Deploy with a bootstrap server changedthird-party/claude-desktop/bootstrap
Nearest release: v2.1.314, published 18 hours before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 30 Oct 2026 18:36 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 30 Oct 2026 18:37 UTC.
Upstream edited
Recorded here
Lines+16added
Lines−2removed
From line
49
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits33to this page, all time
The whole hunk
from line 49, old and new numbered
/
from line 49
4949
5050When two refetches in a row return the same changed values, a few settings apply to the running app without a restart, such as the banner, the display name, and the token limit, as do the two lifecycle keys described below. Every other setting, including inference credentials, the egress allowlist, MCP servers, and the model list, stays on the values the app launched with. For those, the app prompts the user to restart and applies the new response when it relaunches.
5151
52Claude Desktop 1.40609.0 and later enforce that restart. Once a background re-check returns a changed response that needs a restart, and a second check about 30 seconds later returns the same values, the user can keep working for [`relaunchEnforcementHours`](https://claude.com/docs/third-party/claude-desktop/configuration#relaunchenforcementhours) (24 hours by default, at most 336 hours, or `0` to require the restart at once; releases before 1.46388.1 default to 1 hour). After that window the app blocks further use until it restarts, and it relaunches on its own once it has been idle for two minutes (no Claude task running and no keyboard or pointer input).
52Claude Desktop 1.40609.0 and later enforce that restart. Once a background re-check returns a change that needs a restart and a second check about 30 seconds later confirms it, the user can keep working for [`relaunchEnforcementHours`](https://claude.com/docs/third-party/claude-desktop/configuration#relaunchenforcementhours), 24 hours by default (1 hour in releases before 1.46388.1). After that window the app blocks further use until it restarts, and it relaunches on its own after two minutes with no keyboard or pointer input and no Claude task running.
5353
5454Return `relaunchEnforcementHours` in the bootstrap response to change the window, and `configRecheckIntervalMinutes` to change how often running apps check for a new response. The app reads both keys from the newest response, so changing them does not itself require a restart. In the nested response format ([`bootstrap-config-v2`](#response-schema)) both keys sit under `lifecycle`, as `lifecycle.relaunchEnforcementHours` and `lifecycle.configRecheckIntervalMinutes`. Releases before 1.46388.1 read the window from `bootstrap.relaunchEnforcementHours` and do not read the `lifecycle` path, so move the value when your fleet updates (the flat-format key name is unchanged). On a device where `bootstrapUrl` came from an imported file rather than MDM, a device-management profile that sets only [app-behavior keys](https://claude.com/docs/third-party/claude-desktop/mdm.md#update-keys-and-managed-precedence), such as the update keys, supplies these two keys as well, so set them in that profile or the defaults apply there.
5555
from line 259
259259
260260### Request headers (no per-user sign-in)
261261
262Requires Claude Desktop 1.32885.1 or later. Set `bootstrapHeaders` to a JSON object of headers to send on every bootstrap fetch, or `bootstrapHeadersHelper` to the absolute path of an executable that prints such an object on stdout (run with no arguments; its output is cached for a few minutes and merged over the static headers, the helper winning on a conflict). When either key is set and `bootstrapOidc` is not, the app treats the headers as sufficient authentication and fetches the configuration without prompting the user to sign in. If your server answers `401` or `403`, the app discards the cached helper output so the next fetch (the next background check, or a relaunch) re-runs the helper. At launch the app also shows a sign-in prompt; that sign-in succeeds only if your server implements the [device-code grant](#bootstrap-server-as-authorization-server-device-code), so a headers-only server should return `401`/`403` only for a genuinely unusable credential. A `401`/`403` on a background check keeps the running configuration and retries at the next check without prompting. A signed-in user's bearer token replaces any `Authorization` header you configured. Both keys are read from device management or the local configuration file only, never from the bootstrap response, and header values are masked in the diagnostic report. [Origin pinning](#origin-pinning) applies in this mode exactly as in device-code mode. Use this instead of embedding `user:password@` in `bootstrapUrl`, which the app refuses.
262Requires Claude Desktop 1.32885.1 or later. Use this mode instead of embedding `user:password@` in `bootstrapUrl`, which the app refuses.
263
264Set one or both of these keys, described under [MDM configuration keys](#mdm-configuration-keys):
265
266* `bootstrapHeaders`: a JSON object of headers to send on every bootstrap fetch
267* `bootstrapHeadersHelper`: the absolute path of an executable that prints such an object on stdout
268
269When either key is set and `bootstrapOidc` is not, the app treats the headers as sufficient authentication and fetches the configuration without prompting the user to sign in.
270
271If your server answers `401` or `403`, the app discards the cached helper output so the next fetch (the next background check, or a relaunch) re-runs the helper.
272
273* **`401` or `403` at launch**: the app also shows a sign-in prompt. That sign-in succeeds only if your server implements the [device-code grant](#bootstrap-server-as-authorization-server-device-code), so a headers-only server should return `401`/`403` only for a genuinely unusable credential.
274* **`401` or `403` on a background check**: the app keeps the running configuration and retries at the next check without prompting.
275
276A signed-in user's bearer token replaces any `Authorization` header you configured. Both keys are read from device management or the local configuration file only, never from the bootstrap response, and header values are masked in the diagnostic report. [Origin pinning](#origin-pinning) applies in this mode exactly as in device-code mode.
263277
264278## The HTTP contract
265279
No line in this hunk matches that.