What this read moved
1–9 of 9government/config/plugins-and-connectors Changed · +2 / -2 lines
from line 10
1010
1111A connector gives Claude access to another service, such as a search tool your agency runs, and the **Connectors** card is the way to deliver a connector to members. A plugin is a package that changes how Claude works. It can add skills, slash commands, and sub-agents, and it can carry hooks, which are scripts a plugin author includes to run automatically at defined points during a session, such as when a session starts. For adding a connector, see [Connectors](/docs/government/connectors/overview). For what a plugin can contain across Claude products, see the [Plugins overview](/docs/plugins/overview); the Claude for Government differences are covered below.
1212
13A plugin you upload on the **Plugins** card delivers its skills, slash commands, sub-agents, and hooks to members, and its hooks run on the member's machine. In Claude for Government, a connector declared in a plugin you upload here is not connected, so to give members a connector, add it on the **Connectors** card instead.
13A plugin you upload on the **Plugins** card delivers its skills, slash commands, sub-agents, and hooks to members, and its hooks run on the member's machine. A plugin can also declare [MCP servers](/docs/connectors/overview) of its own, and [Plugins that run code](#plugins-that-run-code) describes how they behave. To deliver a connector to members, add it on the **Connectors** card.
1414
1515## Plugin archive formats
1616
from line 40
4040
4141The upload preview marks any plugin that declares components that can run code on the member's machine, for example hooks or an [MCP server](/docs/connectors/overview), and you confirm that you trust such a package before it is added. For a marketplace archive, one confirmation covers every marked plugin in the batch. After you add it, the plugin's row on the **Plugins** card keeps a **Runs code** marker, so you can see at a glance which of the plugins you have added contain these components.
4242
43The marker reflects what a plugin declares. In Claude for Government, a marked plugin's hooks run on the member's machine at defined points during a session, its local MCP server never runs, and a connector declared in a plugin you upload here is not connected.
43The marker reflects what a plugin declares. In Claude for Government, a marked plugin's hooks run on the member's machine at defined points during a session. Claude Desktop can also run a local MCP server that the plugin declares on the member's machine, or connect to a remote one.
4444
4545Treat the marker as a prompt to review the package yourself. You are responsible for the plugins you distribute to members, so read each plugin's contents before you upload it.
4646
government/config/settings Changed · +1 / -1 lines
from line 170
170170
171171The **Plugins** card lets you upload plugin packages and deliver them to members in Claude Desktop. A plugin bundles skills, slash commands, and sub-agents for Claude Desktop, and can also carry hooks and declare connectors; see [Manage plugins and connectors](/docs/government/config/plugins-and-connectors) for how each component behaves in Claude for Government and the [Plugins overview](/docs/plugins/overview) for what a plugin can contain. Plugins are delivered only to Claude Desktop.
172172
173Click **Add plugins** and drop a `.zip` file. The file can be a single plugin package or a whole marketplace archive, for example the **Download ZIP** of a GitHub repository that holds several plugins. A preview shows each plugin's name, version, and description, and marks any plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. In Claude for Government, a plugin's hooks run on the member's machine at defined points during a session; a plugin's declared local MCP server is disabled and does not run. For those plugins, you confirm that you trust the package before it is added. See [Plugins that run code](/docs/government/config/plugins-and-connectors#plugins-that-run-code) for what the marker means and how these components behave in Claude for Government.
173Click **Add plugins** and drop a `.zip` file. The file can be a single plugin package or a whole marketplace archive, for example the **Download ZIP** of a GitHub repository that holds several plugins. A preview shows each plugin's name, version, and description, and marks any plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. In Claude for Government, a plugin's hooks run on the member's machine at defined points during a session, and Claude Desktop can start or connect to an MCP server the plugin declares. For those plugins, you confirm that you trust the package before it is added. See [Plugins that run code](/docs/government/config/plugins-and-connectors#plugins-that-run-code) for what the marker means and how these components behave in Claude for Government.
174174
175175Each plugin you add appears as a row with an **Auto-install** or **Members choose** control. **Auto-install** installs the plugin for every member automatically, and **Members choose** makes it available for members to install themselves. Click the remove icon to queue a plugin for removal. Changes you make in these rows are staged: nothing is applied until you click **Save changes**, and **Discard** clears the pending changes. Plugins you add through the **Add plugins** dialog take effect as soon as you confirm them in that dialog. Removing a plugin stops delivering it, and members who already installed it keep their copy until they remove it themselves.
176176
government/deploy-desktop/configure Changed · +1 / -1 lines
from line 188
188188Deploy the configuration before the app wherever you can. A user whose device already has the profile opens Claude Desktop for the first time and lands directly on the Claude for Government sign-in screen, with no opportunity to sign in to claude.ai by mistake.
189189
190190<Note>
191 Once `bootstrapUrl`, `disableDeploymentModeChooser`, or any other recognized key except the automatic update settings is present in the profile, the device is managed. The in-app configuration window becomes read-only, and locally authored settings, including a single-machine test configuration, are ignored in favor of the profile. A managed device uses only the connection in the profile: users cannot add, import, or switch to other configurations in that window. If a group of users needs a different connection, scope a different profile to their devices or users in your management system, or leave those devices without a profile and set them up as described under [Configure a single machine](#configure-a-single-machine). Removing the profile returns the device to local control.
191 Once `bootstrapUrl`, `disableDeploymentModeChooser`, or any other recognized key except the automatic update settings is present in the profile, the device is managed. The in-app configuration window becomes read-only, and locally authored settings, including a single-machine test configuration, are ignored in favor of the profile. A managed device uses only the connection in the profile: users cannot add, import, or switch to other configurations in that window. Users on a managed device can still turn on developer mode from the **Help** menu by choosing **Troubleshooting**, then **Enable Developer Mode**. The configuration window it reveals stays read-only, so they can view the connection there but not change it. If a group of users needs a different connection, scope a different profile to their devices or users in your management system, or leave those devices without a profile and set them up as described under [Configure a single machine](#configure-a-single-machine). Removing the profile returns the device to local control.
192192</Note>
193193
194194The app reads managed configuration at launch. After you change the profile on a device where the app is already running, have the user fully quit and reopen it.
government/desktop/models Changed · +2 / -0 lines
from line 12
1212
1313When a long conversation or task gets close to filling the context window, Claude summarizes the earlier part to make room and carries on from the summary, which the app calls compacting. With the **1M context window** entry this happens much later, so long pieces of work keep their full detail for longer. Until a conversation outgrows the standard entry's window, the two entries behave the same and use the same amount of your [allowance](/docs/government/account/usage). Past that point the **1M context window** entry keeps sending Claude the whole conversation rather than a summary, so each further message uses more of your allowance and responses can take longer to start.
1414
15For Cowork tasks on very large document sets, for example hundreds of pages of PDFs, use the **1M context window** entry so Claude can keep more of the documents in view before it compacts.
16
1517To use the larger window, open the model picker and choose the model's entry marked **1M context window**, or **1M** in Code. The entry in use has a check mark next to it, and the model name in the message box reads the same for both entries in Chat and Cowork, so open the picker to check. If you have not picked a model before, the larger window may already be selected. The entry appears only for models where Claude for Government offers the larger window, so if no model in your picker has it, ask your organization's owner whether your seat tier can include a model that does.
1618
1719<Note>
government/desktop/plugins Changed · +1 / -1 lines
from line 33
3333
3434## What plugins add in Claude for Government
3535
36A plugin adds its skills, slash commands, sub-agents, and hooks, and its hooks run on your machine at defined points during a session. The connectors you can use are the ones your administrators provide, which appear under **Customize**, then **Connectors**. Connectors declared by a plugin you add yourself are not added to Claude Desktop's connectors, and a local [MCP server](/docs/connectors/overview) declared by a plugin never runs.
36A plugin adds its skills, slash commands, sub-agents, and hooks, and its hooks run on your machine at defined points during a session. The connectors you can use are the ones your administrators provide, which appear under **Customize**, then **Connectors**. Connectors declared by a plugin you add yourself are not added to Claude Desktop's connectors.
3737
government/security/security-and-data-handling Changed · +2 / -2 lines
from line 124
124124
125125<AccordionGroup>
126126 <Accordion title="Where do connectors run, and where are tokens stored?">
127 Connectors are called from the desktop application, outside the sandbox. The built-in Microsoft 365 connector and administrator-added connectors call their endpoints directly from the user's device, through the system proxy where one is configured. OAuth tokens for both are stored encrypted on each user's device using operating system encryption (macOS Keychain on Mac, DPAPI on Windows). For administrator-added connectors, the bearer header entered on the Config page is delivered to each user's desktop. A plugin package can include skills, slash commands, sub-agents, and hooks, which run on the member's machine. The Config page asks the administrator to confirm trust before adding a plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. A plugin's declared local MCP server is disabled in Claude for Government and does not run, and a connector declared inside a plugin package does not become available as an organization connector unless the plugin was delivered through device management. End users cannot add their own connectors. End users can upload their own plugin files in Claude Desktop; a user-uploaded plugin's skills, commands, sub-agents, and hooks run on that user's machine, and any connector it declares does not become available as an organization connector. Administrators distribute plugins to members on the Config page with a per-plugin choice of automatic installation or member opt-in. See [Connectors](/docs/government/connectors/overview) and the Plugins card under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards).
127 Connectors are called from the desktop application, outside the sandbox. The built-in Microsoft 365 connector and administrator-added connectors call their endpoints directly from the user's device, through the system proxy where one is configured. OAuth tokens for both are stored encrypted on each user's device using operating system encryption (macOS Keychain on Mac, DPAPI on Windows). For administrator-added connectors, the bearer header entered on the Config page is delivered to each user's desktop. A plugin package can include skills, slash commands, sub-agents, and hooks, which run on the member's machine. The Config page asks the administrator to confirm trust before adding a plugin that declares components that can run code on the member's machine, for example hooks or an MCP server. When an administrator adds a plugin on the Config page, Claude Desktop can run a local MCP server that the plugin declares on the member's machine, or connect to a remote one. End users cannot add their own connectors. End users can upload their own plugin files in Claude Desktop; a user-uploaded plugin's skills, commands, sub-agents, and hooks run on that user's machine, and any connector it declares does not become available as an organization connector. Administrators distribute plugins to members on the Config page with a per-plugin choice of automatic installation or member opt-in. See [Connectors](/docs/government/connectors/overview) and the Plugins card under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards).
128128 </Accordion>
129129
130130 <Accordion title="Do connectors follow the sandbox egress allowlist?">
from line 168
168168 </Accordion>
169169
170170 <Accordion title="Where are files added to a project stored, and are they indexed?">
171 A project in Claude for Government is stored in the application data directory on the user's own device, together with any instructions, links, and folder references the user adds to it. Files added to a project stay on the user's local disk; there is no service-side project store, and files are not vectorized or indexed. Claude reads them directly from disk on demand with its file tools. Content Claude reads from those files is handled like the rest of the conversation: inference requests pass through the Claude for Government service to the model endpoint but are not retained. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access).
171 A project in Claude for Government is stored in the application data directory on the user's own device, together with any instructions, links, and folder references the user adds to it. Files added to a project stay on the user's local disk; there is no service-side project store, and files are not vectorized or indexed. Claude reads them directly from disk on demand with its file tools. A new Cowork session in the project does not reuse what an earlier session read, so Claude reads the files it needs again. The project's [memory](/docs/third-party/claude-desktop/data-storage#memory) carries short notes between sessions, such as preferences and decisions, not the contents of the files. Content Claude reads from those files is handled like the rest of the conversation: inference requests pass through the Claude for Government service to the model endpoint but are not retained. See [Desktop and filesystem access](/docs/third-party/claude-desktop/local-access).
172172 </Accordion>
173173
174174 <Accordion title="Can the local data location be changed for backup or sync?">
third-party/claude-desktop/bootstrap Changed · +1 / -1 lines
from line 194
194194| Okta | `http://127.0.0.1:53180/callback` (any fixed port) on a **Native** application | Set to the registered port | Create a custom authorization server with an audience your bootstrap server validates. |
195195| Other OIDC | `http://127.0.0.1/callback` | Set only if exact-port match is enforced | None |
196196
197Use `127.0.0.1`, not `localhost`.
197Register the redirect URI with `127.0.0.1` rather than `localhost`, because the app sends `http://127.0.0.1:<port>/callback` by default. If your identity provider accepts only `localhost` in a registered redirect URI, set the `redirectHost` field of [`bootstrapOidc`](/docs/third-party/claude-desktop/configuration#bootstrapoidc) to `localhost` and register `http://localhost/callback` instead, or `http://localhost:<port>/callback` when you set a redirect port.
198198
199199This page covers only the bootstrap sign-in. Authentication for inference is independent of bootstrap and depends on what your response provisions; see the relevant provider page ([gateway SSO](/docs/third-party/claude-desktop/gateway#single-sign-on-with-your-identity-provider), [Google Cloud's Agent Platform](/docs/third-party/claude-desktop/vertex), [Amazon Bedrock](/docs/third-party/claude-desktop/bedrock), [Microsoft Foundry](/docs/third-party/claude-desktop/foundry)).
200200
third-party/claude-desktop/gateway Changed · +1 / -0 lines
from line 235
235235| `tokenUrl` | No\* | Explicit OIDC token endpoint. Must be set together with `authorizationUrl`. Ignored when `issuer` is set. |
236236| `scopes` | No | Space-separated OIDC scopes. Defaults to `openid profile email offline_access`. Required when `bearerTokenType` is `access_token`. See [Refresh tokens and session lifetime](#refresh-tokens-and-session-lifetime) for how this field interacts with silent refresh. |
237237| `redirectPort` | No | Fixed local port for the loopback redirect. Leave unset to let the app choose an ephemeral port (Entra). Set when the provider requires an exact port match (Okta). |
238| `redirectHost` | No | Host in the loopback redirect URI, `127.0.0.1` (the default) or `localhost`. Set to `localhost` when the identity provider accepts only `localhost` in a registered redirect URI, and register the `localhost` form of the URI instead (`http://localhost/callback`, or `http://localhost:<port>/callback` with `redirectPort`). |
238239| `bearerTokenType` | No | Which token the app sends to the gateway as the `Authorization: Bearer` value. `id_token` (the default) sends the OIDC ID token — the gateway validates it offline against the provider's JWKS with `aud` equal to the client ID. `access_token` sends the OAuth access token instead — use this for gateways that validate as an OAuth resource server rather than validating the ID token directly. When set to `access_token`, `scopes` is required. |
239240| `appendOfflineAccess` | No | Whether to automatically append `offline_access` to `scopes` in `access_token` mode. Defaults to `true`. Set to `false` only if your authorization server rejects `offline_access` as an unrecognized scope. See [Refresh tokens and session lifetime](#refresh-tokens-and-session-lifetime). |
240241| `resource` | No | RFC 8707 resource indicator: an absolute `https://` URL identifying the gateway as the access-token audience. When set, the app sends `resource=<value>` on the authorization, token, and refresh requests. Use only with `bearerTokenType: "access_token"` and an identity provider that implements RFC 8707 (for example AD FS); leave unset for Microsoft Entra ID, which rejects the parameter; request the gateway's API scope in `scopes` instead. Changing it signs users in again. Ignored by the OS-broker sign-in flow (`inferenceGatewayOidcAuthFlow: broker`). |
third-party/claude-desktop/vertex Changed · +1 / -1 lines
from line 225
225225* If your IdP permits loopback redirect URIs on any port (the [RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252#section-7.3) native-app pattern, supported by Microsoft Entra ID under the **Mobile and desktop applications** platform), register `http://127.0.0.1/callback` and leave `redirectPort` unset.
226226* If your IdP requires an exact registered redirect URI (such as Okta or PingFederate), set the `redirectPort` field of `inferenceVertexWorkforceOidc` to a fixed port and register the resulting URI exactly, for example `http://127.0.0.1:53180/callback`.
227227
228Use `127.0.0.1`, not `localhost`; most IdPs do not treat them as interchangeable.
228Register the redirect URI with `127.0.0.1` rather than `localhost`, because the app uses `127.0.0.1` by default and most IdPs do not treat the two as interchangeable. If your IdP accepts only `localhost` in a registered redirect URI, set the `redirectHost` field of [`inferenceVertexWorkforceOidc`](/docs/third-party/claude-desktop/configuration#inferencevertexworkforceoidc) to `localhost` and register `http://localhost/callback` instead, or `http://localhost:<port>/callback` when you set `redirectPort`.
229229
230230Distribute the workforce-pool provider audience and the IdP OIDC client in the managed configuration; the app shows a **Sign in** page on first launch, runs an authorization-code-with-PKCE flow against your IdP in the system browser, exchanges the returned ID token for a Google Cloud access token at `sts.googleapis.com`, and stores the IdP refresh token encrypted with the operating system's secure storage. No `gcloud` CLI, helper script, or Google identity is required.
231231