Group Policy / Intune: enterprise managed policy for the Bolt desktop app (Windows)

The Windows counterpart of the Jamf and Intune guide. Same closed key catalogue, same merge semantics, same app. On Windows Bolt reads it from the registry.

• Template: bolt-desktop.admx + en-US/bolt-desktop.adml

• Where the app reads:

  Tier	Registry key	Who can write it	Bolt reports
  Forced	HKLM\SOFTWARE\Policies\Sparcle\Bolt	Group Policy / Intune / an admin	forced: true: “Managed by your organization”
  Device default	HKLM\SOFTWARE\Sparcle\Bolt	an admin (a provisioning script)	forced: false

HKCU is not read, in either tree. Any signed-in user can reg add their own hive without administrator rights, and a forced source wins the merge outright, so reading it would let any local user hand themselves policy. A user-scoped GPO targeting Bolt will appear to apply in the editor and do precisely nothing on the device: this is the intended behaviour, not a bug to work around.

Which keys exist

The catalogue is closed and identical to the macOS one: see the table in the Jamf and Intune guide for what each key means and how it merges. A registry value outside it is silently ignored.

Only the value shapes differ, because the registry has no property list:

Two consequences worth knowing before you debug something:

• There is no registry boolean. REG_DWORD 1/0 is the switch, and anything else (2, a REG_SZ "true") is rejected rather than coerced: the key is then absent, not defaulted.
• List keys are REG_MULTI_SZ, not the Group Policy “list” control. The list control writes each entry as a numbered REG_SZ under a subkey, which Bolt does not read. That is why the template uses multi-line text boxes. REG_EXPAND_SZ is also refused everywhere: expanding it would splice in the signed-in user’s environment block, which the user controls.

Deploy via Group Policy (on-prem AD)

1. Copy bolt-desktop.admx into the domain Central Store, \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\, and en-US\bolt-desktop.adml into the en-US\ subfolder beside it. (Without a Central Store: C:\Windows\PolicyDefinitions\ on the machine running the editor.) The .adml must keep the same base name and sit in a language subfolder, or the editor refuses to load the namespace.
2. Open Group Policy Management, edit a GPO linked to the target OU.
3. Computer Configuration → Policies → Administrative Templates → Bolt Desktop. All settings are machine scope; there is deliberately nothing under User Configuration.
4. Configure the settings you want and leave the rest Not Configured: that is what lets your Bolt deployment’s own policy and the app’s built-in floor still apply. Disabling a switch is not the same as leaving it unset: Disabled writes a locked 0.
5. gpupdate /force on a target machine, then restart Bolt.

Deploy via Microsoft Intune

Intune ingests the same file; no OMA-URI authoring by hand.

1. Devices → Configuration → Create → New policy → Windows 10 and later → Templates → Imported Administrative templates (Preview).
2. Import bolt-desktop.admx and, when prompted, its en-US/bolt-desktop.adml.
3. Create → New policy → … → Imported Administrative templates and configure the Bolt Desktop settings the import surfaced.
4. Assign to a device group (not a user group: the settings are machine scope).

Verify

1. On a target machine, confirm the policy actually landed before concluding the app ignored it: Bolt treats an unmanaged machine as “zero keys, no error”, so “nothing happened” looks identical to “nothing was pushed”:

   reg query "HKLM\SOFTWARE\Policies\Sparcle\Bolt"

2. Restart Bolt and confirm the effect: e.g. set the enforcement level to Block and confirm a risky paste is blocked rather than warned, or add a host to the AI destinations list and confirm it is now covered.

3. Confirm it reads as locked: the setting shows “Managed by your organization” in Bolt’s admin settings. If it shows as an ordinary value, it landed in HKLM\SOFTWARE\Sparcle\Bolt (the device-default tier) rather than the Policies tree.

4. Set the GPO back to Not Configured and gpupdate /force; Group Policy removes the value from the Policies tree, so the key un-forces on Bolt’s next read.

Setting a device default instead of a locked policy

For a value an admin wants to set per-machine without locking it (a provisioning script setting boltUrl on imaged machines, say), write the sibling tree directly. Bolt reads it and reports it unforced:

reg add "HKLM\SOFTWARE\Sparcle\Bolt" /v boltUrl /t REG_SZ /d "https://bolt.example-corp.com" /f
reg add "HKLM\SOFTWARE\Sparcle\Bolt" /v riskySites /t REG_MULTI_SZ /d "chatgpt.com\0claude.ai" /f

The Group Policy Editor cannot write this tree, which is exactly why the app can trust the Policies tree to mean “forced”.

Unforced is not “advisory”. It changes three things and no more:

• Bolt does not label the setting “Managed by your organization”.
• A switch no longer wins outright; the ordinary off-beats-on rule applies, so another source can still turn the feature off.
• Group Policy will not clear it on the next refresh, because Group Policy does not own that tree: you set it, you remove it.

It does not demote the value to a suggestion. Precedence is by source, not by forcedness: device policy outranks the org policy your Bolt server serves, which outranks the built-in floor, and for ordinary configuration keys that ordering decides the winner outright, forced or not. Use this tree for machines that genuinely need a different value, not as a soft hint.

Two things temper that, and both are per key, not per tier:

• The enforcement level is always most-restrictive-wins, coverage lists are always unioned, and exemption lists are always intersected. Neither the tier a value came from nor its forced flag changes those three rules.
• Your Bolt server serves only four of the keys in this template today: dlpMode, riskySites, riskyAppBundleIds and allowedCorpDomains. For the rest there is no deployment-served value to outrank or be outranked by: what you write in either registry tree is what governs, alongside Bolt’s built-in default. So “leave it Not Configured and let the deployment decide” is only a real option for those four.

An explicitly empty exemption list is a real setting (it closes every hole) and is not the same as leaving the policy unset. If you need one and the editor’s empty text box does not produce it, write it directly:

reg add "HKLM\SOFTWARE\Policies\Sparcle\Bolt" /v allowedCorpDomains /t REG_MULTI_SZ /d "" /f

Check which of the two you got with reg query … /v allowedCorpDomains: an empty REG_MULTI_SZ is present-and-empty, an unset policy is absent.