One read of Claude Documentationclaude-docs-20260814T092040Z
213 pages moved out of 213 read.
Pages moved
213
significant first
Pages read
213
in this capture
Captured
09:20 UTC
Corpus hash
dfa3e64bc187
full baseline · baseline
What this read moved
126-150 of 213, page 6 of 9This capture is too large to show at once. Changes 126-150 of 213 are below, significant first; the rest are on the following screens.
connectors/verification First recorded · 48 lines, first recorded
# Connector verification ## Verified ## Community ## Custom ## The directory is optional ## Advice for all third-party connectors ## List your own connector
The first capture of this source. The page was already there, and this is what it said.
# Connector verification > How Anthropic reviews connectors, and what Verified, Community, and Custom mean The [Connectors Directory](/docs/connectors/directory) includes connectors built by Anthropic and by third-party developers. Each connector shows how much Anthropic has reviewed it, so you can decide what to connect to. ## Verified Anthropic has reviewed this connector for quality and security. Verified connectors show a checkmark next to their name. ## Community A third-party developer built this connector. It passed Anthropic's automated checks, but Anthropic has not reviewed it in depth. Community connectors show a "Community" label in the directory and in [Customize > Connectors](https://claude.ai/customize/connectors). Before you connect one, Claude shows a reminder that it has not been reviewed in depth. The label is a quality signal. It affects how the connector is displayed and discovered in the directory, not how the connector itself functions: once connected, a community connector works the same way as a verified one. ## Custom You added this connector yourself. Anthropic has not reviewed it. See [custom connectors](/docs/connectors/custom/remote-mcp) to learn how to add one. ## The directory is optional The directory is a catalog, not a separate kind of connector. Connectors in the directory and custom connectors you add yourself use the same technology. If you have a connector's URL, it can be added as a custom connector. A connector does not need to be in the directory for you to use it. Listing a connector in the directory makes it discoverable by other people and gives it a review label (a checkmark if Anthropic has verified it, or "Community" if it passed Anthropic's automated checks). It does not change the tools the connector exposes. See [directory vs custom](/docs/connectors/building/directory-vs-custom) for a detailed comparison. ## Advice for all third-party connectors Whatever the label, this advice applies to any connector built by someone other than Anthropic: * Only connect to servers from developers and organizations you trust. * A connector's developer controls which tools it exposes and can change them at any time. * Anthropic does not run a third-party connector's servers and does not control how it handles your data. * Carefully review requested permission scopes during authentication. * Be aware of prompt injection risks; Claude has built-in protections. * Monitor for unexpected changes in tool behavior. For more, see [security and privacy](/docs/connectors/custom/remote-mcp#security-and-privacy). ## List your own connector If you build connectors and want yours in the directory, start with the [review criteria](/docs/connectors/building/review-criteria) and the [submission guidelines](/docs/connectors/building/submission).
cowork/changelog First recorded · 814 lines, first recorded
# Changelog
The first capture of this source. The page was already there, and this is what it said.
# Changelog > Release notes for Claude Desktop <Update label="v1.30096.1" description="2026-08-13"> **General** * Fixed Find (Cmd+F) doing nothing the first time it was pressed after launch. * Fixed right-to-left text in the composer scrambling around embedded left-to-right words; code blocks stay left-to-right. * Fixed the Artifacts entry missing from the sidebar on Windows machines that can't run local Cowork; it now opens the Artifacts gallery. * Fixed macOS asking for notification permission as soon as the app launched, instead of when the first notification is about to appear. * Fixed the app crashing at launch, or on a system theme change, on some Linux installs (most often repackaged builds); it now falls back to a default tray icon. **Code** * Added Rewind to cloud sessions (message menu, Esc Esc, or `/rewind`), and fixed rewound-away messages reappearing when a rewound cloud or Remote Control session was reopened. * Fixed an interrupted Claude Code download (for example, after a crash or power loss mid-install) leaving Code sessions on that computer unable to start, most often on Windows. * Fixed an unanswered permission or plan-approval prompt in a cloud session sometimes being treated as approved after the session's environment disconnected. * Fixed cloud sessions marked as needing input sometimes opening without the question or approval prompt. * Fixed Remote Control sessions sometimes never connecting when opened while idle, staying off your other devices after a stop or interruption until turned back on by hand, and looking idle instead of reporting that the host computer is offline. * Fixed copy and paste problems: transcript text pasted into rich-text apps lost the spaces around inline code, bold, and italics and mangled code blocks, and Cmd+C after selecting text in the Plan view copied nothing. **Cowork** * Fixed the earlier conversation being discarded when you chose Go back after a failed task resume, or edited a message right after the app restarted. * Fixed memory saves failing when the Claude Code `managed-settings.json` policy sets `allowManagedPermissionRulesOnly`. * Fixed Cowork on Windows failing on every launch with "VM service not running" after its background service had stopped; the service is now restarted automatically, and otherwise the error explains that restarting the computer restores it. * Fixed Cowork sometimes pulling you back to the bottom of a task after you had scrolled up, for example when a sub-agent step finished. **3P** * Added `otlpAuthMode` and `otlpHeadersHelper`, two ways to authenticate telemetry exports without static `otlpHeaders`: set `otlpAuthMode` to `inference-credential` to reuse the signed-in user's inference token, or point `otlpHeadersHelper` at an executable that prints the collector headers as JSON. * Added an optional `inferenceGatewayOidc.resource` subfield that sends an RFC 8707 resource indicator on gateway sign-in and token refresh, for identity providers that audience-restrict access tokens. * Changed `inferenceBedrockBaseUrl` and `inferenceVertexBaseUrl`: only affects users who entered the bootstrap server URL themselves (in Settings or a local config file). Those users are now asked once to allow a Bedrock or Vertex endpoint that server delivers before it takes effect, the same prompt `inferenceGatewayBaseUrl` already shows. Managed deployments (bootstrap URL set by device management, or `trustBootstrapDelivery: true`) see no change. * Changed `claudeAiImport`: an imported session now asks the user to confirm once (Trust and resume) before Claude continues it for the first time; this also applies to sessions imported before this update. * Fixed a single malformed `allowedPluginMarketplaces` (beta) entry disabling every configured marketplace; the entry is now skipped and reported. * Fixed sending messages failing when a bootstrap server turned Cowork off (`coworkTabEnabled` set to `false`); the home screen now opens directly into Chat. * Fixed OpenTelemetry exports being rejected when the configured gateway also serves as the telemetry collector endpoint. </Update> <Update label="v1.28929.0" description="2026-08-11"> **General** * Added the standard macOS full-screen keyboard shortcut, with an Enter Full Screen and Exit Full Screen item in the View menu. * Fixed a startup error on some Linux systems, most often repackaged or containerized installs, that left the app without a tray icon and recurred on every system theme change. * Fixed commands in the built-in terminal failing with error -1743 when controlling other apps on macOS, instead of showing the Automation permission prompt. * Fixed sign-in on macOS repeatedly failing with "Failed to login, it may have been cancelled"; Claude now opens the sign-in page in your default browser when the system sign-in sheet is unavailable. * Fixed some Windows installs (MSIX packages and enterprise-managed roaming profiles) failing to save chat history, settings, and scheduled tasks, and Cowork failing to start with "Download failed" after an app update. * Fixed the app's memory use growing without bound during long-running sessions. **Code** * Removed the ability for scheduled-task runs and other unattended sessions to start dev servers in the Browser preview; other sessions now approve each distinct dev server command once rather than on every start. * Fixed app settings, and the app's record of session worktrees, being discarded when those files had been re-saved with a UTF-8 byte-order mark by an external editor. * Fixed forked sessions starting from the original base branch instead of the parent session's current branch. * Fixed importing Claude Code CLI sessions changing the order of existing sessions in `claude --resume`. * Fixed sessions failing to resume, reporting their conversation history as missing, after Claude had moved the session into a worktree. * Fixed file uploads through Claude in Chrome from a Code session failing with "Invalid arguments for tool file\_upload". **Cowork** * Fixed a follow-up message sent while Claude was still writing a reply sometimes being dropped, with the reply cut off. **3P** * Added history import. When `claudeAiImport.enabled` is `true`, users can bring a Claude.ai data export, Cowork, Code, and Chat sessions from other Claude installs on the same computer or from an app data folder they choose, and terminal Claude Code sessions into the app from Settings > Import. `claudeAiImport.bannerBehavior` controls an optional banner on new tasks that offers it: `off` (default), `detect` (only when earlier sessions are found on the computer), or `show` (everyone, until dismissed or imported). * Added `modelPrefer1mContext`. When `true`, a user who has not yet chosen a model starts on the 1M-context variant of the default model whenever the deployment marks or reports that model as 1M-capable, including auto-discovered models. Saved selections are never changed. Defaults to `false`. * Added the gateway address, `inferenceGatewayBaseUrl`, to the one-time bootstrap consent prompt. When a bootstrap server delivers it and the bootstrap URL was not set through device management, each user is asked once at launch to allow the address, and again if it later changes; the app does not connect to the gateway until they choose Allow. Existing installs prompt the first time they start this version. Set `trustBootstrapDelivery` to `true` in your device-management profile or local configuration file to accept it for everyone in advance. * Changed the Code tab to be hidden entirely, rather than shown greyed out, when an administrator has disabled Code. * Fixed a session opened in a new window on Windows having no title bar, window controls, or drag area. * Fixed stored sign-ins being lost when the system keychain was temporarily locked. * Fixed the Chat tab ignoring `toolSearchEnabled`, which sent every connector's tool definitions with each request and could exceed the context window when many connectors were configured; Chat now loads them on demand when the key is `true`, as Cowork and Code do. * Fixed the credential-expired notice and the session error banners in Cowork and Code offering no way to sign in again when the credential comes from a helper script (`inferenceCredentialHelper`); they now show "Sign in again", which re-runs the helper. * Fixed the model picker reverting to the standard-context variant in new sessions, after relaunch, and when switching between Chat and Cowork once the 1M-context variant had been chosen. </Update> <Update label="v1.26832.0" description="2026-08-06"> **General** * Added a "Start a new project" option to the "Add to project" menu, which opens the create-project dialog. * Added Esc as a way to end voice mode in the chat composer. * Added the ability to add suggested skills in local sessions, and plugins from your personal marketplaces, directly from their suggestion cards. * Fixed Claude Desktop on Linux entering a crash-and-relaunch loop that consumed heavy processor time when automatic session restore ran into persistent graphics failures. * Fixed starting a chat inside a project showing a blank screen until the response finished, and leaving the chat without its project name or title. * Fixed the scheduled-task prompt editor not being announced to screen readers as a labeled multiline text box. **Code** * Added session-window restore: Claude Code session windows that were open when you quit now reopen the next time you launch the app. * Changed permission-mode picks so they apply to the folder where you made them instead of becoming a machine-wide default. * Removed the "Always allow" option when approving dev server starts in the Browser preview; each new server start now asks, and a server that has crashed asks again instead of restarting silently. * Fixed "Try again" on session-error cards sometimes doing nothing, and a failed send's retry card and prompt text now survive an app relaunch. * Fixed leftover session workspaces building up on disk until new sessions could fail with a disk-space error. * Fixed repository pickers in project settings and scheduled tasks timing out or omitting repositories in large organizations; they now load quickly, can search every repository, and can load more results. **Cowork** * Added a ⋮ menu to scheduled tasks in the sidebar, including Mark as unread for the latest run. * Added a confirmation before a link in a live artifact opens in your browser, with a per-site "Don't ask again" option. **3P** * Added `updateViaUpdatesHost`. Set it to `true` to read the update feed from `releases.claude.com`, a host that serves only the desktop update check and carries no model API, so networks that block `api.anthropic.com` can still receive updates. Installer downloads continue to come from `downloads.claude.ai`. Defaults to `false`. * Added an access mode to each `allowedWorkspaceFolders` entry. Set `mode` to `ro` to let Claude read and search a folder without changing it: in Cowork, writes are blocked and Claude is directed to put modified copies in the session outputs folder. In the Code tab this covers Claude's file tools only; Bash in the Code tab and SSH sessions do not yet enforce it. Entries without `mode` stay read-write, so existing configurations are unchanged. * Added optional `:port` suffixes to `coworkEgressAllowedHosts` entries, for example `internal.corp.com:8443` or `*.corp.com:8443`, restricting that entry to the named port. This applies to the sandbox's web fetch now, and to shell egress once the updated virtual machine image ships; on the Code tab, a port-scoped entry is treated as its bare host (any port). Entries without a port keep allowing any port, and an invalid entry is dropped on its own with a warning in the logs. * Added settings that decide where users sign in for inference to the one-time bootstrap consent prompt: the Azure AI Foundry Entra tenant and client, Bedrock IAM Identity Center, the Vertex OAuth client and workforce identity, and gateway OIDC. Set `trustBootstrapDelivery` to `true` in your device-management profile to accept these for everyone in advance. * Added the merged Chat and Cowork home as the default. The "New" button starts a chat or a task from one composer, and the sidebar shows Home, which lists chats and tasks together, alongside Code. * Changed the `trustBootstrapLocalExec` key name to `trustBootstrapDelivery`, reflecting that it now covers sign-in targets as well as helper scripts and connectors. The previous name continues to work in existing profiles. * Fixed chats started inside a Project not picking up the Project's Instructions and Context links, including reading the files linked there. * Fixed Code sessions on a custom gateway endpoint ending with an idle-timeout error while the gateway was still sending keep-alive responses. * Fixed Code tab sessions on gateway and direct API key deployments still sending nonessential traffic to `api.anthropic.com` after an administrator turned off nonessential telemetry. * Fixed model selections provided by your deployment being overridden by an out-of-date Claude Code `managed-settings.json` left on the device. * Fixed the published `bootstrap-config-v2.schema.json` describing flat keys instead of the nested shape the app's own configuration export uses. </Update> <Update label="v1.25927.0" description="2026-08-04"> **General** * Added a chevron next to the composer's microphone button that switches between dictation and voice mode and keeps your choice; clicking the microphone now starts dictation right away. * Fixed `⌘K` (or `Ctrl+K` on Windows and Linux) search missing results from tool output and archived sessions. * Fixed a crash on macOS during passkey and Touch ID prompts when the system language is German, Spanish, French, Hindi, Indonesian, Italian, Japanese, or Korean. * Fixed automatic and menu-triggered update restarts interrupting an in-progress Claude Code or Cowork task. * Fixed the app being left with no usable window: a failure during startup now shows an error dialog and records the details to a file, and a window the system shut down under low memory reloads instead of staying blank. **Code** * Added automatic resume for sessions interrupted when your computer goes to sleep. A banner with a manual Continue button appears only when resuming isn't safe, and you can continue the session in the cloud instead. * Added capture and annotation for the page the Browser pane is showing, including external sites, so you can mark up what you see and attach the image to chat. * Fixed a crash while using the in-app browser on pages with heavy console or network activity. * Fixed messages sent while Claude was working disappearing from a session after it was reloaded from disk. * Fixed sessions sometimes becoming permanently unopenable, showing "No messages yet" while their conversation history was still on disk. * Fixed starting a session and swapping repositories stalling in organizations with very large repository lists: the pickers now load repositories page by page, find the rest as you type, say when more are available by searching, and report a failed search instead of showing empty results. **Cowork** * Added pasted and attached images to the session's uploads folder, so Claude can open and edit the actual file. * Fixed "Allow for this task" not appearing for connector tools when your organization has turned off persistent "Always allow". * Fixed documents showing an internal file id instead of their title, including in export filenames and approval prompts. * Fixed long-running workspace shell commands, such as large database queries, being cut off too early. * Fixed scheduled task problems: a cron expression using `7` for Sunday never ran, stalled runs kept running in the background until the app was restarted, and "Allow for all scheduled runs" appeared on prompts where the choice could not be saved, so the task asked again on every run. **3P** * Added Projects for organizing Chat conversations: create a project, start a chat inside it, or move existing chats in. Projects stays available even when your administrator has turned the Cowork tab off. * Added `inferenceGatewayOidcAuthFlow` and `inferenceVertexWorkforceAuthFlow`, which choose whether identity-provider sign-in for gateway and Vertex workforce-identity credentials runs in the system browser (the default) or through the operating system's Microsoft account broker on Windows and macOS, so sign-in can satisfy Conditional Access policies that require a managed device. * Added `managedMcpServers[].oauth.authFlow`, which lets a managed connector sign in through the operating system's Microsoft Entra account broker on Windows and macOS, so Conditional Access policies that require a managed device no longer block it. Devices without a broker keep using browser sign-in. * Added `skillCreationEnabled`, which controls whether users can create and upload their own skills. It defaults to on; setting it to `false` hides the creation and upload surfaces and turns off Claude's skill-creation tools. It appears in the Setup window under workspace restrictions. * Added `trustBootstrapLocalExec`. Each user is now asked once for consent when the bootstrap configuration includes settings that run local commands, such as credential helpers and local connectors. Set this key to `true` to accept them for everyone in advance. It defaults to `false` and is accepted only from MDM or a local configuration file. * Added a built-in GitHub connector to `managedMcpServers`: set `server` to `github` and supply your own GitHub OAuth app client ID with the device flow enabled. The new `host`, `toolsets`, and `readOnly` subfields point the connector at a GitHub Enterprise Server instance, choose which toolsets load, and offer read tools only. The connector is also configurable from the Setup window. * Added support for mounting Windows mapped network drives into the Cowork sandbox, so shell commands and document processing can work with files on network drives, and fixed adding a mapped network-drive folder mid-session being rejected with a message to use the folder picker. * (breaking) Changed the nested v2 bootstrap response: `deploymentDisplayName` and `deploymentDisplaySubtitle` now sit under `appearance`, and `endUserAttribution` and `userContentRendererUrl` under `workspace`. The flat MDM key names are unchanged. * Changed `managedMcpServers` and `microsoftAuthBroker` to be supported on standard deployments as well, so an administrator can enable the built-in Microsoft 365 connector by adding it to `managedMcpServers` through MDM. It stays off unless configured. * Changed where several keys can be delivered from: `claudeAiImport`, `deploymentDisplayName`, and `deploymentDisplaySubtitle` now accept values from MDM and a local configuration file as well as a bootstrap server, and `disableDeepLinkRegistration`, `microsoftAuthBroker`, `userContentRendererUrl`, `inferenceFoundryTenantId`, `inferenceFoundryClientId`, `inferenceCredentialHelper` (with its TTL, timeout, and silent-refresh keys), `inferenceBedrockProfile`, `inferenceBedrockAwsDir`, `inferenceBedrockAwsCliPath`, and `inferenceVertexCredentialsFile` can now be delivered by a bootstrap server. The keys that name a local executable go through the consent prompt above. * Deprecated `organizationPluginsUrl` and removed it from the configuration reference. The key is still honored, but organization plugins are better configured with `allowedPluginMarketplaces`. * Updated `enduserAttribution` to the corrected spelling `endUserAttribution`. The previous spelling is still accepted and now records a configuration warning. * Fixed connector sign-in recovery: connectors no longer ask you to sign in again after a slow startup when the credentials are still valid, and the GitHub connector shows its Reconnect card on the next tool call after its token is revoked on github.com instead of staying stuck. * Fixed tasks failing with "Couldn't start this task" for the rest of the session when the app launched while the network or the sign-in credential was unavailable. * Fixed the app losing administrator-enabled features, such as the Chat tab, for the rest of the session when the organization's configuration server was unreachable at launch. It now retries in the background and recovers. * Fixed the home composer and sidebar still offering Cowork when an administrator has turned the Cowork tab off; Cowork is now hidden instead of greyed out, while Chat and Projects remain available. </Update> <Update label="v1.24012.11" description="2026-08-03"> **General** * No user-facing changes. **Code** * No user-facing changes. **Cowork** * No user-facing changes. **3P** * Fixed sessions started while configured MCP servers were still connecting having no connector tools until a new conversation was started. * Fixed the Microsoft 365 connector not appearing after first-time sign-in until the app was restarted. </Update> <Update label="v1.24012.9" description="2026-07-24"> **General** * No user-facing changes. **Code** * No user-facing changes. **Cowork** * Fixed plugin hooks silently doing nothing on Windows. **3P** * Added the `mcpPersistentAlwaysAllowEnabled` managed configuration key, letting admins disable the persistent "Always allow" approvals for MCP tools while keeping session-scoped approvals available. * Added the five-level effort selector for Claude Opus 5 in the model picker. Extended thinking is always on for Opus 5. </Update> <Update label="v1.24012.0" description="2026-07-21"> **General** * Added an option to keep custom plugin marketplaces up to date automatically, and fixed a marketplace refresh reporting success before the sync ran and re-adding an existing marketplace not refreshing its contents. * Improved keyboard and screen reader support across the app: settings tabs and share-visibility choices respond to arrow keys, dialogs announce meaningful titles, decorative graphics no longer clutter screen reader output, and the find bar, search fields, and pane resize handles show a visible focus outline and announce their size. * Fixed failed uploads being reported as corrupted or unsupported files, and retries showing a "Server is busy" message for unrelated errors. * Fixed safety-block notices suggesting you switch models when no alternative model was available for that topic. * Fixed the app failing to launch when its settings file or logs folder was corrupted, and saved sessions disappearing after a relaunch when one session's stored data was invalid. * Fixed the app window resizing abruptly and losing its saved size and position when signing in or out; it now animates smoothly in place. **Code** * Added iOS Simulator support: Claude Code can build your iOS app, launch the simulator, and verify the result without leaving the session. * Added iOS Simulator and Android Emulator buttons to the session titlebar when the agent launches an app on a device, so the pane is one click to reopen. * Added Pause Project, which pauses a project's coordinator and new session spawning from settings and shows a Resume banner above the composer. * Added screenshot annotation in the composer: click a staged image, open the pencil, and draw with pen, shapes, text, and colors before sending. * Improved how large sessions open: the newest messages paint first while older history loads in the background. * Fixed Code sessions affecting the wrong files: background worktree cleanup could switch or reset the main repository checkout when a worktree folder was only partially removed, and new sessions could copy uncommitted files from the original folder. * Fixed session list problems: finished sessions still showing as running, deleted sessions reappearing as empty "Session not found on disk" entries after an update, archived sessions still appearing active on claude.ai and other devices, and sessions started from claude.ai missing Rename, Archive, and Delete in the sidebar menu. * Fixed the app freezing when Claude Code updated its configuration file during concurrent use, and web pages in the Browser pane freezing the app with alert and confirm dialogs. **Cowork** * Added /usage and /cost to Cowork tasks: an inline card shows your plan limits and the session's usage without sending anything to the model. * Improved background computer use so it types faster and no longer leaves menus stuck open on screen. * Updated folder access prompts for cloud Cowork tasks to note that files Claude uses leave your device and are processed on Anthropic's servers. * Fixed changes to Instructions for Claude sometimes not applying to new sessions, and edits reverting to an earlier version while a session was running, including after an app restart. * Fixed Cowork workspace problems: the Windows workspace failing to start when its virtual disk files were compressed, a backgrounded shell command leaving a session stuck reporting "already running", and bash commands failing when several subtasks ran them at once. * Fixed the message input staying stuck in a sending state when a folder access dialog went unanswered. **3P** * Added `deploymentDisplayName` and `deploymentDisplaySubtitle` to customize the deployment name and an optional subtitle shown in the account menu and sidebar. * Added `enduserAttribution`, which shows the signed-in user's identity in the sidebar, account menu, and Code tab, and includes it as the OpenTelemetry `enduser.id` attribute on telemetry sent to your configured collector. Administrators can turn it off, and an existing static `enduser.id` is kept. * Added `oauth.authorizationUrl` and `oauth.tokenUrl` to managed MCP servers for identity providers that do not serve a discovery document, and `oauth.additionalRedirectReferrerHosts` to allow sign-in callbacks from hosts other than the authorization URL's. * Added `userContentRendererUrl`, which sets the HTTPS origin that renders artifact and file previews; leave it unset to use the default Anthropic-hosted renderer. * Added a `broker` option to `inferenceFoundryAuthFlow` that signs in to Azure AI Foundry through the operating system's native account broker on Windows or Company Portal on macOS, so sign-in can satisfy Conditional Access policies that require a compliant device. Windows and macOS only. * Added a Usage page in Settings for custom deployments, showing token usage across Chat, Cowork, and Code. * Added Microsoft 365 Teams tools (send to a chat, channel, or thread; create a chat; @mention people) and formatted-body support for Outlook reply drafts. * Added the 1M context option in the model picker for gateway-discovered models that report the capability in `/v1/models`, without requiring an `inferenceModels` entry. * Changed telemetry on bootstrap-server deployments to default to disabled until the server explicitly enables it (previously only FedRAMP hosts), and added the ability to disable error and usage reporting through bootstrap configuration. * Fixed managed MCP connectors: a server that requires authentication now opens a sign-in window even when its configuration does not explicitly enable OAuth, and an `oauth` entry with sign-in fields but a missing or empty `clientId` is now rejected at load with a clear error instead of silently attempting automatic registration. * Fixed managed MCP tool policies that block all tools by default with per-tool exceptions denying the excepted tools in Claude Code sessions. * Fixed sessions, skills, and plugins intermittently disappearing after sign-in or configuration changes. * Fixed the Claude.ai sign-in option being hidden on deployments configured with a bootstrap URL; it is now hidden only when the administrator explicitly disables the deployment mode chooser. * Fixed the bundled Microsoft 365 connector showing only an opaque tool error when its sign-in expired; it now shows an inline Reconnect card. * Fixed the token-cap setup fields so the maximum tokens per window and the token cap window hours are required together; setting only one previously produced a cap that enforced nothing. </Update> <Update label="v1.22209.3" description="2026-07-19"> **General** * Fixed sessions on Windows failing on every turn with a "Socket is closed" error when traffic passed through a corporate proxy that inspects encrypted connections, by updating the bundled Claude Code CLI to 2.1.215. Interrupted responses now retry on a fresh connection instead of ending the turn. **Code** * No user-facing changes. **Cowork** * No user-facing changes. **3P** * No user-facing changes. </Update> <Update label="v1.22209.0" description="2026-07-16"> **General** * Improved responsiveness while artifacts generate, so typing and scrolling stay smooth during generation. * Improved the "Add to project" menu to show only projects you can move into, with your own projects listed first. * Fixed rare freezes when a transcript contained very large whitespace-padded messages or tool output. * Fixed tool errors blaming an organization policy when a site was actually blocked by your own site permissions or settings. **Code** * Added controls for project owners to remove members from a shared project and copy an invite link from the members dialog. * Added per-row actions to queued messages (Edit in composer, Send now, and Remove), with right-click support. * Fixed a new session sometimes taking over the directory another session was still working in. * Fixed Code sessions hanging at startup when skill syncing was slow, and tools on your shell `PATH` staying undetected when shell environment detection timed out at startup. * Fixed freezes, a stuck "loading earlier messages" spinner, and blank rendering when scrolling back through very large session transcripts or when a running task's output grew very large. * Fixed the New session button, `⌘N` (or `Ctrl+N` on Windows and Linux), and the project header "+" discarding an unsent composer draft. **Cowork** * Improved writing drafts to consistently appear as preview cards before being staged in a connected app such as Slack. * Fixed documents Claude creates not reliably opening in the editor. * Fixed files edited by Claude sometimes reading back stale or truncated content on Windows. * Fixed the chat window freezing and not updating while Claude uses your computer. * Fixed the document editor sometimes attributing your own typing to Claude while autosaving. * Fixed working documents disappearing from the Documents panel after a temporary disk error. **3P** * Added `disableBrowserExternalNavigation`, which admins can set to `true` in Claude Code's `managed-settings.json` to keep the Code tab's Browser pane limited to localhost for both users and Claude. Local dev servers and file previews are unaffected. * Added `otlpTracesEnabled` (beta), which also exports OpenTelemetry traces from Cowork tasks and Code sessions to your configured collector. * Updated the allowed workspace folders policy to also apply to Code sessions on SSH hosts, evaluated against the folders on the remote host. * Fixed enforcement of the managed Auto mode opt-out. * Fixed plugins being treated as required by your organization when their marketplace name merely resolved under a required marketplace entry; only the exact entry a name resolves to now applies, so affected plugins can be uninstalled again. * Fixed saving a skill created in chat failing; skills now save to the app's local skill storage.
Cut at 300 lines. The page has the rest.
cowork/guide/dispatch First recorded · 94 lines, first recorded
# Run tasks in the background with Dispatch ## Prerequisites ## Start a Dispatch task ## How Dispatch routes work ## Track task status ## Approve actions Dispatch needs ## Continue from a finished task ## Assign tasks from your phone ## Related
The first capture of this source. The page was already there, and this is what it said.
# Run tasks in the background with Dispatch
> Assign work to a Dispatch agent that plans, runs, and reports on tasks while you do something else, on this computer or from your phone.
Dispatch is a long-running agent in Cowork that takes high-level instructions and carries them out in the background. You describe an outcome in a single conversation; the Dispatch agent breaks it into tasks, runs each one as a separate Cowork or Code session, and surfaces the results in the sidebar when they finish.
Unlike a normal Cowork chat, you don't watch each step. Dispatch is for work you want to start and come back to later.
## Prerequisites
Dispatch requires a Pro or Max plan and the latest Claude Desktop app on macOS or Windows.
## Start a Dispatch task
The Dispatch agent appears as **Dispatch** in the left sidebar. Selecting it opens a single conversation with the agent.
<Steps>
<Step title="Open Dispatch from the sidebar">
Select **Dispatch** in the left side panel.
</Step>
<Step title="Describe the outcome">
Tell the agent what you want done, the same way you'd brief a colleague. For
example: "Summarize the open Linear issues tagged reliability and draft a
status update for the team channel."
</Step>
<Step title="Let Dispatch plan and run">
The agent decides how to split the work and starts one or more child tasks.
Each child task appears under the Dispatch group in the sidebar with its own
status.
</Step>
</Steps>
You converse with one Dispatch agent, but it can run many child tasks beneath that conversation. Child tasks don't spawn further children of their own.
## How Dispatch routes work
The Dispatch agent routes each child task to the surface that fits it.
| Task type | Runs in | Examples |
| -------------- | -------------------------------------------------------------------------------------- | ------------------------------------------ |
| Coding work | Code, against a workspace you've already set up | Fix a bug, open a pull request, run tests |
| Knowledge work | Cowork, in the [project](/docs/cowork/guide/projects) you specify (or your default project) | Research, write a document, organize files |
When starting a task, you can tell the agent which Code workspace or Cowork project to use. If you don't, it lists what's available and chooses.
## Track task status
Each child task shows its current state in the sidebar. Select any task to open its full transcript, the steps Claude took, and any files it produced.
| State | Meaning |
| --------------- | ---------------------------------------------------------- |
| Running | Claude is actively working on the task |
| Awaiting input | The task needs information from you before it can continue |
| Awaiting answer | The task asked you a question and is waiting for a reply |
| Completed | The task finished |
| Error | The task stopped because something went wrong |
| Archived | You marked the task as done and set it aside |
## Approve actions Dispatch needs
When a child task needs permission to take an action (such as running a command or writing a file outside its workspace), the prompt is forwarded to you. If you don't respond within ten minutes, the request is automatically denied and the task continues without that action.
Permission prompts behave the same as in a normal Cowork session.
## Continue from a finished task
Select any child task in the sidebar to open its session. You can read the transcript, send follow-up messages, or ask the Dispatch agent to start a new task that builds on the result.
## Assign tasks from your phone
When Claude Desktop is running, your computer registers as a Dispatch host. From the Claude mobile app, you can start a Dispatch conversation that runs on your desktop, then check results from either device.
<Steps>
<Step title="Keep your desktop ready">
Leave Claude Desktop open with your computer awake and online.
</Step>
<Step title="Open Dispatch on mobile">
In the Claude mobile app, open Dispatch and describe the task. The work runs
on your desktop.
</Step>
<Step title="Review on either device">
Progress and results appear in the Dispatch sidebar on desktop and in the
mobile app.
</Step>
</Steps>
## Related
* [Organize work with projects](/docs/cowork/guide/projects) for the project context Dispatch routes knowledge work into
* [Cowork overview](/docs/cowork/overview) for how Dispatch fits alongside sessions and projects
cowork/guide/plugins First recorded · 96 lines, first recorded
# Install plugins ## What a plugin can contain ## Install a plugin ## Use a Git repository as a marketplace ## Limits ## Plugins managed by your organization ## Update and remove plugins ## Related
The first capture of this source. The page was already there, and this is what it said.
# Install plugins
> Add packaged skills, connectors, and agents to Cowork from the plugin marketplace or a file.
A plugin is a package that extends what Claude can do in Cowork. Installing one can add skills, MCP connectors, subagents, slash commands, or hooks in a single step. Plugins come from the marketplace, from your organization, or from a file you upload.
Plugins are available in Cowork and Code. They aren't used in Chat.
## What a plugin can contain
A plugin's manifest declares any combination of the following.
| Component | What it adds |
| ---------- | ---------------------------------------------------------- |
| Skills | Reusable instructions that teach Claude a workflow |
| Connectors | MCP servers that give Claude access to an external service |
| Agents | Specialized subagents Claude can delegate to |
| Hooks | Scripts that run at defined points in a session |
After installing, open the plugin to see what it provides. Skills and agents appear as tabs; connectors and hooks have their own pages.
## Install a plugin
Open **Customize** in the sidebar, then **Plugins**.
<Steps>
<Step title="Browse the marketplace">
Select **Browse plugins** to see available plugins. The default marketplace
is Anthropic's official catalog; you can add other marketplaces by URL.
</Step>
<Step title="Install">
Select a plugin and click **Install**. If the plugin includes a connector
that needs authentication, you're prompted to sign in.
</Step>
<Step title="Review components">
Open the installed plugin to see its skills, connectors, agents, and hooks.
Enable or disable individual components as needed.
</Step>
</Steps>
To install from a file instead, select the upload option on the Plugins page and select the plugin package.
## Use a Git repository as a marketplace
A Git repository that contains plugin packages can serve as a marketplace. This is the typical way teams distribute their own plugins without publishing to the public catalog. Repositories on GitHub (including GitHub Enterprise) are supported; public repositories on GitLab and Bitbucket also work.
<Steps>
<Step title="Add the repository">
On the Plugins page, select **Add marketplace** and enter the repository's
URL. Cowork accepts the standard `https://github.com/owner/repo` form and
the `owner/repo` shorthand for GitHub.
</Step>
<Step title="Install plugins from it">
Plugins defined in the repository appear alongside plugins from other
marketplaces. Install them the same way.
</Step>
</Steps>
Click **Update** on a marketplace to pull the latest plugins from its repository.
For administrator-managed marketplaces, see [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) in the deployment guide.
## Limits
The following are the default limits for plugin packages and marketplaces.
| Limit | Value |
| ---------------------------------- | ------ |
| Plugin package size (uncompressed) | 200 MB |
| Files per plugin package | 5,000 |
| Marketplace repository archive | 512 MB |
| Plugins per marketplace | 500 |
| Marketplaces you can add | 25 |
The in-app skill viewer previews individual files up to 1 MB. Larger files appear in the file list as "too large to preview" but are still available to Claude at runtime.
## Plugins managed by your organization
On Team and Enterprise plans, administrators can require certain plugins for everyone in the organization. Required plugins install automatically and show **This plugin is required by your organization**; you can't remove them.
For how administrators provision plugins, see [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) in the deployment guide.
## Update and remove plugins
Cowork checks for plugin updates from the marketplace they came from. If you've edited a plugin's files locally, Cowork detects the change and warns you before an update would overwrite it.
To remove a plugin you installed, open it under **Customize → Plugins** and click **Uninstall**. Organization-managed plugins can only be removed by an administrator.
## Related
* [Plugins overview](/docs/plugins/overview) for how plugins work across Claude products
* [Submit a plugin](/docs/plugins/submit) to publish your own to the marketplace
* [MCP, plugins, skills, and hooks](/docs/cowork/3p/extensions) for administrator provisioning
cowork/guide/projects First recorded · 76 lines, first recorded
# Organize work with projects ## What a project holds ## Create a project ## Work inside a project ## Cowork projects and claude.ai projects ## Archive a project ## Related
The first capture of this source. The page was already there, and this is what it said.
# Organize work with projects
> Group folders, instructions, and context into a Cowork project so Claude starts each session with the right setup.
A Cowork project collects everything Claude needs for a recurring area of work: the local folders to read and write, standing instructions, useful links, and a dedicated memory store. When you start a session inside a project, Claude is already set up with that context.
Projects live on your computer. They aren't synced to the cloud or shared with other people.
## What a project holds
Each project bundles the following, and you can change any of it after creation.
| Item | Purpose |
| ------------------ | ------------------------------------------------------------------------------------- |
| Description | What the project is for; Dispatch reads it when choosing a project for a task |
| Folders | One or more local folders Claude can read and write inside this project's sessions |
| Instructions | Standing guidance applied to every session in the project |
| Links | Reference URLs (documents, dashboards, repositories) Claude can consult |
| Projects from Chat | Projects you made in Chat (claude.ai) whose knowledge this Cowork project can draw on |
| Memory | A project-scoped memory store that persists across sessions |
## Create a project
Open **Projects** in the left navigation and choose the **+** button to start. You're offered three starting points.
<Steps>
<Step title="Choose a starting point">
Select **Start from scratch** to create an empty project with a new folder,
**Import a project** to bring an existing claude.ai project into Cowork, or
**Use an existing folder** to point at a folder you already work from.
</Step>
<Step title="Name and describe it">
Give the project a name and a short description so you can tell it apart in
the sidebar.
</Step>
<Step title="Add folders and instructions">
Attach the local folders Claude should have access to, and write any
standing instructions you want applied to every session.
</Step>
</Steps>
You can attach more folders, links, or projects from Chat at any time from the project's settings.
## Work inside a project
Select a project in the sidebar to start a new Cowork session with that project's folders mounted and instructions applied. Files Claude creates land in the project's folders; what Claude learns during the session is saved to the project's memory for next time.
[Dispatch](/docs/cowork/guide/dispatch) can also route background tasks into a project, so long-running work picks up the same folders, instructions, and memory.
When you drag files or folders into a project, individual files are copied into the project's first folder and folders are mounted as additional project folders. Claude reads individual files up to 50 MB.
## Cowork projects and claude.ai projects
A Cowork project is not the same thing as a project on claude.ai. They're stored separately and have different capabilities.
| | Cowork project | claude.ai project |
| ------------------------ | --------------------- | --------------------------- |
| Lives | On your computer only | In your Claude account |
| Holds local folders | Yes | No |
| Shareable with teammates | No | Yes, on Team and Enterprise |
You can link a claude.ai project into a Cowork project so Cowork sessions can draw on its knowledge. Linking doesn't merge them; the claude.ai project stays where it is.
## Archive a project
Archiving removes the project from your list and deletes its metadata (name, instructions, links, memory). It does not touch the local folders you attached; your files stay exactly where they are on disk.
To archive, open the project's menu in the sidebar and choose **Archive**.
## Related
* [Run tasks in the background with Dispatch](/docs/cowork/guide/dispatch) to run work inside a project without watching each step
* [Install plugins](/docs/cowork/guide/plugins) to extend what Claude can do in a project's sessions
* [Cowork overview](/docs/cowork/overview) for how projects relate to sessions and Dispatch
cowork/monitoring First recorded · 236 lines, first recorded
# Monitoring ## Setup ## Events ### Event correlation ### Standard attributes ### User prompt event ### Model response event ### Tool result event ### API request event ### API error event ### Tool decision event ## Event analysis ## Backend considerations ## Service information ## Security and privacy
The first capture of this source. The page was already there, and this is what it said.
# Monitoring > Track Cowork usage and activity across your organization with OpenTelemetry Track Cowork usage and activity across your organization by exporting events through [OpenTelemetry](https://opentelemetry.io/) (OTel). Cowork exports events via the OTel logs/events protocol, giving you visibility into user prompts, model responses, API requests, tool usage, and errors. <Note> Monitoring is available for Team and Enterprise plans. OTel monitoring requires Claude desktop app version 1.1.4173 or later. </Note> ## Setup Configure monitoring from the Cowork admin settings: 1. Navigate to **Admin settings > Cowork** 2. Configure the following fields: | Field | Description | Example | | ----------------- | ----------------------------------------- | ----------------------------------- | | **OTLP endpoint** | Your OpenTelemetry collector URL | `http://collector.example.com:4318` | | **OTLP protocol** | Transport protocol | `http/json` or `http/protobuf` | | **OTLP headers** | Authentication headers for your collector | `Authorization=Bearer your-token` | 3. Save your settings 4. Start a new Cowork session — settings are loaded at session start, so existing sessions won't pick up the new configuration <Note> The OTel exporter runs inside the Cowork VM, so it is subject to the session's egress rules. If your organization restricts network egress, Cowork automatically adds your collector's hostname to the session's egress allowlist. You don't need to add it at **Admin settings > Capabilities > Network egress**. </Note> ## Events Cowork exports the following events to your OTel collector. By default, events include metadata only. User prompt content, model response text, and tool details are included only when you enable them with the [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) setting. ### Event correlation When a user submits a prompt, Cowork may make multiple API calls and run several tools. The `prompt.id` attribute links all events back to the single prompt that triggered them. | Attribute | Description | | ----------- | ------------------------------------------------------------------------------------ | | `prompt.id` | UUID v4 identifier linking all events produced while processing a single user prompt | To trace all activity triggered by a single prompt, filter your events by a specific `prompt.id` value. On third-party deployments, you can additionally enable OpenTelemetry trace export with the [`otlpTracesEnabled`](/docs/third-party/claude-desktop/telemetry#traces-beta) setting (beta). When it is enabled, events emitted while a prompt is processed also carry `trace_id` and `span_id`, linking them to the session's trace spans for end-to-end correlation in your observability backend. ### Standard attributes All events include these attributes: | Attribute | Description | | ---------------------- | -------------------------------------------------------------------------------------------- | | `session.id` | Unique session identifier | | `organization.id` | Organization UUID | | `user.account_uuid` | User's account UUID | | `user.account_id` | Account ID in tagged format matching Anthropic admin APIs (for example, `user_01BWBeN28...`) | | `user.id` | Anonymous device/installation identifier | | `user.email` | User email | | `workspace.host_paths` | Host workspace directories selected in the desktop app (string array) | | `terminal.type` | Terminal type (`non-interactive` for Cowork) | <Note> The account attributes — `organization.id`, `user.account_uuid`, `user.account_id`, and `user.email` — are populated from the user's Anthropic account, so they appear on first-party deployments only. On [third-party deployments](/docs/third-party/claude-desktop/overview) there is no Anthropic account and these attributes are absent; instead, the export carries the signed-in user's identity as the `enduser.id` resource attribute, described under [User attribution](/docs/third-party/claude-desktop/telemetry#user-attribution). The `process.owner` resource attribute (the operating-system login name) is standard OpenTelemetry process metadata and is present on all deployments. </Note> ### User prompt event Logged when a user submits a prompt. **Event name**: `user_prompt` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `prompt_length` | Length of the prompt | | `prompt` | Prompt content | ### Model response event Logged when the model completes a response that includes text output. Requires Claude desktop app version 1.17377 or later. **Event name**: `assistant_response` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model that produced the response | | `request_id` | API request identifier | | `response_length` | Length of the response | | `response` | Model response text. Includes text output only; thinking content is excluded. Truncated to 60 KB. When model response capture is disabled, the value is the literal string `<REDACTED>`. | Model responses are captured when [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) includes `assistantResponses`, and also whenever user prompts are captured. ### Tool result event Logged when a tool completes execution. **Event name**: `tool_result` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `tool_name` | Name of the tool | | `success` | `"true"` or `"false"` | | `duration_ms` | Execution time in milliseconds | | `error` | Error message (if failed) | | `decision_type` | Either `"accept"` or `"reject"` | | `decision_source` | How the decision was made — `"config"`, `"hook"`, `"user_permanent"`, `"user_temporary"`, `"user_abort"`, or `"user_reject"` | | `tool_result_size_bytes` | Size of the tool result in bytes | | `mcp_server_scope` | MCP server scope identifier (for MCP tools) | | `tool_parameters` | JSON string containing tool-specific parameters, including `mcp_server_name` and `mcp_tool_name` for MCP tools | | `tool_input` | JSON-serialized tool arguments. Individual strings over 512 characters are truncated; entire string limited to \~4K characters. Applies to all tools including MCP tools. | ### API request event Logged for each API request to Claude. **Event name**: `api_request` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model used (e.g., `claude-sonnet-5`) | | `cost_usd` | Estimated cost in USD | | `duration_ms` | Request duration in milliseconds | | `input_tokens` | Number of input tokens | | `output_tokens` | Number of output tokens | | `cache_read_tokens` | Number of tokens read from cache | | `cache_creation_tokens` | Number of tokens used for cache creation | | `speed` | `"fast"` or `"normal"` | ### API error event Logged when an API request to Claude fails. **Event name**: `api_error` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | --------------------------------------------------------------------- | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `model` | Model used | | `error` | Error message | | `status_code` | HTTP status code as a string, or `"undefined"` for non-HTTP errors | | `duration_ms` | Request duration in milliseconds | | `attempt` | Attempt number (for retried requests) | | `speed` | `"fast"` or `"normal"` | ### Tool decision event Logged when a tool permission decision is made. **Event name**: `tool_decision` **Attributes**: All [standard attributes](#standard-attributes), plus: | Attribute | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------ | | `event.timestamp` | ISO 8601 timestamp | | `event.sequence` | Monotonically increasing counter for ordering events within a session | | `tool_name` | Name of the tool | | `decision` | Either `"accept"` or `"reject"` | | `source` | Decision source — `"config"`, `"hook"`, `"user_permanent"`, `"user_temporary"`, `"user_abort"`, or `"user_reject"` | ## Event analysis The exported events support a range of analyses: **Tool usage patterns** — Analyze tool result events to identify most frequently used tools, success rates, average execution times, and error patterns. **Cost monitoring** — Track `cost_usd` from API request events to understand usage trends across users and teams. Group by `user.account_uuid` or `organization.id` for per-user or per-team breakdowns. **Performance monitoring** — Track API request durations and tool execution times to identify performance bottlenecks. <Note> Cost values from events are approximations. For official billing data, refer to your billing dashboard. </Note> ## Backend considerations Your choice of logs backend determines the types of analyses you can perform: * **Log aggregation systems** (e.g., Elasticsearch, Loki): Full-text search and log analysis * **Columnar stores** (e.g., ClickHouse): Structured event analysis and complex queries * **Observability platforms** (e.g., Honeycomb, Datadog): Advanced querying, visualization, and alerting ## Service information All events are exported with the following resource attributes: | Attribute | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `service.name` | `cowork` | | `service.version` | Claude app version | | `host.arch` | Host architecture (e.g., `arm64`) | | `os.type` | Operating system type (e.g., `darwin`) | | `os.version` | Operating system version string | | `enduser.id` | The signed-in user's identity, on third-party deployments only. Controlled by the [`endUserAttribution`](/docs/third-party/claude-desktop/configuration#enduserattribution) setting; see [User attribution](/docs/third-party/claude-desktop/telemetry#user-attribution). | | `process.owner` | Operating-system login name | ## Security and privacy * Events are only exported when an admin configures the OTLP endpoint * User prompt content is included only when you enable `userPrompts` in [`otlpContentCapture`](/docs/third-party/claude-desktop/telemetry#content-capture) * On Claude desktop app version 1.17377 or later, model response text is included when you enable `assistantResponses` in `otlpContentCapture`, and also whenever user prompt content is included * The `tool_input` attribute (file paths, URLs, search patterns, and other arguments) is included only when you enable `toolDetails` in `otlpContentCapture` * On first-party deployments, `user.email` is always included in event attributes, so configure your telemetry backend to filter or redact it if this is a concern * On third-party deployments, `user.email` is absent; the export identifies users with the `enduser.id` resource attribute, controlled by the [`endUserAttribution`](/docs/third-party/claude-desktop/configuration#enduserattribution) setting
cowork/overview First recorded · 36 lines, first recorded
# Overview ## Key capabilities ## Extend Cowork with integrations
The first capture of this source. The page was already there, and this is what it said.
# Overview
> Learn about Cowork, Anthropic's agentic workspace
Cowork uses the same agentic architecture that powers Claude Code, accessible within Claude Desktop without opening the terminal. Rather than responding to prompts sequentially, Claude tackles intricate, multi-step tasks autonomously. Describe a desired outcome, then return later to completed work — polished documents, organized files, synthesized research, and more.
## Key capabilities
* **Works directly on your computer** — Claude reads and writes local files without requiring manual uploads or downloads.
* **Claude in Chrome** — Pair [Claude in Chrome](https://claude.com/chrome) with Cowork to automate your tasks on any website.
* **Sub-agent coordination** — Complex work gets divided into smaller tasks with parallel workstreams for faster results.
* **Professional outputs** — Creates polished deliverables including Excel spreadsheets with functional formulas, PowerPoint presentations, and formatted documents.
## Extend Cowork with integrations
Cowork supports the same extensibility features available across Claude products:
<Columns cols={2}>
<Card title="Connectors" icon="plug" href="/docs/connectors/overview">
Connect Claude to your tools and data sources using MCP.
</Card>
<Card title="Skills" icon="wand-magic-sparkles" href="/docs/skills/overview">
Teach Claude reusable workflows with custom instructions.
</Card>
<Card title="Plugins" icon="puzzle-piece" href="/docs/plugins/overview">
Bundle skills, connectors, and more into shareable packages.
</Card>
<Card title="Monitoring" icon="chart-line" href="/docs/cowork/monitoring">
Track usage and activity across your organization.
</Card>
</Columns>
You manage connectors, skills, and plugins from **Customize** in the sidebar. Cowork loads the ones enabled for your claude.ai account, synced at session start, and doesn't read the [Claude Code](https://code.claude.com/docs/en/skills) CLI's `~/.claude` directory on your machine. To use a skill or plugin that exists only in `~/.claude`, add it in **Customize**.
government/account/overview First recorded · 29 lines, first recorded
# Your account ## What's here ## The page footer ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Your account > Check your own account details, usage limits, and active sessions. > **Who this is for:** Anyone with a Claude for Government account. The Account portal is where you view your own details rather than manage other people. It covers your own identity details, your personal usage allowance, and the places you are currently signed in. Nothing you do here affects any other user. Every user has access to this portal regardless of what role they hold. If you are a regular user with no administrative role, this is also where you land immediately after signing in, and it is the only part of the web portal you will see. > **For organization owners:** You land in the organization admin area instead when you sign in. You can reach your own account pages at any time from the **Switch to user view** link in the page footer, and return the same way. ## What's here * The [**Account**](/docs/government/account/profile) tab shows who you are, including your name, email address, organization, role, and seat tier. Everything on this tab is read-only. Your name and email come from your agency's directory; your organization, role, and seat tier are set by your directory or by an administrator. * The [**Usage**](/docs/government/account/usage) tab shows how much of your personal allowance you have used in the current 5-hour and 7-day windows, and when each one next resets. If you have hit a limit and Claude is paused, this tab is marked with a pulsing indicator in the navigation so you can spot it at a glance. * The [**Sessions**](/docs/government/account/sessions) tab lists every browser and desktop application where you are currently signed in, with the option to sign any of them out remotely. ## The page footer At the bottom of every page in this portal you will find your email address and a **Sign out** button. Signing out from the footer ends the session you are currently using and, where your agency uses single sign-on, also ends your session with the identity provider so that you will be prompted for credentials the next time you visit. > **For organization owners and tenant administrators:** The footer also includes a **Switch to admin view** link that takes you back to the administrative area. ## Things to know * **Nothing here is editable.** Your name, email, organization, role, and seat tier are all set in your agency's directory or by an administrator, and they flow into Claude for Government automatically. If any of these details are wrong, the [Account](/docs/government/account/profile) page explains where each one comes from and who to contact. * **The three tabs are independent.** Looking at your usage or your sessions has no effect on the other tabs, and the Sign out button in the footer works from any of them. * **The pulsing indicator on the Usage tab is the only alert in this portal.** It appears while either of your usage limits is full and disappears on its own once the limit resets.
government/account/profile First recorded · 45 lines, first recorded
# Account ## What you'll see ## How to change these details ## If your seat tier says "No seat assigned"
The first capture of this source. The page was already there, and this is what it said.
# Account > Use this page to confirm that you are signed in as the right person and to see what access you have been given. > **Who this is for:** Anyone with a Claude for Government account. Use this page to confirm that you are signed in as the right person and to see what access you have been given. The **Account** tab is the landing page of the user area. It shows the basics of your account in one place: your name and avatar at the top, followed by four fields that describe your access. Everything on this page is read-only. The values come from your agency's identity system and from settings that an administrator controls, so this page is for checking your details rather than changing them. ## What you'll see | Field | What it means | Where it comes from | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | **Email** | The address you sign in with. It is the unique identifier for your account, and notifications such as sign-in links are sent to it. | Your agency's identity provider. | | **Organization** | The organization you belong to within your agency's tenant. A tenant is your agency's overall space in Claude for Government, and it can contain several organizations (for example, one per bureau or office). Your organization determines which administrators manage your access and which usage pool your activity draws from. | Set when your account was created or when directory sync placed you. | | **Role** | What you are allowed to manage. **User** means you can use Claude but do not administer anything. **Owner** means you can manage your organization's users, seats, and settings. **Primary Owner** is the same as Owner with a few additional safeguards: a primary owner cannot be removed by other owners, and each organization can have at most three of them. | Assigned by an organization owner or by directory sync. | | **Seat tier** | The allowance you have been given. A seat tier is a named package that sets two things for you: how much Claude usage you get (shown on the [Usage](/docs/government/account/usage) tab) and which Claude models you are allowed to use. The tiers themselves, their names, and what each one includes are defined by your agency, so the name you see here is specific to your deployment. | Assigned to you by an organization owner. | The name and avatar at the top come from your agency's directory. The avatar is generated from your name; you cannot upload a custom picture. ## How to change these details None of these fields can be edited on this page. Where to go instead depends on the field: * **Name or email.** These are owned by your agency's identity provider or directory. Update them there, and the change flows into Claude for Government automatically the next time you sign in or the next time directory sync runs. You do not need to do anything inside Claude for Government. * **Organization.** Users cannot move themselves between organizations. If you have been placed in the wrong organization, ask your organization's owner or a tenant administrator to move you. * **Role.** An organization owner can promote or demote users between **User** and **Owner** in the administrative area. Ask your organization's owner if your role needs to change. * **Seat tier.** An organization owner assigns and changes seat tiers from the administrative area. See the next section if yours is missing. <Tip> If you are helping a colleague troubleshoot, ask them to read out this page. It tells you in one screen which organization they are in, what role they hold, and whether they have a seat, which is usually enough to diagnose a "Claude is not working for me" report. </Tip> ## If your seat tier says "No seat assigned" <Note> This section only appears when you do not have a seat tier. If a tier name is shown in the Seat tier field, you can skip this section. </Note> Without a seat tier you can sign in and see the portal, but you cannot send any messages to Claude, and the [Usage](/docs/government/account/usage) tab will show "No seat tier assigned" instead of your allowance. This is the expected state for a brand-new account that has not yet been given a seat, or for an account whose seat was deliberately removed. Ask your organization's owner to assign you a seat. Once they do, the tier name appears here immediately and you can start using Claude straight away without signing out and back in. > **For organization owners:** When you view your own profile with no seat, the page links you straight to **Admin → Users** so you can assign yourself one. Owners are not given a seat automatically; administrative access and Claude usage are granted separately, so you must assign a seat to yourself the same way you would for any other user.
government/account/sessions First recorded · 54 lines, first recorded
# Sessions ## What each row shows ## What is not shown ## How long sessions last ## Signing out of other sessions ### What actually happens when you sign out another session ## If you see a session you don't recognize
The first capture of this source. The page was already there, and this is what it said.
# Sessions > Use this page to see every place you are currently signed in to Claude for Government and to sign out of any of them remotely. > **Who this is for:** Anyone with a Claude for Government account. Use this page to see every place you are currently signed in to Claude for Government and to sign out of any of them remotely. A session is created each time you sign in, whether that is in a web browser or in the Claude desktop application. This page lists your active sessions so you can confirm that nothing unexpected has access to your account, and clean up after yourself on a computer you no longer have. ## What each row shows Each row is one active sign-in. The one you are using right now is labeled **this session** and always appears at the top of the list; the rest are ordered with the most recent first. * **Client** tells you which kind of application the sign-in is for. It shows **Browser** for a web sign-in, or **Desktop app** for the Claude application installed on a computer. * **via …** tells you how that session was established. **Single sign-on** means you authenticated through your agency's identity provider. **Device pairing** means a code shown in the desktop application was entered and approved in a browser, linking that application to your account. **Email link** means a one-time link was sent to your inbox and followed to sign in. * **Signed in** tells you when the session started. The time is shown in your local time zone along with a relative hint such as "2 days ago". ## What is not shown To limit how much information about your devices is held in the system, the list deliberately does not include IP addresses, locations, device names, or browser details. You can tell a browser session from a desktop session and you can see when each one started, but you cannot tell two browser sessions apart by device. When in doubt, sign out anything you cannot positively account for; signing back in is quick. ## How long sessions last Sessions expire after a period of inactivity, and using a session extends it. Once you have been inactive for longer than the idle timeout, that browser tab or desktop application prompts you to sign in again the next time it tries to do anything. The idle timeout is set by your agency or organization; unless they have chosen a shorter value, it is 24 hours. Your agency or organization can set a maximum session length in addition to the idle timeout. When a session reaches that length, it expires even if you have been using it the whole time, and the browser tab or desktop application prompts you to sign in again. Sessions that expire either way drop off this list automatically. Sessions can also end early in three ways: you sign one out from this page, you use the **Sign out** button in the page footer to end the session you are currently using, or an administrator deactivates your account or your organization, which immediately invalidates every session you have. ## Signing out of other sessions <Note> These controls only appear when you have sessions besides the one you are using. If this is your only sign-in, the list shows just the current session and no sign-out buttons. </Note> * To end one session, select **Sign out** on its row. * To end everything except the one you are using, select **Sign out *N* other sessions** below the list. Neither of these affects the session you are currently using, and there is no confirmation prompt; the session is revoked as soon as you select the button. To sign out of the session you are using right now, use the **Sign out** button in the page footer instead. ### What actually happens when you sign out another session The sign-out is recorded the moment you select the button. The other browser or desktop application is not sent a live message, but the very next thing it tries to do (load a page, send a message, or refresh) will be refused and it will be returned to the sign-in screen. In practice this means the other session is cut off within seconds of any activity. A request that was already in flight at the instant you revoked may finish, but nothing new can start. Signing out another session from this page does not touch your agency's single sign-on session, so if the person at that other computer tries to sign back in, the identity provider may still let them straight through without re-entering a password. If that is a concern (for example, you left a shared computer signed in), sign the session out here first, then contact your agency's identity team to end the single sign-on session, or change your directory password. <Tip> Signing out here versus signing out from the footer behave differently at the identity provider. The footer **Sign out** ends both your Claude for Government session and your single sign-on session, so you will be asked for credentials the next time you visit. The per-row **Sign out** on this page ends only the Claude for Government session and leaves single sign-on alone. </Tip> ## If you see a session you don't recognize Sign it out from here right away. You can use **Sign out *N* other sessions** if you want to be certain you have cleared everything. If an unrecognized session reappears after you have done so, or anything else about the list looks wrong, report it to your organization's administrator so they can investigate through your agency's identity system.
government/account/usage First recorded · 68 lines, first recorded
# Usage ## How limits work ## When a limit fills up ## Reading the reset times ## Keeping the numbers current ## If you keep hitting limits ## If the page says "No seat tier assigned"
The first capture of this source. The page was already there, and this is what it said.
# Usage > Use this page to see how much of your Claude allowance you have used and when it refreshes. > **Who this is for:** Anyone with a Claude for Government account. Use this page to see how much of your Claude allowance you have used and when it refreshes. Check this page if Claude tells you that you have reached a limit, or if you simply want to see how much headroom you have left before you start a large piece of work. Claude Desktop does not show how much of your allowance you have used. To check, sign in to the web portal in your browser and open the **Usage** tab. ## How limits work Your seat tier (the allowance package an administrator has assigned to you) gives you two rolling windows that run at the same time: * The **5-hour window** limits how much you can use in a short burst. * The **7-day window** limits how much you can use across a whole week. Each window shows a progress bar, a percentage from 0% to 100%, and the time it next resets. The bar will never show more than 100% even if your last message pushed you slightly past the line. Both windows refill automatically on their own schedules, so you never need to do anything to get your allowance back. Usage is not counted in messages. Each message to Claude consumes an amount of your allowance proportional to how much work it takes to answer, so a short question uses very little while a long conversation or a request that produces a lot of output uses more. That is why the page shows a percentage rather than a message count. If a request to Claude fails because of a problem on the service side, the allowance it would have used is given back to you automatically. If you cancel or close a response while it is still being written, that message still counts against your allowance. ## When a limit fills up If **either** window reaches 100%, your Claude access pauses until that window resets. While paused you can still sign in, browse the portal, and review past conversations, but you cannot send new messages. When this happens, you will see a banner at the top of this page telling you which limit you have hit and when it will clear, and the **Usage** tab in the navigation is marked with a pulsing indicator so you can spot it from anywhere in the account area. If both windows happen to be full at the same time, the banner names the one that resets later, since that is the one actually holding you. <Note> The paused banner and the navigation indicator only appear while a limit is actually at 100%. Once the window resets, both disappear on their own. </Note> The page also shows your seat tier name in the top right, so you can tell at a glance which allowance you are on. Below the windows there is a **How do these limits work?** link that expands a short plain-language summary, which can be useful when walking a colleague through the page. <Tip> This page shows your personal limits only. If you are on a self-managed seat tier, your organization also draws from a shared credit balance. If that balance runs out or your organization reaches a spend cap your tenant administrator set, Claude will tell you that your organization is out of credits rather than that you have reached a limit, and nothing on this page will look full. A spent balance is resolved by Anthropic adding credits to the account. A reached spend cap clears when the rolling window moves forward or when a tenant administrator raises the cap. </Tip> ## Reading the reset times Each window can be in one of three states, and the text beneath its label tells you which: * **Resets …** means the window is running. You will see a countdown such as "in 2 hr" if the reset is less than a day away, or a date and time if it is further out. Hover over the text to see the other format. Reset times always land on the top of an hour; the clock starts from the hour in which you sent your first message in the window, so your 5-hour window always ends on a round hour rather than at an odd number of minutes. * **Starts when a message is sent** means you have not used anything in this window yet. The window has no timer at all until you send your first message, at which point the countdown starts and the percentage begins to climb. * **Resets on next request** means the window's time has already passed but you have not sent anything since. The display may still show the old percentage, but the very next message you send will clear it to 0% and start a fresh window. You are not actually limited in this state even if the bar looks full. ## Keeping the numbers current The **Last updated** line at the bottom tells you when these figures were fetched. The page does not refresh on its own while you have it open, so if you have been using Claude in another tab or in the desktop application, the numbers here can fall behind. Select the refresh icon next to **Last updated** to pull the latest figures, or simply leave the page and come back. ## If you keep hitting limits Your organization owner can move you to a seat tier with a larger allowance. The tiers that are available, and what each one includes, are defined by your agency, so ask your administrator which options exist. When an administrator changes your seat tier, the usage you have already accumulated in each window carries over; what changes is the size of the allowance it is measured against. This means the percentages on this page will jump the moment the change is made: moving to a larger tier makes the same usage a smaller share of the new allowance, so the bars drop, while moving to a smaller tier makes them rise and can put you straight into a paused state if you had already used more than the new tier allows. The windows still reset at the same times they would have before. Separately from changing your tier, an administrator can also reset your usage windows, which clears both bars to 0% immediately. This is a distinct action that an administrator takes deliberately; it does not happen automatically as part of a tier change. ## If the page says "No seat tier assigned" <Note> This message replaces the whole page and only appears when you do not have a seat. If you can see the progress bars, this does not apply to you. </Note> You do not have a seat yet, so there is no allowance to show and you cannot send messages to Claude. Ask your organization owner to assign you one. Once they do, this page will show your limits straight away without you needing to sign out and back in.
government/config/overview First recorded · 105 lines, first recorded
# How Config works ## How settings are applied ### Setting kinds ### Locks ## When changes take effect ## Working with the list ## Previewing impact ## Comparing settings across levels ### Looking up one person's settings ## Group-specific settings ### When someone belongs to more than one group ## What differs between the tenant and organization levels ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# How Config works > Understand how product settings in Claude for Government are resolved across the tenant, directory groups, and organizations, and how to find, change, compare, and lock them. > **Who this is for:** Tenant administrators and organization owners who set product behavior for the people they manage. The **Config** page in the admin portal is where you set product behavior such as the session timeout, Claude Desktop banner, product availability, and telemetry for the people you manage. The same page appears at both the tenant and the organization level, with the same list of settings, and this page explains how the two levels fit together. For the settings themselves, see [Available settings](/docs/government/config/settings). ## How settings are applied Each setting is resolved through a chain that runs from the Anthropic default, to your tenant, to each organization. Directory groups add two further levels, described under [Group-specific settings](#group-specific-settings) below. A value set at any level becomes the starting point for the levels below it. An organization that doesn't set a value uses the tenant's value, and a tenant that doesn't set a value uses the Anthropic default. When you expand a setting you can see each step of this chain, which value is currently **In effect**, where it came from, and (in the tenant view) which organizations have set their own value. ### Setting kinds Settings combine across the chain in one of three ways, and the kind is fixed per setting (you don't choose it): * A **simple value** is replaced at each level, and the most specific level that set it wins. Most settings work this way. * A **restriction** is a limit where the tightest value across all levels wins. Any level can tighten the limit but none can loosen it. For example, if the tenant sets a session timeout of 30 minutes, an organization can set 15 but cannot set 60. The value that takes effect is always the shortest one in the chain. * A **collection** accumulates entries from each level. A level can add entries to what the level above provided, or replace the list entirely. ### Locks A **lock** prevents levels below from changing a setting. When you lock a setting at your level it shows as **Enforced** to you, and levels below see it as **Managed**, which means it is read-only for them. Any value a lower level had previously set is ignored while your lock is in place, and it comes back into effect if you later remove the lock. A tenant lock makes the setting read-only for every organization. A lock you set at the organization level prevents any group-level value within your organization from taking priority over it. **Locked by Anthropic** is the **Managed** state when the lock was applied by Anthropic at the application level rather than by your own tenant. It appears on features that are not available in Claude for Government, and only Anthropic can change or unlock those settings. Settings that may contain secrets, such as telemetry headers, are never echoed back in the chain view. You see that a value is set, but not what it is. ## When changes take effect Settings that govern the admin portal, such as whether organizations may manage seat tiers, apply immediately. Settings that govern the Claude applications themselves, such as the Claude Desktop banner, product availability, and telemetry endpoint, are delivered to each member's application the next time it refreshes its configuration, which happens when the application is launched or the member signs in. You do not need to push anything, but members who are currently running the application may need to restart it to pick up a change. Lowering the session idle timeout applies to new sign-ins only, and so does raising or removing the maximum session length. Lowering the maximum session length, or setting one for the first time, also reaches members who are already signed in, taking up to one idle timeout period to do so, as described under [Maximum session length](/docs/government/config/settings#maximum-session-length). ## Working with the list Settings are grouped by category in the sidebar on the left. Select a category to see its settings; the number beside each category shows how many settings it contains. Each setting appears as an expandable card showing its name, a one-line description, which products it applies to, its current value, and where that value comes from (for example, **From Anthropic default** or **Set at tenant**). Click a card to expand the full chain and the editor. The scope bar above the list shows which level you are editing and lets you switch between levels when you have access to more than one. Use **Compare config across levels** to see every setting side by side across the full chain. To change a setting, expand it, adjust the value, and save. To remove your value and return to whatever the level above provides, reset it. ## Previewing impact After you change a setting at the tenant level, a **Preview impact** button appears next to **Save changes**. Select it to see a table listing every organization with its current effective value and what it would become after your change. Organizations where nothing would change are marked **unchanged**. This is especially useful when locking a setting, so you can see which organizations currently have a different value that your lock will take priority over. Preview isn't available for settings whose values are hidden for security reasons (for example, settings that can contain authorization tokens). For those settings the preview shows whether a value is set rather than what it is. <Note> **Preview impact** is available at the tenant level because it shows the effect of a tenant change across every organization. It does not appear at the organization level. </Note> ## Comparing settings across levels Select **Compare config across levels** at the top of the Config page to open a read-only table that lays every setting out side by side across the full chain. This view is for understanding how a value got to be what it is, and for spotting which levels have set their own value for which settings. You can't change anything from here; each row has an **Edit** link that takes you back to that setting on the main Config page. The table has one row per setting and one column per level in the chain: the **Anthropic default**, your **Tenant**, **Groups** (tenant-wide group settings), each **Organization** you can see, **Org groups** (group settings scoped to one organization), and the **Final value** that actually takes effect. A dash means that level has not set a value for that setting. A lock icon next to a value means that level has locked it, and anything below it in the chain is ignored. Use the **All levels** / **Final only** toggle to hide the middle columns and show just the setting, where it was set, and the final value. Before you pick a person, the **Groups** and **Organization** columns list every group and organization that has set its own value for that setting, so you can see at a glance where different values have been set across the levels you can see. ### Looking up one person's settings Type a name into the search box above the table to see exactly what settings apply to that person. The table re-resolves every setting from that person's point of view: the **Groups** column shows the value from the one group that applies to them (with any lower-priority groups they belong to shown faded, since those do not count), the **Organization** column shows their organization's value, and the **Final value** column shows what they actually get. A summary card above the table lists the tenant, group, and organization being used for the lookup. Click any row to expand a plain-English explanation of how the final value was reached, for example "Anthropic's default is On. Your tenant hasn't changed it. The Program-Reviewers group sets this to Off." This is the quickest way to answer a question like "why is this turned off for this person?" or "why can't this person use Code in Claude Desktop?" ## Group-specific settings In addition to setting values for your whole tenant or organization, you can set values for the members of a directory group. A directory group is a group that your identity provider has pushed to Claude for Government over SCIM, as described on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page. There are two kinds of group level: * **Tenant-wide group settings** sit between the tenant and the organization in the chain. A value set here takes priority over the tenant default for the group's members, in every organization they belong to. Tenant administrators manage these. * **Organization group settings** are scoped to one organization. A value set here applies only to people who are both a member of the group and a member of that organization, and it is the most specific level in the chain. Organization owners manage these for their own organization and see the same list of groups the tenant does. To edit settings for a group, open the scope bar above the settings list and choose the group's name from the dropdown. The page switches to show the same settings editor, now scoped to that group. Editing, saving, resetting, and locking all work the same way as at the other levels. Anything locked at a higher level still shows as **Managed** here and cannot be changed. ### When someone belongs to more than one group Only one group's settings apply to any given person. When someone is a member of more than one group, the settings from their highest-priority group that has any configuration are used, and the other groups are ignored for that person. The priority order is set by a tenant administrator on the [Identity and access](/docs/government/tenant-admin/identity-and-access) page by dragging the groups into the order they want. The same priority order is used wherever configuration is resolved for a person; seat-tier group mappings on the [Provisioning](/docs/government/org-admin/provisioning) page use a separate fixed order. At the organization level the priority order is shown for reference and cannot be reordered there. If no groups appear in the scope bar dropdown, none have been synced from the identity provider yet. Connect SCIM on the Identity and access page and push groups from your directory, and they will appear automatically. <Note> Two settings, **Organization instructions** and **Organization Analytics connector**, can be set at the tenant and organization levels but not at either group level. </Note> ## What differs between the tenant and organization levels The Config page shows the same list of settings at both levels, and almost all of them can be set at either level. The genuine differences are: * **Two settings can be set only by a tenant administrator.** [Let organizations manage their own seat tiers](/docs/government/config/settings#let-organizations-manage-their-own-seat-tiers) and [Compliance API](/docs/government/config/settings#compliance-api) appear on both pages, but are always read-only at the organization level. * **Preview impact appears only at the tenant level.** See [Previewing impact](#previewing-impact) above. * **Group priority is set at the tenant level.** Organization owners see the priority order for reference but cannot change it. * **Tenant administrators can open any organization's Config page** and act on that organization's behalf. Organization owners see only their own organization. * **Inherited plugins are labeled at the organization level.** Plugins the tenant has added appear under a **From levels above** heading on the organization page; see [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). For more detail see [Config at the tenant level](/docs/government/tenant-admin/configuration) and [Config at the organization level](/docs/government/org-admin/configuration). ## Things to know * Some settings can only be changed by tenant administrators (and not by organization owners at all), regardless of whether they are locked. These are noted in the [Available settings](/docs/government/config/settings) descriptions. * Resetting a setting removes only that level's value. Values set at other levels are unaffected and remain in effect once yours is gone.
government/config/plugins-and-connectors First recorded · 69 lines, first recorded
# Manage plugins and connectors ## Plugins versus connectors ## Plugin archive formats ### What a plugin archive can contain ## Plugins that run code ## Install behavior ## Where plugins are added ## Update or remove a plugin ## Connector tool policies for members
The first capture of this source. The page was already there, and this is what it said.
# Manage plugins and connectors > Choose between plugins and connectors in Claude for Government, prepare plugin archives for upload, decide how plugins install for members, update and remove plugins, and understand how connector tool policies apply to members. > **Who this is for:** Tenant administrators and organization owners who deliver plugins and connectors to the members they manage. You add plugins on the **Plugins** card and connectors on the **Connectors** card of the **Config** page in the admin portal. The card controls themselves are described under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards), and this page covers the tasks around them, from choosing between a plugin and a connector to keeping plugins up to date. To distribute skills to members, bundle them in a plugin, as described under [Skills for administrators](/docs/government/desktop/skills#skills-for-administrators). ## Plugins versus connectors A 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. A 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. ## Plugin archive formats The **Plugins** card accepts a single `.zip` file. The file can be one plugin package or a marketplace archive that holds several plugins, such as the downloaded ZIP of a repository that publishes a set of plugins. A single plugin package can be up to 10 MB, and a marketplace archive can be up to 15 MB. When you upload a marketplace archive, the preview lists the plugins it found, and you select which ones to add. Only plugins whose files are packaged inside the archive are added, so an entry in the marketplace listing that points to a plugin hosted elsewhere is skipped. The plugins you add from one archive are grouped under a **Tag**, prefilled from the marketplace's name, which lets you identify the set later. To refresh the set, upload a new version of the same marketplace archive with the same **Tag**. The preview lists any plugin you added from that marketplace before that the new version no longer contains, and you can remove those plugins in the same step. ### What a plugin archive can contain A plugin package is laid out around a manifest at `.claude-plugin/plugin.json`. The [plugins reference](https://code.claude.com/docs/en/plugins-reference) describes the general plugin format. Claude for Government accepts the narrower set described here, so a package that follows only the general reference can be rejected. The manifest is a JSON object, saved as UTF-8 without a byte-order mark, which some Windows editors add unless told otherwise. It has two required keys. `name` becomes the plugin's identity everywhere it appears, in lowercase letters, digits, hyphens, and underscores, up to 64 characters and starting with a letter or digit. `version` is 1 to 64 characters. Add a short `description` for the preview and the plugin's row. Uploading an archive whose name matches a plugin you already added replaces that plugin, whatever the two versions say. Content sits in a fixed set of folders, all lowercase and case-sensitive: `skills/`, `commands/`, `agents/`, `hooks/`, and `monitors/`, plus `.claude-plugin/` for the manifest and an optional `icon.png`. Each folder accepts specific file types. `commands/` and `agents/` take `.md` files, `hooks/` and `monitors/` take `.json` files, and `skills/` takes six text formats (`.md`, `.txt`, `.json`, `.yaml`, `.yml`, `.csv`). The root can also hold `README.md`, `LICENSE`, `LICENSE.txt`, `CLAUDE.md`, `CONNECTORS.md`, and `.mcp.json`. Other text files in those six formats, at the root or in folders of your own, are accepted but not used by Claude. Any other file type, anywhere in the archive, is rejected. Apart from the optional icon, everything in an archive must be text in UTF-8. There is no way to ship a script, or any other binary asset such as an image, through the card, which is narrower than what members can add to skills on their own devices. File and folder names must be ASCII. Nothing in the archive may start with a dot apart from `.claude-plugin/` and a root `.mcp.json`: repository files such as `.github/` or `.gitattributes` must be left out, while `.gitignore` and `.DS_Store` are dropped for you. Paths inside the zip must use forward slashes: File Explorer's **Compress to ZIP file**, 7-Zip, `tar.exe`, PowerShell 7, and Python's `zipfile` all write them, while Windows PowerShell 5.1's `Compress-Archive` can write backslash paths, which the upload rejects. A zip that wraps everything in one top folder, which is what zipping the plugin folder or downloading a repository as a ZIP produces, works, as long as the repository holds no other dot-prefixed files. The upload looks inside the wrapper. Apple's `__MACOSX/` folders are dropped quietly too, and an archive can hold up to 50 MB of uncompressed content. Inside `skills/`, each skill is one folder holding a `SKILL.md` whose frontmatter `name` matches the folder name, with any reference files beside it. A bare skill archive, such as a zip of just the skill folder or a `.skill` file from Claude Desktop, is not a plugin: add the manifest and move the folder under `skills/` to convert it. For the path from writing a skill to delivering it, see [Building and deploying your own skills](/docs/government/desktop/skills#building-and-deploying-your-own-skills). In a marketplace archive, each plugin sits in its own subdirectory, and the marketplace listing points at those subdirectories. A listing entry whose source is the archive root itself, `./`, is not supported and adds nothing, so for a repository laid out as a single plugin with its own marketplace file, remove the marketplace file and upload it as one plugin. A package is marked **Runs code** when it declares components that can run code on members' machines. That means any file under `hooks/` or `monitors/`, a `.mcp.json` at the root, or a manifest key that declares them, such as `hooks` or `mcpServers`. The keys the upload recognizes as descriptive are `name`, `version`, `description`, `author`, `displayName`, `keywords`, `homepage`, `repository`, `license`, and `icon`. Any other key turns the marker on. ## Plugins that run code The 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. The 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. Treat 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. ## Install behavior Each plugin on the **Plugins** card has an install behavior that you set when you add it and can change later on its row. **Auto-install** installs the plugin on every member's Claude Desktop without the member doing anything. **Members choose** offers the plugin to members, who install it themselves from their organization's plugins in Claude Desktop, as described in [Plugins in Claude Desktop](/docs/government/desktop/plugins). You do not need to push anything for a plugin to reach members. Claude Desktop syncs your organization's plugin list when it starts and periodically while it runs, so an auto-installed plugin appears on its own, and a member who already has the application open receives it at the next sync. A member can remove a plugin you installed automatically, and it stays removed for that member. In Claude Desktop, members can also add plugins of their own, by uploading a plugin file or having Claude create one, as described in [Plugins in Claude Desktop](/docs/government/desktop/plugins). Those plugins are separate from the ones you add and do not appear on the **Plugins** card. ## Where plugins are added Plugins are added at the tenant or organization level. Plugins the tenant adds flow to every organization and appear on each organization's **Plugins** card under **From levels above**, as described under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). A tenant administrator can lock the plugin list, which makes it read-only for organizations, following the lock behavior in [How Config works](/docs/government/config/overview#locks). [Group levels](/docs/government/config/overview#group-specific-settings) inherit the plugins of their tenant or organization, so the **Plugins** card is read-only when you view a group. ## Update or remove a plugin To update a plugin, upload the new version's archive. Because its name matches the plugin you added, the upload updates that plugin, the preview marks the update before you save, and members who have the plugin receive the new version automatically. To remove a plugin, click its remove icon and save the change. Removing a plugin stops delivering it, and there is not currently a way to uninstall a plugin remotely from members' devices, so members who already installed it keep their copy until they remove it themselves, as described under [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). ## Connector tool policies for members You add and edit connectors on the **Connectors** card, and for each one you choose the products that receive it and set a policy for each of its tools. See [Connectors](/docs/government/connectors/overview) for the three-step wizard. On Claude Desktop, that tool policy shapes what members experience. A tool you switch off is blocked, so Claude cannot use it. A tool you switch on is available and asks the member on every use, and members are not offered a lasting approval for it. A tool you do not list is left to the member to turn on or off, and its approval prompts follow the member's own choices, which can include lasting approval unless your organization turns that off.
government/config/settings First recorded · 117 lines, first recorded
# Available settings ## Settings list ### Session idle timeout ### Maximum session length ### Let organizations manage their own seat tiers ### Compliance API ### Telemetry endpoint (Claude Desktop) ### Telemetry headers (Claude Desktop) ### Claude Desktop banner ### Product availability ### Allowed network hosts ### Allowed workspace folders ## Tool and connector cards
The first capture of this source. The page was already there, and this is what it said.
# Available settings > Reference for the product settings on the Config page in Claude for Government, including session timeout, maximum session length, telemetry, Claude Desktop banner, product availability, and the tool and connector cards. > **Who this is for:** Tenant administrators and organization owners who set product behavior for the people they manage. This page describes the settings on the **Config** page in the admin portal. Each setting is written once here and can be set at both the tenant and organization level unless noted otherwise. For how the levels combine, what locking does, and how to compare and preview, see [How Config works](/docs/government/config/overview). ## Settings list ### Session idle timeout Controls how long a member can stay inactive before being signed out. The value must be a whole number of minutes, 15 or higher, and the Anthropic default is 1440 minutes (24 hours). A lower value applies at the next sign-in; a higher value applies on the next request. This is a restriction, so each level can shorten the timeout but not lengthen it past what the level above allows, and the value that takes effect is always the shortest one in the chain. ### Maximum session length Controls how long a member can stay signed in before they have to sign in again, even if they are active the whole time. The value must be a whole number of minutes from 60 to 525,600 (365 days), and by default there is no maximum. The maximum is an absolute limit on a session's lifetime that is independent of the session idle timeout, and a session ends as soon as it reaches either limit. This is a restriction, so each level can set or shorten the maximum but not lengthen it past what the level above allows, and the value that takes effect is always the shortest one in the chain. A shorter maximum, or a new maximum where there was none before, also applies to members who are already signed in. Open sessions pick up the change while the member is active rather than instantly, so allow up to one session idle timeout period (24 hours by default) for it to reach everyone who is currently signed in. Any session that has not picked it up by then has already expired from inactivity. The maximum always counts from when the member originally signed in, so a session that is already older than the new maximum ends when it picks up the change and the member is prompted to sign in again. A longer maximum, or resetting the setting to remove a maximum set at your level, applies only at each member's next sign-in. Sessions that are already open keep the limit they already have, and raising or removing the maximum does not restore sessions that a shorter value has already shortened or ended. When a session ends because it reached the maximum, the member signs in again, just as they do after the idle timeout. Your identity provider decides whether that sign-in asks the member to authenticate again (for example with a password, a multi-factor prompt, or a PIV card) or passes them straight through, according to its own session and re-authentication policy. Examples of that policy are the sign-in frequency control in Microsoft Entra Conditional Access and authentication policies in Okta. If you want members to authenticate again when they sign back in after reaching the maximum, set your identity provider's re-authentication interval to no longer than the maximum session length. ### Let organizations manage their own seat tiers Controls whether organization owners may create and edit self-managed seat tiers on the [Tiers](/docs/government/org-admin/seat-tiers) page, in addition to the Anthropic-managed ones. Only tenant administrators can change this setting; it is always read-only at the organization level, and organization owners cannot grant themselves the capability. When it is off, the **New seat tier** button and the edit and delete controls on the Tiers page are hidden, and the **Reset usage limits** action on the [Users](/docs/government/org-admin/users) page is also unavailable. <Note> **Set at the tenant level only.** This setting is read-only for organization owners. </Note> ### Compliance API Controls whether the [Compliance API](/docs/government/org-admin/compliance-api) is available. When it is off, organization owners cannot create new keys and every request to the API returns an error, including requests made with keys that were valid before. Listing and revoking existing keys remains available even when this is off, so that a disabled organization can still revoke an exposed key. <Note> **Set at the tenant level only.** This setting is read-only for organization owners. </Note> ### Telemetry endpoint (Claude Desktop) The base address of the collector where Claude Desktop sends usage telemetry using the [OpenTelemetry](https://opentelemetry.io/) protocol (OTLP), for example `https://otel-collector.example.gov:4318`. Claude Desktop appends the OTLP request paths `/v1/logs` and `/v1/metrics` itself, so enter the address without those suffixes. Leaving the value empty disables telemetry. The value must begin with `https://` and may include a port and a path prefix. Its host must be a hostname or a private-network address, and a public IP address is refused. A matching **Telemetry endpoint (Claude for Microsoft 365)** setting covers that product. Point this address at a receiver that accepts OTLP over HTTP in both its protobuf and JSON encodings. An [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) does this by default and conventionally listens for OTLP over HTTP on port 4318. If your logging or SIEM platform accepts only its own HTTP ingestion format, run an OpenTelemetry Collector that receives OTLP and forwards to that platform, and enter the collector's address here. Claude Desktop on each member's device connects to this address itself rather than through the Claude for Government service. The collector must therefore be reachable from your members' networks and must present a TLS certificate that their operating system trusts. Members pick up a new or changed endpoint the next time they start Claude Desktop. From then on your collector receives OpenTelemetry logs and metrics for each member's activity under three `service.name` values: * `cowork` for Chat and Cowork activity * `claude-code-desktop` for Code sessions * `claude-desktop` for error events from the application itself Each conversation turn produces events such as `user_prompt`, `api_request`, and `tool_result` that record the model, token counts, durations, and tool names. Every record also carries the member's operating-system login name as the `enduser.id` and `process.owner` resource attributes. Message text, file contents, and tool output are not included. See the [event reference in Monitoring](/docs/cowork/monitoring#events) for each event's attributes. Claude Desktop keeps working when the collector refuses requests or cannot be reached, and members see no error. To confirm telemetry is arriving, check your collector's own request logs or metrics for requests to `/v1/logs` after a member has restarted Claude Desktop and sent a message. ### Telemetry headers (Claude Desktop) Headers that Claude Desktop sends with every telemetry request, typically the credential your collector requires. Leave the setting empty if your collector does not require one. Because the value may contain a secret, it is never displayed after you save it; you see only that it is set. Write each header as `Name=value`, for example `Authorization=Bearer <token>`. To send more than one header, separate them with commas, as in `Authorization=Bearer <token>,X-Tenant=agency`. Because the comma is the separator, a header value itself cannot contain one. Spaces and `=` characters within a value are fine. ### Claude Desktop banner A persistent banner shown at the top of Claude Desktop. You can set the text, colors, and an optional link, and preview the result as you edit. Banner text may be up to 200 characters, leading and trailing spaces are rejected, colors must be valid hex codes, and the link (if set) must begin with `https://`. An empty banner is valid and simply hides it. The system-use notification shown at sign-in is separate from this banner. It is fixed text and cannot be edited. Use the Claude Desktop banner setting if you need a configurable message inside the application. ### Product availability A group of separate switches that control which Claude products and features are available to members. Each switch appears as its own row: **Claude Desktop**, **Chat in Claude Desktop**, **Advanced file analysis in Chat**, **Cowork in Claude Desktop**, **Code in Claude Desktop**, **Claude Code**, and **Claude for Microsoft 365**. All are on by default. Turning a switch off makes that product or feature unavailable. The **Chat in Claude Desktop**, **Cowork in Claude Desktop**, and **Code in Claude Desktop** switches each make one part of the app available to members. Chat is for simple conversations, Cowork is for longer tasks that Claude works through on its own in a local workspace folder, and Code is for software development. The **Claude Code** switch is separate and controls the standalone Claude Code command-line tool. When Chat and Cowork are both available, Claude Desktop presents them together as **Home** in its sidebar, next to **Code**. From Home, a member chooses **Chat** or **Cowork** in the message box, and the sidebar lists their chats and tasks together. Turning a switch off also changes this layout. For example, with **Chat in Claude Desktop** off, the sidebar shows **Cowork** in place of Home and the message box offers no choice, and with **Cowork in Claude Desktop** off, the message box offers Chat only. If Chat, Cowork, and Code are all turned off, Claude Desktop keeps Cowork on. There is no setting that chooses what Claude Desktop opens to, or whether the message box starts on Chat or Cowork. <Note> This layout applies to Claude Desktop 1.26832.0 and later. Earlier versions show **Chat**, **Cowork**, and **Code** as three separate tabs, controlled by the same switches. </Note> ### Allowed network hosts A list of hostnames that tools in Claude Desktop may reach, for example to install packages or fetch web pages. This covers the tools Claude uses during Cowork tasks, web fetch in Chat, and the sandboxed shell commands of Code sessions on macOS. For how the list applies to Code sessions on each operating system, see [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop). The connection to Claude is always allowed and does not need to be listed. An empty list shows as **Claude connection only**. Use **Add package registries** to add npm, PyPI, GitHub, crates.io, and other common registries so that Claude can install libraries; hosts added this way appear together as a single **Package registries** pill with a count. This list does not cover addresses on your private network, direct IP addresses, or Web search, so do not rely on it alone to restrict network access. ### Allowed workspace folders Controls which folders members can pick as a project folder in Claude Desktop, and where Claude can read and write files. Leave it unset to allow any folder. Add folder paths to limit members to those locations, or check **Block all workspace folders** to allow none, in which case Claude can still work in Chat and Cowork in folders it creates inside its own sandbox. A Code session starts only in a folder this setting permits, and [Code in Claude Desktop](/docs/government/security/security-and-data-handling#code-in-claude-desktop) describes how the setting applies to Code sessions on each operating system. You can list Windows and Mac paths together, and each device uses only the paths for its platform. An unset value shows as **Any folder** and an empty list shows as **No folders**. ## Tool and connector cards Alongside the settings list, the Config page shows cards for the built-in tools (Web search, Web fetch, and Shell commands), the built-in connector (Microsoft 365), a **Connectors** card for the ones you add yourself, and a **Plugins** card for plugin packages you upload. A connector is an integration that lets Claude reach an external service on a user's behalf. The **Web search** card controls whether Claude can search the web in Claude Desktop. It is off by default. When you turn it on you are shown a short description of how search works and asked to acknowledge it before the setting is saved. A **Require approval for each search** sub-setting sits below the toggle and becomes available once web search is on; it is on by default, and turning it off lets each member choose whether to approve every search or allow searches to run automatically. The **Web fetch** card controls whether Claude can fetch web pages in Claude Desktop. It is on by default, and fetches are subject to the Allowed network hosts list above. A **Require approval for each fetch** sub-setting sits below the toggle. Turning it on asks the member to approve every page fetch before it runs; when it is off (the default), each member chooses whether to approve fetches or allow them automatically. The **Shell commands** card controls whether Claude can run shell commands during tasks in Claude Desktop. It is on by default, and turning it off also turns off Advanced file analysis in Chat. A **Require approval for each command** sub-setting sits below the toggle. Turning it on asks the member to approve every shell command before it runs; when it is off (the default), each member chooses whether to approve commands or allow them automatically. Chat always asks before each command regardless of this setting. The **Microsoft 365** card lets members reach your agency's Microsoft 365 content, including SharePoint, OneDrive, Outlook, and Teams, from Claude Desktop. Each member signs in with their own Microsoft account. Enter the **Tenant ID** and **Client ID** from an application you register in Microsoft Entra, choose the **Azure cloud** your Microsoft tenant is in, and select which Microsoft Graph permissions to allow under **Access**. The connector is off while Tenant ID and Client ID are both blank. See [Set up the Microsoft 365 connector](/docs/government/connectors/microsoft-365) for the full walkthrough. The **Connectors** card lists the Model Context Protocol servers you have added for your own systems. Each connector is defined once and applied to the products you choose. See the [Connectors](/docs/government/connectors/overview) page for how to add and manage them. The **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. Click **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. Each 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. At the organization level, plugins the tenant has added appear under a **From levels above** heading with an **Inherited from your tenant** badge. You can see them there but cannot change or remove them. Upload a plugin with the same name at your organization level to take priority over one. <Tip> The Claude for Government deployment may include additional settings that are not listed above. Any extra setting follows the same chain, status badges, and edit and reset behavior. </Tip>
government/connectors/microsoft-365 First recorded · 197 lines, first recorded
# Set up the Microsoft 365 connector ## Before you start ## Register an application in Microsoft Entra ### If your Microsoft tenant is in a US Government cloud ### Allow outbound network access ## Configure the connector on the Config page ## Choose which Microsoft 365 permissions to allow ### Read access ### Read access requiring administrator approval ### Write access ## What members see ### Brokered sign-in requirements ## Common problems ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Set up the Microsoft 365 connector
> Register an application in your Microsoft Entra tenant so that Claude Desktop can read your agency's Outlook, OneDrive, SharePoint, and Teams content on each member's behalf.
> **Who this is for:** Organization owners and tenant administrators who want Claude to reach their agency's Microsoft 365 content, and who can register an application in Microsoft Entra ID (or can work with someone who can).
The Microsoft 365 connector lets Claude read and search your agency's Outlook mail and calendar, OneDrive and SharePoint files, and Teams chat from Claude Desktop. The connector runs locally on each member's machine: when a member signs in with their own Microsoft account, Claude Desktop calls Microsoft Graph directly from their device, so those calls and the member's sign-in tokens stay between their device and Microsoft and never pass through any Anthropic service. What Claude reads into a conversation is then handled like anything else the member sends to Claude.
Because each member signs in individually, Claude can only reach content that the signed-in member can already open in Microsoft 365. Your existing Microsoft 365 permissions, sharing rules, and Conditional Access policies apply unchanged.
Setup has two parts. First, someone with administrator access in Microsoft Entra ID registers an application in your Microsoft tenant. Then you enter that application's details on the **Microsoft 365** card on the [Config](/docs/government/org-admin/configuration) page.
## Before you start
You need someone with the **Cloud Application Administrator**, **Application Administrator**, or **Global Administrator** role in your Microsoft Entra tenant. That person registers the application and approves the Microsoft Graph permissions for your whole tenant. If that isn't you, send them the [Register an application in Microsoft Entra](#register-an-application-in-microsoft-entra) section below; you can fill in the Config page form once they send you the two IDs.
Open the [Config](/docs/government/org-admin/configuration) page in another tab and find the **Microsoft 365** card. You'll paste two values from Entra into it at the end.
## Register an application in Microsoft Entra
<Steps>
<Step title="Create the app registration">
1. In the [Microsoft Entra admin center](https://entra.microsoft.com), open **App registrations** from the left navigation and select **+ New registration**.
2. Enter a display name, for example "Claude for Government Microsoft 365".
3. Under **Supported account types**, choose **Single tenant only - \{your organization}**. Older versions of the portal label this option **Accounts in this organizational directory only (Single tenant)**.
4. Leave **Redirect URI** blank for now, and select **Register**.
</Step>
<Step title="Add the redirect URIs">
On the new application's left navigation, go to **Manage** > **Authentication** and open the **Redirect URI configuration** tab (on older versions of the portal, select **+ Add a platform** instead).
1. Select **Add redirect URI**. In the sidebar, choose the **Mobile and desktop applications** card (the Windows, UWP, and Console card, not the iOS/macOS card).
2. Leave the suggested redirect URIs unchecked. In the **Custom redirect URIs** box, enter `http://localhost` and select **Configure**.
3. Close the sidebar. A **Mobile and desktop applications** section now appears on the Authentication page. Select **Edit** on that section, and in the empty box that appears under `http://localhost`, enter each of the two broker redirect URIs below (a new empty box appears after you enter each one). Replace `APPLICATION_CLIENT_ID` with the **Application (client) ID** shown on the application's Overview page, and select **Save** at the top when done.
```text theme={null}
ms-appx-web://Microsoft.AAD.BrokerPlugin/APPLICATION_CLIENT_ID
msauth.com.anthropic.claudefordesktop://auth
```
The `http://localhost` URI is the standard loopback redirect for browser sign-in. When a member signs in through their browser, Microsoft Entra sends the response to a temporary listener on the member's own machine, so it never leaves the device. The other two URIs let Claude Desktop sign in through the operating system's account broker on Windows and macOS devices that meet the [brokered sign-in requirements](#brokered-sign-in-requirements). Brokered sign-in carries the device-identity claim that Conditional Access policies such as **Require compliant device** evaluate, so register all three now even if you are not sure you need them.
<Note>
All three URIs must be under **Mobile and desktop applications**, not **Web**. Registering them as **Web** causes Entra error `AADSTS50011` at sign-in. After you save, Entra may display the `msauth.com.anthropic.claudefordesktop://auth` URI under a separate **iOS/macOS** section. That's expected, since both sections are public-client platforms. To double-check, open **Manage** > **Manifest** and confirm the three URIs appear under `publicClient.redirectUris` rather than `web.redirectUris`. If the list also contains `msauth.com.anthropic.claudefordesktop.helper://auth`, remove that entry. Claude Desktop does not use it.
</Note>
</Step>
<Step title="Allow public client flows">
Still under **Authentication**, find **Allow public client flows** (on the **Settings** tab under **Web and SPA settings**, or under **Advanced settings** on older versions of the portal), set it to **Yes**, and select **Save**.
This tells Microsoft Entra that the application runs on end-user devices and does not hold a secret. Claude Desktop signs in as a public client with no client secret, and with this setting off, brokered sign-in on managed devices fails with Entra error `AADSTS7000218`.
<Warning>
Setting **Allow public client flows** to **Yes** also permits the device-code sign-in flow, which attackers can abuse for phishing. To close that path, apply a tenant Conditional Access policy that blocks the device-code authentication flow. Scope the policy to **All resources**, not to this app registration, because Conditional Access evaluates the resource a token is requested for rather than the requesting client.
</Warning>
</Step>
<Step title="Add and approve Microsoft Graph permissions">
On the application's left navigation, go to **Manage** > **API permissions**.
1. Select **+ Add a permission** > **Microsoft Graph** > **Delegated permissions**.
2. Add `User.Read` (under **User**) and `offline_access` (under **OpenId permissions**). `User.Read` is usually already listed on a new application, so leave it in place. The connector always requests these two at sign-in, so they must be approved regardless of what you select under **Access** later.
3. Add every permission you plan to select under **Access** on the Config page. At minimum, add the eight Default permissions (`Mail.Read`, `Mail.Read.Shared`, `Calendars.Read`, `Calendars.Read.Shared`, `Files.Read.All`, `Sites.Read.All`, `Chat.Read`, `OnlineMeetings.Read`), since those are pre-selected on the Config page. See [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow) for what each one does and for the optional write permissions.
4. Select **Add permissions**.
5. Select **Grant admin consent for \{your tenant name}** and confirm.
The **Grant admin consent** step approves these permissions once for every member of your Microsoft tenant, so individual members are not asked to approve them again when they sign in. Until you complete this step, members see Entra error `AADSTS65001` at sign-in (or, on tenants that allow members to approve permissions themselves, a per-member consent prompt).
<Note>
A delegated permission lets the application act on a member's behalf, limited to whatever that member can already do. It does not let Claude see content the member cannot see. For example, granting `Files.Read.All` lets Claude read files the signed-in member can open, not every file in your tenant.
</Note>
</Step>
<Step title="Copy the two IDs">
On the application's **Overview** page, copy the **Application (client) ID** and the **Directory (tenant) ID**. You'll paste both into the Config page when you [configure the connector](#configure-the-connector-on-the-config-page).
</Step>
</Steps>
### If your Microsoft tenant is in a US Government cloud
Microsoft 365 GCC (the standard Government Community Cloud) uses the commercial Microsoft Entra service, so follow the steps above unchanged and leave **Azure cloud** set to **Commercial** when you [configure the connector on the Config page](#configure-the-connector-on-the-config-page).
GCC High and DoD tenants use the Azure Government cloud instead. Register the application at `https://entra.microsoft.us` (or `https://portal.azure.us`) rather than `entra.microsoft.com`, and select the matching **Azure cloud** value when you [configure the connector on the Config page](#configure-the-connector-on-the-config-page). Claude Desktop then signs in at `login.microsoftonline.us` and calls `graph.microsoft.us` (or `dod-graph.microsoft.us` for DoD) instead of the commercial hosts.
### Allow outbound network access
The connector calls Microsoft directly from each member's device, so devices need outbound HTTPS access to the Microsoft Entra and Microsoft Graph hosts for your cloud.
| Azure cloud | Sign-in host | Microsoft Graph host |
| ---------------------- | --------------------------- | ------------------------ |
| Commercial | `login.microsoftonline.com` | `graph.microsoft.com` |
| US Government GCC-High | `login.microsoftonline.us` | `graph.microsoft.us` |
| US Government DoD | `login.microsoftonline.us` | `dod-graph.microsoft.us` |
No outbound access to any Anthropic host is needed for the connector's Microsoft 365 calls.
## Configure the connector on the Config page
On the [Config](/docs/government/org-admin/configuration) page, expand the **Microsoft 365** card and fill in the form.
| Field | What to enter |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tenant ID** | The **Directory (tenant) ID** from the application's Overview page. |
| **Client ID** | The **Application (client) ID** from the application's Overview page. |
| **Azure cloud** | **Commercial** for most tenants, including Microsoft 365 GCC. Choose **US Government GCC-High** or **US Government DoD** only if your Microsoft tenant is in one of those clouds. |
| **Access** | The Microsoft Graph permissions the connector requests when a member signs in. The standard read-only permissions are already selected; add or remove permissions as needed. See [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow). |
Save the card. The connector is delivered to each member's Claude Desktop the next time it refreshes its configuration, which happens at launch or sign-in. Members who already have Claude Desktop open may need to restart it.
## Choose which Microsoft 365 permissions to allow
The **Access** picker controls which Microsoft Graph delegated permissions Claude Desktop requests when a member signs in. The permissions marked **Default** below are already selected when you first open the card and give read-only access to the member's mail, calendar, files, sites, Teams chat, and online meetings. Add write or administrator-approval permissions if you need them, or clear read permissions you do not want. At least one permission must be selected.
Whatever you select here must also be added and approved on the Entra app registration (step 4 above). Keep the two lists in sync. Claude Desktop also always requests `User.Read` and `offline_access`. These two do not appear in the picker, but they must still be approved on the Entra app registration.
### Read access
| Permission | What it lets Claude do |
| --------------------------------- | --------------------------------------------------------------------------- |
| `Mail.Read` (Default) | Read the member's mail |
| `Mail.Read.Shared` (Default) | Read mail in mailboxes shared with the member |
| `Calendars.Read` (Default) | Read the member's calendar events |
| `Calendars.Read.Shared` (Default) | Read events on calendars shared with the member and find free meeting times |
| `Files.Read.All` (Default) | Read files the member can open in OneDrive and SharePoint |
| `Sites.Read.All` (Default) | Read SharePoint site content the member can open |
| `Chat.Read` (Default) | Read the member's Teams chats |
| `OnlineMeetings.Read` (Default) | Read the member's online meetings |
| `MailboxSettings.Read` | Read the member's mail rules and automatic-reply settings |
### Read access requiring administrator approval
These two permissions always require the **Grant admin consent** step in Entra, regardless of your tenant's user-consent policy. Until that step is done, sign-in fails for every member when either permission is requested.
| Permission | What it lets Claude do |
| ---------------------------------- | ----------------------------------------------------- |
| `ChannelMessage.Read.All` | Include Teams channel messages in chat search results |
| `OnlineMeetingTranscript.Read.All` | Read meeting transcripts |
### Write access
Write permissions let Claude take actions in Microsoft 365 on the member's behalf, such as sending mail, creating calendar events, and editing files. Members approve each write action in Claude Desktop before it runs. The connector is read-only unless you select at least one of these.
| Permission | What it lets Claude do |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Mail.Send` | Send mail, send drafts, and forward mail on the member's behalf. Forwarding and sending drafts also use a mail read permission (any of `Mail.Read`, `Mail.Read.Shared`, or `Mail.ReadWrite`) for pre-send checks. |
| `Mail.ReadWrite` | Create, edit, and delete drafts; trash, restore, and delete messages; apply and remove labels on messages |
| `Calendars.ReadWrite` | Create, update, delete, and respond to calendar events |
| `Files.ReadWrite.All` | Create, edit, rename, move, copy, and delete files and folders the member can edit in OneDrive and SharePoint |
| `Sites.ReadWrite.All` | Additional SharePoint write access beyond files. No Claude action requires this permission; `Files.ReadWrite.All` covers file actions in both OneDrive and SharePoint. |
| `ChatMessage.Send` | Send messages in the member's existing Teams chats |
| `ChannelMessage.Send` | Post messages to Teams channels |
| `Chat.Create` | Start new Teams chats |
| `MailboxSettings.ReadWrite` | Manage the member's labels, mail rules, and automatic replies |
<Note>
Removing a permission from the **Access** picker changes what Claude Desktop requests the next time a member signs in, but it does not revoke permissions that Microsoft Entra has already approved for the application. To revoke a permission entirely, remove it in the Entra admin center under **Enterprise applications** > your application > **Permissions**.
</Note>
## What members see
After you save the card, **Microsoft 365** appears under **Settings** > **Connectors** in each member's Claude Desktop. The member selects **Connect** and signs in with their Microsoft work account. On devices that meet the brokered sign-in requirements below, this opens the operating system's account picker; otherwise, it opens the default browser. Once connected, Claude can search and read the member's Microsoft 365 content in conversations.
Sign-in tokens are stored encrypted on the member's device and persist across restarts, so members are not asked to sign in again each session. Selecting **Disconnect** deletes the connector's stored tokens from the device. On the brokered sign-in path, the device's work or school account is managed by the operating system and remains after Disconnect, so selecting **Connect** again can re-acquire tokens without a fresh prompt. To end a member's access entirely, revoke the member's sessions in the Entra admin center (revocation takes effect once the member's current access token expires), or remove the account from the device in Windows Settings (**Accounts** > **Access work or school**) or macOS Company Portal.
### Brokered sign-in requirements
If your Conditional Access policies require a compliant or managed device, sign-in must carry a device-identity claim. Brokered sign-in provides that claim directly; browser sign-in provides it only when the browser itself is integrated with device identity (for example, Microsoft Edge signed in with the work account on an Entra-joined Windows device, or a macOS browser with the Enterprise SSO integration deployed). Without the claim, members see Entra error `AADSTS53000` or `AADSTS53003` when Claude calls Microsoft 365.
Brokered sign-in requires the broker redirect URIs from step 2, **Allow public client flows** set to **Yes** (step 3), and the following on each device:
| Platform | Broker availability requirements |
| -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows | Windows 10 or Windows Server 2019 or later. The device is joined or registered to Entra ID (Entra joined, Entra hybrid joined, or Entra registered). |
| macOS | macOS 10.15 or later. The Mac is enrolled in device management and registered in Entra ID. **Intune Company Portal** is installed, and an **Extensible SSO** configuration profile of type **Redirect** pointed at the Microsoft Enterprise SSO plug-in is deployed through device management. The broker is unavailable without Company Portal and the SSO profile. |
When the broker is unavailable, Claude Desktop falls back to browser sign-in automatically and stays on browser sign-in until Claude Desktop restarts.
When the broker is available, it carries the device claim, and Conditional Access then evaluates that claim against your policy, so the device must also satisfy whichever grant control your policy applies: marked compliant in Intune (or by a partner compliance integration that reports to Intune) for a **Require compliant device** policy, or hybrid joined for a **Require Entra hybrid joined device** policy. A device with a working broker that does not satisfy the policy still fails with `AADSTS53000` or `AADSTS53003`.
## Common problems
| What the member sees | What it means | How to fix it |
| ---------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Entra error `AADSTS50011` at sign-in | One of the redirect URIs from step 2 is missing from the app registration, was entered with a different value, or was added under the **Web** platform instead of **Mobile and desktop applications**. The error message names the URI that Claude Desktop sent. | Compare it with step 2 and add or correct that URI under **Mobile and desktop applications**. |
| Entra error `AADSTS900971` at sign-in on macOS | No redirect URI is registered for macOS brokered sign-in. | Add `msauth.com.anthropic.claudefordesktop://auth` under **Mobile and desktop applications** (step 2). |
| Entra error `AADSTS65001` at sign-in | The Microsoft Graph permissions have not been approved for the tenant, or a permission the connector requests is not listed under the app registration's **API permissions** (so **Grant admin consent** never covered it). | Confirm that every permission selected under **Access** on the Config page, plus `User.Read` and `offline_access`, is listed under the app registration's **API permissions**. Add any that are missing, then select **Grant admin consent** (step 4). |
| A Microsoft consent prompt appears at sign-in even though you selected **Grant admin consent** | Same cause as `AADSTS65001` above, on a tenant that allows members to approve permissions themselves. | See the `AADSTS65001` row above. |
| Entra error `AADSTS7000218` at sign-in | **Allow public client flows** is set to **No** on the app registration. | Set it to **Yes** (step 3). |
| Entra error `AADSTS53000` or `AADSTS53003` when Claude calls Microsoft 365 | A Conditional Access policy requires a compliant or managed device, and either sign-in fell back to the browser because brokered sign-in is not available, or the device does not satisfy the policy's grant control. | Meet the [brokered sign-in requirements](#brokered-sign-in-requirements) for the member's platform, confirm the device satisfies whichever grant control your policy applies (marked compliant, or hybrid joined), and restart Claude Desktop. On macOS, the most common broker cause is a missing Company Portal install or Extensible SSO profile. |
| Entra error `AADSTS700016` at sign-in | The **Client ID** or **Tenant ID** on the Config page does not match an application in the selected **Azure cloud**. | Re-check the Client ID and Tenant ID against the application's Overview page, and confirm that **Azure cloud** matches the cloud where you registered the application. |
| Sign-in or Claude's Microsoft 365 calls fail with a network error and no `AADSTS` code | The member's device cannot reach the Microsoft Entra or Microsoft Graph host for your Azure cloud. | Allow outbound HTTPS to the hosts listed under [Allow outbound network access](#allow-outbound-network-access). |
| A tool returns a permission error | The Microsoft Graph permission that tool needs is not approved on the app registration, or is not selected under **Access**. | Add the permission in both places and select **Grant admin consent** again. |
## Things to know
* Read and write permissions are separate per Microsoft 365 service. You can approve read broadly while limiting write to specific services or none at all by selecting only the permissions you want under [Choose which Microsoft 365 permissions to allow](#choose-which-microsoft-365-permissions-to-allow).
* The **Access** selection applies to everyone who receives this connector card. There is no separate per-group write toggle inside the card. To give different groups different permissions, set the card at the group scope on the Config page; see [Group-specific settings](/docs/government/config/overview#group-specific-settings).
government/connectors/overview First recorded · 56 lines, first recorded
# Connectors ## The Connectors card ## Adding a connector ### Step 1: Server ### Step 2: Discover tools ### Step 3: Policy & scope ## Editing and removing a connector
The first capture of this source. The page was already there, and this is what it said.
# Connectors > Add Model Context Protocol servers for your own systems, choose which Claude products receive each one, and set which of their tools are available to members. > **Who this is for:** Tenant administrators and organization owners who want Claude to reach their agency's own systems (for example, an internal search service or a ticketing tool) from Claude Desktop and other Claude products. Use this page to add Model Context Protocol servers for your own systems, choose which Claude products receive each one, and set which of their tools are available to members. A **connector** is a link between Claude and an external service. The service runs a Model Context Protocol (MCP) server, which is a standard way for a service to publish a set of tools that Claude can call. You add the server once here, and Claude for Government delivers it to the products you select. ## The Connectors card The **Connectors** card appears on your [tenant](/docs/government/tenant-admin/configuration) or [organization](/docs/government/org-admin/configuration) Config page alongside the built-in connector cards. It lists every connector you have added, with each one's name, address, the products it applies to, and a summary of how many of its tools are allowed. Click **Add connector** to open the wizard, or click the edit icon next to a connector to change it. Connectors are set at the tenant or organization level. When you are viewing a group scope, the card is read-only and points you to the organization or tenant settings where connectors are configured. ## Adding a connector The **Add connector** button opens a three-step wizard. ### Step 1: Server Enter the details of the MCP server. * **Name** is a short identifier for the connector. It must be lowercase letters, digits, hyphens, or underscores. * **Server URL** is the address of the server's MCP endpoint. It must begin with `https://`. * **Transport** selects how Claude talks to the server. Choose HTTP or SSE to match what your server supports. * **Authentication** selects how Claude proves who it is to the server. **None** sends no credentials. **Header (shared secret)** sends a fixed header (for example, an authorization token) with every request; the value is stored securely and shown as `••••` after you save. **OAuth (members sign in)** has each member sign in on first use, and their tokens stay on their own machine. **OAuth (pre-registered app)** also has each member sign in, through an app you register with the server's sign-in provider ahead of time. For **OAuth (pre-registered app)**, enter the **Client ID** your provider issued when you registered the app. A single-tenant Microsoft Entra app also needs its **Tenant ID** and the **Scope** the app requests. Enter the scope that your server's own API expects (for example, an `api://` scope for an app registered in your tenant), because Microsoft Graph scopes such as `Mail.Read` would give the connector's server access to members' Microsoft 365 data. Neither OAuth option stores a secret. When you choose either OAuth option, a confirmation checkbox appears on the final step asking you to confirm that the server address is exactly the one you intend, because members are sent to a sign-in page that the server chooses. When sign-in happens somewhere other than the server itself, for example when you set a tenant ID for a Microsoft Entra app, the checkbox names both that sign-in address and the server address. ### Step 2: Discover tools This step tries to list the tools the server offers so that you can set policy on the next step. Discovery runs from your own browser and is best-effort; many servers cannot be reached this way (for example, because they require authentication or are on a private network), and you can always add tools by name on the next step instead. Click **Discover tools** to run the probe. If the server answers, the tools it advertises are listed. If the server asks for sign-in, a **Sign in to discover** option appears: confirm the sign-in host, sign in through the popup, and the probe runs again with that one-time credential. The credential is used once in your browser for this probe and is never stored; it is separate from the **Authentication** choice on the Server step, which controls how members authenticate later. The **Sign in to discover** option does not appear when you choose **OAuth (pre-registered app)**, because this probe does not sign in with the app you registered. Add the tools by name on the next step. ### Step 3: Policy & scope Choose which products receive this connector and which of its tools are available. Under **Apply to**, tick the products that should receive this connector: Claude Desktop and Microsoft 365. A connector with no products ticked is saved but delivered nowhere, which is a way to pause it. A connector that uses OAuth cannot be applied to Microsoft 365, because per-user sign-in is not available there. A connector with any tool switched off in the table below also cannot be applied to Microsoft 365, and the checkbox is disabled with a **needs every tool on** note until every tool is on. Under **Tool policy**, the table lists the tools found during discovery with an on/off switch for each. **Refresh tools** probes the server again and fills in any tools that are new since you last looked, keeping the switches you have already set. **Add tool** lets you type a tool name by hand when discovery could not reach the server. On Claude Desktop, a tool you switch off is blocked, a tool you switch on is available and each member still approves its use, and a tool that is not listed at all is left to the member to enable or disable. You cannot apply this connector to Microsoft 365 while any tool in this table is switched off. If you are editing a connector that already applies to Microsoft 365 and you switch a tool off, a warning tells you that saving will remove it from Microsoft 365. Click **Save** to create the connector. It appears in the **Connectors** card and is delivered to the products you ticked. ## Editing and removing a connector Click the edit icon next to a connector in the card to open the same wizard with its current values filled in. Changing the authentication method clears any stored secret and the app details saved for **OAuth (pre-registered app)**. Click the remove button next to a connector to delete it; it is withdrawn from every product at the next refresh.
government/deploy-desktop/configure First recorded · 213 lines, first recorded
# Connect Claude Desktop to Claude for Government ## Choose how to deploy ## Before you begin ## The managed setting ### How the app uses the bootstrap address ## Configure a single machine ## Deploy to your fleet ### macOS ### Windows ### Linux ### Order of deployment ## Confirm it worked ## Troubleshooting ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Connect Claude Desktop to Claude for Government
> Choose between single-machine setup and fleet deployment, understand the administrator requirements for each, and connect Claude Desktop to Claude for Government.
> **Who this is for:** IT administrators who install Claude Desktop on agency devices and connect it to Claude for Government.
A fresh install of Claude Desktop connects to claude.ai. To connect it to Claude for Government instead, each device needs one managed setting that tells the app where to reach Claude for Government. Once that setting is in place, everything else that governs the app (which products and features are available, model access, [connectors](/docs/government/connectors/overview), usage limits, the Claude Desktop banner) is controlled through the [tenant](/docs/government/tenant-admin/configuration) and [organization](/docs/government/org-admin/configuration) configuration pages in this portal and delivered to each user when they sign in.
## Choose how to deploy
There are two ways to get Claude Desktop installed and connected to Claude for Government. They differ in who runs the installer, what rights that requires, and how the setting reaches the app.
| | Configure a single machine | Deploy to your fleet |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Best for | Confirming the app works on a representative device before a wider rollout, or setting up a small group of devices by hand | Production rollout across your agency |
| Who installs the app | A person at the device | Your device management system (for example Intune, Configuration Manager, or Jamf) |
| Administrator rights to install | Needed by the person doing each install | Not needed by end users; the management system installs with elevated rights |
| How the address is set | Entered in the app's built-in configuration window | Pushed as a configuration profile alongside the app |
For a production rollout, use your device management system so end users never need administrator rights. The single-machine path is for testing first or for a small group you set up by hand, with an administrator doing each install. That path can also export a ready-made profile for your management system, so it is a useful starting point even when the fleet path is your destination.
## Before you begin
Confirm each of the following before you start either path.
* **User accounts exist.** Claude Desktop signs users in to the same accounts as this portal. For each user, including your own test account, check with your tenant administrators that the user can sign in (a [routing rule](/docs/government/tenant-admin/identity-and-access) covers them) and has a [seat tier](/docs/government/org-admin/seat-tiers) with at least one model enabled.
* **Devices can reach Claude for Government.** Claude Desktop on every device must reach the Claude for Government host over HTTPS on port 443. That one host carries the app's configuration and chat traffic.
* **Browsers can reach sign-in.** Sign-in happens in the user's default web browser, not in the app. Browsers on each device must reach the Claude for Government host, its sign-in service (a separate host that your Anthropic representative provides), and your agency's identity provider.
* **The device meets Claude Desktop's requirements.** See the Claude Desktop [system requirements](/docs/third-party/claude-desktop/installation#system-requirements) for macOS and Windows device requirements. For a Windows fleet, work through the [Windows fleet checklist](/docs/government/deploy-desktop/windows-checklist), which covers the Virtual Machine Platform feature that Cowork needs along with the installer, policy, and network prerequisites.
* **Windows devices used for Code have Git for Windows.** On Windows, only the Code part of Claude Desktop needs Git for Windows. Chat and Cowork work without it. Install Git on the devices whose users will work in Code, or turn **Code in Claude Desktop** off under [Product availability](/docs/government/config/settings#product-availability) so that users are not prompted to install Git.
* **You can install the app.** Installing by hand needs administrator rights on each device; see [Configure a single machine](#configure-a-single-machine) for what that means on each platform. Installing through your device management system does not, because the management system installs with elevated rights. The [macOS deployment guide](https://support.claude.com/en/articles/12611117-deploy-claude-desktop-for-macos) and the [Windows deployment guide](https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows) cover where to download the installer and how to distribute it.
* **The app is current.** The configuration mechanism on this page requires Claude Desktop 1.10628.0 or later.
## The managed setting
The setting is called `bootstrapUrl`, and its value is the Claude for Government host followed by the fixed path `/gateway-api/user/bootstrap`.
```text theme={null}
https://<claude-for-government-host>/gateway-api/user/bootstrap
```
The Claude for Government host is the same domain name you use to access Claude for Government. If you are unsure of it, ask your Anthropic representative. The app uses the address exactly as entered; it fetches each user's configuration from it and starts sign-in from it, so include the full path.
### How the app uses the bootstrap address
The address is the same for every device and user in your agency and carries no credentials or user information, so the same profile is safe to push to your whole fleet. A request to the address without a signed-in session is refused.
When a user chooses **Sign in with your organization**, the app asks the Claude for Government host to start a sign-in, shows the pairing code it receives, and opens the host's sign-in page in the user's default browser. That page asks for the user's agency email address, then sends the browser to the sign-in service and on to your agency's identity provider. After signing in, the user acknowledges the system-use notification, confirms that the code shown in the browser matches the one in the app, and approves.
Claude for Government then issues the app a session for that user, which the app stores encrypted on the device. The app presents that session, and nothing from the profile, when it downloads the user's configuration from this address and when it sends chat traffic to the same host. It re-checks the configuration about every 30 minutes and at each launch.
The configuration that the app downloads for a user includes the following settings, all of which you manage in this portal.
| What the app receives | Where it is set |
| --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Which of Chat, Cowork, and Code the user can open, and whether Advanced file analysis is on in Chat | [Product availability](/docs/government/config/settings#product-availability) on the Config page |
| The models the user can choose | The user's [seat tier](/docs/government/org-admin/seat-tiers) |
| Connectors, plugins, and the settings for the built-in tools | The [tool and connector cards](/docs/government/config/settings#tool-and-connector-cards) on the Config page |
| The hosts that tools may reach | [Allowed network hosts](/docs/government/config/settings#allowed-network-hosts) |
| The folders a user can choose as a workspace | [Allowed workspace folders](/docs/government/config/settings#allowed-workspace-folders) |
| The banner shown across the top of the app | [Claude Desktop banner](/docs/government/config/settings#claude-desktop-banner) |
| Where the app sends your agency's own telemetry, if you have set a collector | [Telemetry endpoint (Claude Desktop)](/docs/government/config/settings#telemetry-endpoint-claude-desktop) |
## Configure a single machine
<Note>
Installing by hand needs administrator rights on the device. On Windows, the installer registers a Windows system service, so it must run as a local administrator. On macOS, installing to the shared Applications folder requires an administrator. On Linux, installing the package requires root.
</Note>
Claude Desktop has a built-in configuration window that is hidden until you enable developer mode. These steps use it to set the address on one machine without any management tooling.
<Steps>
<Step title="Launch the app without signing in">
Install Claude Desktop on the test machine and open it. On Windows, run the installer while signed in as a local administrator. The claude.ai sign-in screen appears; this is expected before the app is configured. Stay on this screen.
</Step>
<Step title="Enable developer mode">
From the **Help** menu, choose **Troubleshooting**, then **Enable Developer Mode**, and confirm the prompt. On Windows the **Help** menu is under the application menu (☰) on the sign-in screen. The app relaunches with a **Developer** menu added.
</Step>
<Step title="Open the configuration window">
From the **Developer** menu, choose **Configure Third-Party Inference**. This is the correct option for Claude for Government despite the name. The window opens on its **Connection** section.
</Step>
<Step title="Enter the bootstrap address">
In the window's left sidebar, click **Source**. On an unconfigured machine it appears last in the list and is dimmed, but is still clickable. Enter the full address from the section above in the **Bootstrap config URL** field. Leave every other field alone; Claude for Government supplies the provider, credentials, and model list after sign-in.
</Step>
<Step title="Apply and sign in">
Click **Apply Changes** and let the app relaunch. The sign-in screen now offers **Sign in with your organization** alongside the claude.ai option. Choose it. The app shows a pairing code and opens the sign-in page in your browser. Sign in with your agency credentials, confirm that the code in the browser matches the one in the app, and approve. The app picks up the session and opens to Claude.
</Step>
<Step title="Run the verification checklist">
Work through [Confirm it worked](#confirm-it-worked) below.
</Step>
</Steps>
After the test, the same configuration window has an **Export** menu that produces files ready for your management system: a `.mobileconfig` profile for macOS, a `.reg` file for Windows, an ADMX template for Intune or Group Policy, and a Profile Manifest for Jamf. Before exporting, turn on **Disable Claude.ai sign-in** in the window's **Workspace** section so the exported profile hides the claude.ai option on managed devices.
## Deploy to your fleet
When your device management system deploys Claude Desktop, end users receive the app without running an installer themselves. The management system installs the package with the system or root account on each platform, so end users need no administrator rights and see no elevation prompt. Push both the app installer and the configuration profile below through the same system.
The recommended profile contains two keys. In the macOS and Windows profiles below, write every value as a string exactly as shown, including booleans as the strings `"true"` or `"false"`; the Linux file uses native JSON types, as shown.
| Key | Value | Purpose |
| ------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `bootstrapUrl` | `https://<claude-for-government-host>/gateway-api/user/bootstrap` | Required. Points the app at Claude for Government. |
| `disableDeploymentModeChooser` | `"true"` | Recommended. Hides the claude.ai sign-in option so users can only sign in to Claude for Government. |
No other keys are needed; Claude for Government supplies everything else per user after sign-in. The profile contains no secrets, only a host. Keys documented for other Claude plans, such as `forceLoginOrgUUID` or `loginSsoOrgDomain`, apply only to claude.ai workspaces and are not used here.
### macOS
Claude Desktop reads managed preferences in the `com.anthropic.claudefordesktop` domain. Deploy a configuration profile that sets the two keys in that domain as strings.
```xml theme={null}
<key>bootstrapUrl</key>
<!-- substitute the Claude for Government host -->
<string>https://<claude-for-government-host>/gateway-api/user/bootstrap</string>
<key>disableDeploymentModeChooser</key>
<string>true</string>
```
Most device management consoles, including Jamf and Intune, build the profile around these keys for you. For a complete `.mobileconfig` ready to upload, use the Export menu described in the single-machine path.
For a device-management rollout on macOS, also set `disableAutoUpdates` to the string `"true"` in the profile and push updates through your management system, so the in-app updater never prompts users for administrator rights.
### Windows
Claude Desktop reads string (`REG_SZ`) values by name under `HKLM\SOFTWARE\Policies\Claude`. Deliver them with Intune, Group Policy, or any tool that writes machine policy. The ADMX template from the Export menu makes both keys available in the policy editor. As a `.reg` file:
```text theme={null}
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Claude]
; substitute the Claude for Government host
"bootstrapUrl"="https://<claude-for-government-host>/gateway-api/user/bootstrap"
"disableDeploymentModeChooser"="true"
```
The `.reg` file from the Export menu targets `HKEY_CURRENT_USER`, which is correct for single-machine testing. For fleet deployment, deliver the values under `HKEY_LOCAL_MACHINE` as shown here.
<Note>
Cowork, the agentic workspace in Claude Desktop, requires the **Virtual Machine Platform** Windows optional feature. Enable that feature through your device management system before rollout. On a device where the feature is not enabled, Cowork is unavailable until someone turns the feature on, which requires administrator rights that a standard user does not have. Chat works regardless of this feature. The [Windows fleet checklist](/docs/government/deploy-desktop/windows-checklist) lists the remaining Windows prerequisites.
</Note>
### Linux
Place a JSON file at `/etc/claude-desktop/managed-settings.json` containing the same keys at the top level.
```json theme={null}
{
"bootstrapUrl": "https://<claude-for-government-host>/gateway-api/user/bootstrap",
"disableDeploymentModeChooser": true
}
```
The file must be a regular file (not a symlink), and the file and its directory must be owned by root and must not be group- or world-writable. If the permissions are wrong, the app rejects the file, logs the reason to `main.log`, and treats the device as managed but unreadable, so local settings are also disabled until the permissions are corrected and the app is relaunched.
### Order of deployment
Deploy 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.
<Note>
Once `bootstrapUrl` or any other connection key 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. Removing the profile returns the device to local control.
</Note>
The 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.
## Confirm it worked
Run through these checks on a configured machine from either path.
<Steps>
<Step title="Check the sign-in screen">
Launch the app. The sign-in screen offers **Sign in with your organization**. On a managed device with `disableDeploymentModeChooser` set, it is the only option. If only the claude.ai sign-in appears, the configuration did not reach the app.
</Step>
<Step title="Check that the device is managed">
On a device that received the profile through your management system, open the configuration window (the first three steps of the single-machine path). It should be read-only with a banner noting that your organization manages the configuration. If it is still editable, no recognized key reached the app, even if your management console reports the profile as delivered. The diagnostic report's Configuration section (next step) shows exactly what the app read.
</Step>
<Step title="Generate a diagnostic report">
From **Help**, choose **Troubleshooting**, then **Generate Diagnostic Report**. The report's Configuration section lists which keys the app read, where each came from, and any values that failed to parse. Secret values are redacted, so the report is safe to attach to a help-desk ticket.
</Step>
<Step title="Sign in and send a message">
Sign in as a provisioned test user. Chat works and the model picker lists the models you expect for that user's seat tier.
</Step>
<Step title="Confirm per-user settings arrived">
After sign-in, what the app offers matches that user's [product availability](/docs/government/config/settings#product-availability) settings (with everything on, the sidebar shows **Home** and **Code**), and any organization-managed connectors appear in the app. One end-to-end test is to set a short message in the **Claude Desktop banner** setting on the tenant [Config](/docs/government/tenant-admin/configuration) page during rollout; if the message appears across the top of the app after sign-in, per-user delivery is working. If sign-in succeeds but none of these settings arrive, re-check the configured address.
</Step>
</Steps>
## Troubleshooting
| What you see | Likely cause | What to do |
| --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Only the claude.ai sign-in screen; no organization option | The configuration never reached the app: the profile was not delivered, a key name is misspelled, the value is in the wrong location or registry type, or the app was not relaunched after the change | Verify delivery in your management console, generate a diagnostic report and check its Configuration section, then fully quit and reopen the app |
| Sign-in times out, or the browser says the code expired | The app stops waiting after about five minutes | Cancel and start sign-in again; a fresh code is issued |
| The diagnostic report or `main.log` shows "Managed configuration is invalid; local settings are disabled until it is fixed" | The app detected a managed profile but could not read any of its values | Correct the profile and redeploy; the report's Configuration section names each key that failed |
| Signed in, but the model picker is empty | The user has no seat tier, or none of the tier's models is available in Claude for Government | Have an organization owner check the user's seat on the [Users](/docs/government/org-admin/users) page and the tier's models on the [Seat tiers](/docs/government/org-admin/seat-tiers) page |
For anything else, the app writes its log to `~/Library/Logs/Claude-3p/main.log` on macOS, `%LOCALAPPDATA%\Claude-3p\logs\main.log` on Windows, and `~/.config/Claude-3p/logs/main.log` on Linux. The log records which configuration keys were read or dropped and why. The diagnostic report from the verification checklist produces a bundle, without conversation content, that you can send to your Anthropic representative.
## Things to know
* Configuration changes made in this portal do not need to be pushed to devices. The app re-checks Claude for Government for changes about every 30 minutes and at each launch, and prompts users to relaunch when something changed.
* New and retired models appear in the model picker without any profile change or app update; model access is controlled through [seat tiers](/docs/government/org-admin/seat-tiers).
* Claude Desktop keeps itself updated by default. If your agency distributes software through its own pipeline, add `disableAutoUpdates` with the value `"true"` to the same profile and redistribute installers yourself.
* The sign-in flow and what a user sees on the [Sessions](/docs/government/account/sessions) page after pairing a device are covered on that page.
government/deploy-desktop/windows-checklist First recorded · 69 lines, first recorded
# Windows fleet checklist ## Device requirements ## Installer and packaging ## Application control rules ## Cowork virtualization ## Configuration values ## Network access ## User accounts and seats
The first capture of this source. The page was already there, and this is what it said.
# Windows fleet checklist > Device, installer, virtualization, policy, network, and account prerequisites to confirm before deploying Claude Desktop across a Windows fleet for Claude for Government. > **Who this is for:** IT administrators and desktop engineering teams who are preparing a Windows fleet for Claude Desktop connected to Claude for Government. Use this checklist to confirm what your devices, policies, network, and user accounts need before you push Claude Desktop to a Windows fleet. Several items concern the virtual machine that Claude Desktop runs on each device for Cowork, the agentic workspace in Claude Desktop, and for Advanced file analysis in Chat. When every item is in place, follow [Connect Claude Desktop to Claude for Government](/docs/government/deploy-desktop/configure) to deliver the managed setting and the app. ## Device requirements * **Windows version and architecture.** Devices need Windows 10 version 2004 (build 19041) or later, including Windows 11, on x64 or Arm64 hardware. See the Claude Desktop [system requirements](/docs/third-party/claude-desktop/installation#system-requirements). Devices in Windows S mode cannot run Cowork. * **Memory and disk.** Plan for at least 8 GB of memory and about 20 GB of free space on the drive that holds `%LOCALAPPDATA%`. Cowork keeps its workspace there after downloading it the first time a user starts a task. Cowork still starts on a device with less memory, but tasks run slowly. ## Installer and packaging * **Use the `.msix` package.** Cowork is available only when Claude Desktop is installed from the `.msix` package. The legacy `.exe` installer gives you Claude Desktop without Cowork. See [Install the app](/docs/third-party/claude-desktop/installation#install-the-app). * **Install machine-wide.** Have your management system (for example Intune or Configuration Manager) provision the package for all users from the system account, or provision it from an elevated PowerShell session with `Add-AppxProvisionedPackage` or the equivalent DISM command. The package registers a Windows service that Cowork uses, so an install run by a standard user fails, and installing by hand requires a local administrator. The [Windows deployment guide](https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows) covers downloading and distributing the package. * **Allow trusted app installation.** Make sure Windows policy allows trusted app packages to install from outside the Microsoft Store. If your security baseline configures **Allow all trusted apps to install** (the `ApplicationManagement/AllowAllTrustedApps` policy), set it to enabled. Windows Developer Mode is not required. * **Intune scripts.** For Intune, Anthropic publishes [install and detection scripts](https://downloads.claude.ai/releases/enterprise/intune/Claude-Intune-README.md) that deploy the `.msix` as a Win32 app, so that Intune keeps reporting the app as installed after the app updates itself. * **Offline installer.** For networks that cannot reach `downloads.claude.ai`, deploy the [offline installer](/docs/third-party/claude-desktop/installation#offline-installation), which includes the components that Cowork and Code otherwise download from that host. * **Nothing else to pre-install.** The `.msix` package is self-contained, with no separate runtimes or frameworks to install first. Git for Windows is needed only on devices whose users will work in Code; see [Before you begin](/docs/government/deploy-desktop/configure#before-you-begin). * **Software intake.** The package is MSIX rather than MSI or EXE, and Intune, Configuration Manager, and PowerShell deploy MSIX natively. If your software intake process names MSI or EXE packages specifically, confirm that it accepts MSIX. An MSIX package installs without prompts when your management system deploys it and takes no vendor-specific switches. ## Application control rules If you enforce application control with AppLocker or App Control for Business (formerly Windows Defender Application Control), allow Claude Desktop by publisher or by package family name rather than by path, and let the rule match any version, so that it keeps matching as the app updates. | Identifier | Value | | ---------------------- | ---------------------- | | Package name | `Claude` | | Package family name | `Claude_pzs8sxrjxfjjc` | | Publisher display name | Anthropic, PBC | These values identify the `.msix` package from the download site and the offline installer, and they do not change between versions or architectures. Cowork also runs an agent helper, a separate executable signed by Anthropic that the app places under each user's profile rather than inside the package. If AppLocker executable rules or endpoint security software with path-based rules apply on your devices, allow the helper by publisher too, as described under [Endpoint security software](/docs/third-party/claude-desktop/installation#endpoint-security-software). ## Cowork virtualization Cowork runs the shell commands that Claude issues inside a dedicated virtual machine that the app manages on each device, and Advanced file analysis in Chat uses the same virtual machine. Users install nothing for this, but each device must be able to start the virtual machine. The [Cowork readiness check](/docs/third-party/claude-desktop/installation#check-device-readiness) is a small program that verifies most of the requirements below on a device without installing anything or signing in. Run it on one device of each hardware model, and resolve what it reports before the broad rollout. * **Virtual Machine Platform.** Enable the **Virtual Machine Platform** optional Windows feature (`VirtualMachinePlatform`) on every device before rollout, for example by running `Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart` from an elevated PowerShell session, then restart the device so that the feature takes effect. Turning the feature on requires administrator rights, so a standard user cannot enable it later. * **Hardware virtualization.** Turn on hardware virtualization in each device's firmware (Intel VT-x or AMD-V on x64 devices). * **Service logon right.** The virtual machine runs under an account in the built-in `NT VIRTUAL MACHINE\Virtual Machines` group (SID `S-1-5-83-0`), the same group that Hyper-V and WSL 2 use, so a fleet where either of those works already meets this requirement. You only need to act if your security baseline manages the **Log on as a service** right through Group Policy. In that case, include this group, and keep it out of **Deny log on as a service**. * **Uncompressed application data.** Leave `%LOCALAPPDATA%\Claude-3p` out of NTFS compression and Encrypting File System (EFS) policies, because the virtual machine's disk cannot start from a compressed or EFS-encrypted folder. * **Virtual desktops.** On virtual desktop infrastructure, the Windows desktops themselves run as virtual machines, so Cowork can start only where the hosting platform exposes nested virtualization to them. Run the readiness check on one desktop in each pool, and make Cowork available to virtual desktop users only where it passes. On a device that does not meet these requirements, Chat still works apart from Advanced file analysis, and Cowork reports that it is unavailable. If a device meets them and Cowork still fails to start, check whether endpoint security software is blocking the Cowork agent helper, as described under [Application control rules](#application-control-rules). ## Configuration values * **Two registry values.** Push the two values described under [Windows](/docs/government/deploy-desktop/configure#windows) as machine policy under `HKLM\SOFTWARE\Policies\Claude`: the required `bootstrapUrl` and the recommended `disableDeploymentModeChooser`. No other values are needed, because everything else reaches each user from Claude for Government at sign-in. * **Delivery order.** Deliver the values before the app wherever you can, so that users land directly on the Claude for Government sign-in screen, as [Order of deployment](/docs/government/deploy-desktop/configure#order-of-deployment) explains. ## Network access Claude Desktop's own traffic is HTTPS on port 443, and you can allowlist it by hostname. The [Security and data handling](/docs/government/security/security-and-data-handling#network-egress-required-domains-and-proxies) page explains what each connection carries. * **App traffic.** Allow Claude Desktop on every device to reach the Claude for Government host, which carries the app's configuration and chat traffic. * **Browser sign-in traffic.** Allow the browser on every device to reach the Claude for Government host, the Claude for Government sign-in service (a separate host that your Anthropic representative provides), and your agency's identity provider. Sign-in happens in each user's default browser, not in the app. * **`downloads.claude.ai`.** The app downloads the Cowork workspace and the Claude Code command-line tool from this host when a user starts a Cowork task, a Code session, or Advanced file analysis in Chat. The offline installer includes both, so devices installed with it need this host only for application updates while automatic updates are on. * **`www.claudeusercontent.com`.** This host serves the frame that displays artifact previews. * **Update hosts.** While automatic updates are on, also allow the hosts listed under Auto-updates in [Required egress paths](/docs/third-party/claude-desktop/telemetry#required-egress-paths). The telemetry rows there never apply, because Claude for Government does not send telemetry to Anthropic. * **Hosts your tools and connectors use.** Allow the hosts you add to [Allowed network hosts](/docs/government/config/settings#allowed-network-hosts) (such as package registries), the addresses of any connectors you configure on the Config page (including Microsoft 365 if you set up that connector), and your telemetry collector if you set one. * **Proxies.** The app and the Cowork workspace follow the operating system's proxy settings, including PAC files, as described under [Proxy support](/docs/third-party/claude-desktop/telemetry#proxy-support). If your proxy inspects TLS, validate sign-in, a chat, and a Cowork task on a pilot device before rollout. ## User accounts and seats Make sure every user in the rollout can sign in and has a seat before their device is set up. Each user needs a [routing rule](/docs/government/tenant-admin/identity-and-access) that covers them and a [seat tier](/docs/government/org-admin/seat-tiers) with at least one model enabled. A user without a seat tier can sign in but gets an empty model picker, which can look like a device problem and is covered in the [Troubleshooting](/docs/government/deploy-desktop/configure#troubleshooting) table.
government/desktop/import First recorded · 43 lines, first recorded
# Import your data from Claude for Government Web ## Before you begin ## Run the import ## If your import fails
The first capture of this source. The page was already there, and this is what it said.
# Import your data from Claude for Government Web
> Copy your conversations, projects, and files from Claude for Government Web into Cowork in Claude Desktop.
> **Who this is for:** Anyone who used Claude for Government Web (the web app) and now uses Claude Desktop connected to Claude for Government.
The import copies your conversations, their attached files, and the projects you created, which arrive as [Cowork](/docs/cowork/overview) projects. It does not copy projects that other people shared with you.
## Before you begin
* **An account on the web app.** It must use the same work email address as your Claude for Government account in Claude Desktop. The import does not work with a personal claude.ai account.
* **Sign-in to the web app in your default browser.** The import opens a browser tab there for you to approve a one-time code.
> **For administrators:** Anthropic enables the import for each organization, so there is no [product setting](/docs/government/config/settings) for it. If your users should have the import and it does not appear for them, contact your Anthropic representative. Imported conversations and projects land in Cowork, so members need Cowork turned on under [product availability](/docs/government/config/settings#product-availability).
## Run the import
<Steps>
<Step title="Open the import dialog">
In Claude Desktop, open **Settings**, then the **Cowork** page, and click **Import** in the **Claude for Government Web import** row. The **Import from Claude for Government Web** dialog opens.
</Step>
<Step title="Sign in and approve the code">
Click **Sign in**. Claude Desktop shows a one-time code and opens your default browser to the web app. Sign in there with your work account if you are asked to, confirm that the code in the browser matches the one in the app, and approve it.
</Step>
<Step title="Start the import">
Back in the dialog, check that the email address shown is your work account, then click **Import**. The import can take a few minutes and continues in the background, so you can close the dialog while it runs.
</Step>
<Step title="Check the results">
If the dialog is open when the import finishes, it reports **Import complete** with the number of conversations, projects, and files it brought over. Otherwise, find your imported conversations in the app's sidebar, listed with your other chats and tasks.
</Step>
</Steps>
## If your import fails
| What you see | Likely cause | What to do |
| -------------------------------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Your data is over the import's size limit | You have more data than the import can bring over | Remove conversations or files you no longer need in the web app, in line with your organization's records policy, then run the import again. |
| The account does not match your organization | You signed in to the web app with a different account | Start the import again and sign in with your work account. |
For anything else, try the import again; if it keeps failing, contact your administrator.
government/desktop/plugins First recorded · 36 lines, first recorded
# Plugins in Claude Desktop ## Where plugins come from ## Find and install plugins ## Manage installed plugins ## What plugins add in Claude for Government
The first capture of this source. The page was already there, and this is what it said.
# Plugins in Claude Desktop > Find, install, create, and remove plugins in Claude Desktop for Claude for Government, and understand what plugins add in this deployment. > **Who this is for:** Anyone who uses Claude Desktop in Claude for Government and wants to find, install, or create plugins. A plugin is a package that adds capabilities to Claude in a single step, such as skills, slash commands, sub-agents, and hooks. Plugins work in Cowork and in Code. See the [Plugins overview](/docs/plugins/overview) for more on what a plugin can contain. ## Where plugins come from In Claude for Government, plugins reach you in four ways: * Your administrators add plugins for your organization, and some of them install automatically. * You upload a plugin file you have. * You ask Claude to create a plugin with you. * You add a plugin marketplace and install plugins from it. Claude for Government does not include a public plugin marketplace; your administrators add your organization's plugins. You can also add a plugin marketplace of your own from **Browse plugins**. Your deployment's network controls determine whether a marketplace can be downloaded. ## Find and install plugins Open **Customize** in the sidebar, then **Plugins**. The organization plugins you have installed are listed under **Organization plugins**. To find the rest, select **Browse plugins** and open the **Organization** tab, which lists every plugin your administrators have made available to you. A plugin your administrators set to install automatically is already installed. A plugin they offer for you to choose stays available on the **Organization** tab until you install it. To install a plugin from a file, select **Add plugin**, then **Upload plugin**, and choose the plugin's `.zip` file. Claude Desktop shows a notice reminding you to install only plugins you trust, since uploaded plugins are not controlled by Anthropic. To have Claude build one, select **Add plugin**, then **Create with Claude**, and describe the plugin you want. Claude builds it for you, and you install the result. ## Manage installed plugins Open an installed plugin to see the skills, slash commands, sub-agents, and hooks it provides, and turn individual components on or off. To remove a plugin, open it and click **Uninstall**. Most plugins you uninstall stay removed for you, including ones your administrators set to install automatically. A plugin your organization requires cannot be removed, and Claude Desktop tells you it is required by your organization if you try. A plugin you upload or create is added only on the device you are using. ## What plugins add in Claude for Government A 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.
government/desktop/skills First recorded · 55 lines, first recorded
# Skills in Claude Desktop ## Where skills come from ## Create and manage skills ## Skills for administrators ## Building and deploying your own skills
The first capture of this source. The page was already there, and this is what it said.
# Skills in Claude Desktop
> What skills are in Claude for Government, where they come from, how to create and manage your own, and how administrators distribute skills to members.
> **Who this is for:** Anyone who uses Claude Desktop in Claude for Government. The last two sections are for administrators who distribute skills to members.
A skill is a set of instructions, with optional scripts and resources, that Claude loads when a task matches it, so you can teach Claude a workflow once and reuse it. See the [Skills overview](/docs/skills/overview) for how skills work.
## Where skills come from
In Claude for Government, your skills come from three places:
* Skills you create yourself, which are stored on your device.
* Skills bundled in plugins your administrators deliver, which arrive with the plugin as described in [Plugins in Claude Desktop](/docs/government/desktop/plugins).
* Skills that ship with Claude Desktop for common document tasks, such as working with spreadsheets and presentations, which Claude loads automatically when a task calls for them.
## Create and manage skills
Open **Customize** in the sidebar, then **Skills**, to see your skills and turn any of them on or off. Select **Add skill**, then choose **Create with Claude** to build one with Claude's help, **Write skill instructions** to write it yourself, or **Upload a skill** to add a skill file you have. You can also ask Claude to save a workflow as a skill while you work on a task. The [skill authoring guide](/docs/skills/how-to) describes the file format for skills you write by hand.
Open a skill you created to rename or delete it. Skills you create are stored on your device, so they are available only there.
If your organization restricts skill creation through device managed configuration, the options to create and upload skills are hidden, and Claude does not offer to create or update skills in your conversations.
## Skills for administrators
The admin portal does not currently have a skills view or per-skill controls, so there is no setting that allows, blocks, or distributes a skill on its own. To distribute skills to the members you manage, bundle them in a plugin, which can be as small as the skill plus a plugin manifest, and add it on the **Plugins** card, as described in [Manage plugins and connectors](/docs/government/config/plugins-and-connectors).
A plugin set to **Auto-install** delivers its skills to every member without the member doing anything. A skill you distribute this way is managed through the plugin that carries it, so to change or retire the skill, update or remove the plugin.
## Building and deploying your own skills
This section walks the full path from writing a skill to delivering it to the members you manage: write the skill, package it as a plugin, upload the plugin, and check the result on a device. The packaging rules live under [Plugin archive formats](/docs/government/config/plugins-and-connectors#plugin-archive-formats).
**Write the skill.** A skill is a folder named after the skill, holding a `SKILL.md` file. The file starts with YAML frontmatter carrying `name` and `description`, followed by the instructions as markdown. The folder name must match the `name` in the frontmatter. The [skill authoring guide](/docs/skills/how-to) covers the format and what makes instructions work well. You can also have Claude help, with **Create with Claude** as described under [Create and manage skills](#create-and-manage-skills), or by asking Claude to draft the skill in a Cowork task, where those are available in your deployment. If Claude hands back a `.skill` file, keep the folder it came from instead. A `.skill` file is a zip of the bare skill folder, and the **Plugins** card accepts only plugin packages, so the folder needs the plugin wrapper described next.
**Mind the text-only rule.** A skill delivered through the admin portal can contain only text files, in these formats: `.md`, `.txt`, `.json`, `.yaml`, `.yml`, `.csv`. Skills you create on your own device can include scripts and binary assets such as images, and the skill authoring guide describes those, but a plugin upload that contains them is rejected, so keep a skill you plan to distribute textual.
**Package it as a plugin.** Arrange the skill inside a plugin and zip it. The smallest valid package is the manifest plus your skill folder under `skills/`:
```text theme={null}
acme-skills.zip
├── .claude-plugin/
│ └── plugin.json
└── skills/
└── brand-guidelines/
├── SKILL.md
└── palette.csv
```
`plugin.json` needs two keys, and a description is worth adding, for example `{"name": "acme-skills", "version": "1.0.0", "description": "Agency writing skills"}`. One plugin can carry several skills, one folder per skill. Zipping the plugin folder itself also works, since the upload accepts the single wrapping folder. Claude can do the assembly in a Cowork task: give it the layout above, paste in the full rules from [Plugin archive formats](/docs/government/config/plugins-and-connectors#plugin-archive-formats), and ask it to arrange the files and produce the zip. Claude Desktop in Claude for Government does not include a packaging skill, so put the layout in your request rather than assuming Claude knows it.
**Upload it.** On the **Config** page, open the **Plugins** card, click **Add plugins**, and drop the zip. The preview shows the plugin's name, version, and description. A plugin packaged as above, with only skills and the three manifest keys, is not marked **Runs code**. The marker and its confirmation appear when a package declares components that can run code on members' machines, or carries a manifest key the upload does not recognize, as described under [Plugins that run code](/docs/government/config/plugins-and-connectors#plugins-that-run-code). Choose **Auto-install** to deliver the skills to every member, or **Members choose** to let members install the plugin themselves.
**Check it on a device.** The upload checks packaging, not skill content, so a plugin whose `SKILL.md` is malformed uploads without complaint and simply never loads as a skill. After adding the plugin, open Claude Desktop as a member: install the plugin if you chose **Members choose**, then give Claude a task the skill should match and confirm Claude picks it up. To change the skill later, update the plugin, as described under [Update or remove a plugin](/docs/government/config/plugins-and-connectors#update-or-remove-a-plugin).
government/org-admin/analytics First recorded · 78 lines, first recorded
# Analytics ## How the data is gathered ## Managed and self-managed views ## Credits (self-managed view only) ## Active users ## Usage ## CSV exports ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Analytics > Use this page to review requests, tokens, spend, top users, and credit balance over time across your organization, and to download the data as CSV files for offline reporting. > **Who this is for:** Organization owners who need to understand how their organization is using Claude and how quickly it is consuming credits. Use this page to review requests, tokens, spend, top users, and credit balance over time across your organization, and to download the data as CSV files for offline reporting. Because this data takes a moment to compute, the page starts with a **Load analytics** button. After the data loads, the results are cached for the rest of your session. You can click **Refresh** to fetch the latest numbers, and this button becomes available again 30 seconds after the previous load. A **Download** menu next to **Refresh** saves what the page shows as CSV files, described in [CSV exports](#csv-exports). ## How the data is gathered Usage figures on this page are compiled from the same metering that enforces your users' rate limits, so the request, token, and spend numbers here will closely match what your users experienced. All times are shown in your browser's time zone; if your browser reports a time zone the service does not recognize, times fall back to UTC. ## Managed and self-managed views A control at the top switches between **Anthropic-managed tiers** and **Self-managed tiers**. The two are shown separately because their economics differ: managed-tier seats are purchased as seats, while **self-managed tiers** (tiers your organization created itself on the [Tiers](/docs/government/org-admin/seat-tiers) page) draw down the billing account's balance. Spend figures and the credit panel are therefore shown only in the **Self-managed** view. If your organization has only one kind of tier, the control does not appear and the page shows only the matching view. If all of your seat tiers are Anthropic-managed, you see only the managed view, with no spend figures, credit panel, or burndown chart. ## Credits (self-managed view only) <Note> The credit panel and burndown chart only appear in the **Self-managed tiers** view, and only once credit data is available for your organization. The runway estimate within the panel only appears once there has been enough recent activity to compute a burn rate. </Note> When credit data is available, the credit panel shows the current position of the account your organization draws from as of right now. It displays the **Credits remaining** out of the total added to the account, with a progress bar marked at the 70 percent and 90 percent warning thresholds. It also shows a runway estimate that tells you roughly how many days remain at your trailing 7-day burn rate, and it adds a **Depleted**, **Low balance**, or **Approaching limit** badge when one of those conditions applies. The runway figure divides your remaining balance by your average daily spend over the last seven complete days. It is shown as "less than 1 day" when the balance is nearly exhausted and as "more than 180 days" when spend is low enough that a longer projection would not be meaningful. If there has been no spend at all in the last seven days, no runway is shown. Below the panel, the **Credit burndown** chart plots your balance, with markers on the days credits were added, and projects forward to the date you are estimated to reach \$0. The chart reaches back 30 days, or 90 days when you set the time-window selector described below to **90 days**. <Tip> The credit panel always reflects the current position and is not affected by the time-window selector. The 7-day lookback used for the burn rate is also fixed and does not change when you switch the usage window. </Tip> ## Active users The **Active users** section shows how many distinct people used Claude over fixed periods: the average number of daily active users over the last 7 days, the number of weekly active users over the last 7 days, and the number of monthly active users over the last 30 days. These figures always use the same fixed lookbacks and are not affected by the time-window selector below. ## Usage Everything below the **Usage** divider is scoped to a time window that you choose with the **24 hours**, **7 days**, **30 days**, or **90 days** selector. The summary tiles show the number of requests, the input and output token counts (a token is roughly a piece of a word, and it is the unit that Claude's usage is measured in), and, in the self-managed view, the estimated spend for the selected window. The **Token usage** chart plots input and output tokens over the window. It shows hourly data when you select the 24-hour window and daily data for the longer windows. The **Active users over time** chart plots the number of distinct users who made at least one request in each period of the window, using the same hourly or daily buckets as the token chart. The **By product** table breaks usage down by which Claude product it came from (for example, Claude Desktop or Claude Code), with the same request, token, and spend columns as the other tables. This table only appears once your deployment has recorded usage from at least one product. The **By model** table lists each model used in the window along with its request count, input tokens, output tokens, and, in the self-managed view, its spend. The **Top users** table lists the most active users in the window with the same columns. The table starts with ten rows, and you can click **Show more** to reveal additional users. Up to 100 users are listed individually, and beyond that a note tells you how many more are not listed. ## CSV exports The **Download** menu at the top of the page, next to **Refresh**, saves what the page shows as CSV files. **All** downloads a ZIP archive of the current view, one CSV file per table. The other entries download one table each: **Summary**, **Usage over time**, **By product**, **By model**, and **Top users**, with **Credit burndown** and **Credit top-ups** added in the self-managed view. The menu becomes available again 30 seconds after the previous download. Exports follow the view and the time window you have selected. The credit files match the burndown chart, reaching back 30 days, or 90 days when you select the **90 days** window. In the summary file, the credit figures are the account's position at the time of the export, not spend within the window. The ZIP archive includes an `export_info.csv` file recording the export's context, including when it was made, the organization, the view, the window and its date range, and the time zone the dates are in. In the self-managed view it also records the date range the credit files cover. File names state the view, the time span, and the dates covered, and single-table files also name their table. The top users file lists every user the **Top users** table can show, whether or not you have expanded the table with **Show more**, and adds each user's ID and account status to the columns shown on screen. ## Things to know * Claude for Government does not currently offer a programmatic usage or analytics API. Usage data is available through this admin portal page. The [Compliance API](/docs/government/org-admin/compliance-api) returns governance and audit events, not usage metrics. * A user counts as **active** in the selected window if they made at least one request in it, regardless of which seat tier they were on at the time. * The **spend** column appears only in the self-managed view and is the amount debited from your billing account's balance. The managed view has no spend column because managed-tier usage is covered by the seat price rather than by credit drawdown. * To see how close each user is to their 5-hour and 7-day limits, use the **Usage** bars on the [Users](/docs/government/org-admin/users) page. The **Top users** table on this page shows how much each listed user consumed in the window, not how close they are to a limit. * If the credit panel is missing from the self-managed view, credit data for your organization's billing account is unavailable. The rest of the page will still load. * Usage that was cleared with **Reset usage limits** on the [Users](/docs/government/org-admin/users) page still appears here. The reset only clears the counter that enforces a user's limit; it does not remove the activity from analytics.
government/org-admin/billing First recorded · 46 lines, first recorded
# Billing ## Billing account ## Seats ### Rules for changing seat allocations
The first capture of this source. The page was already there, and this is what it said.
# Billing > Use this page to see the balance your organization spends from and any spend caps set on it, and to adjust your organization's seat allocation. > **Who this is for:** Organization owners who want to see the balance their organization spends from and any spend caps set on it, and manage their organization's seat allocation. Use this page to see the balance your organization spends from and any spend caps your tenant administrator has set, and to adjust your organization's seat allocation. A **billing account** is the funding pool that pays for one or more organizations in your tenant. Your organization's usage on self-managed seat tiers draws directly from this account's balance, and Anthropic adds credit to the account. Your tenant administrator can also set a **spend cap** on your organization, which limits how much it can draw from the account in a rolling 5-hour or 7-day window. <Note> The **Billing** tab appears in the navigation when the billing account is active and your own organization is active on it. If the tab is hidden, this page is still reachable from a direct link. Funding is arranged with Anthropic by your tenant administrators; contact them about credits or spend caps. </Note> ## Billing account At the top you see the billing account's available balance, or, when the balance is not shown to you, a line explaining who manages the account. The balance is shared by every organization the account funds. Below the balance, the page shows the spend caps currently set on your organization, in the form "\$X per 5 hours, \$Y per 7 days", or "No spend caps are set" if none are. These caps are set by your tenant administrator and cannot be changed here. A cap of \$0 pauses your organization's spending from the account, and a banner appears on this page saying so. When the account's balance reaches 70 percent, 90 percent, and 100 percent consumed, a spend-alert banner appears on every page of the organization admin portal and an email is sent to your organization's owners. The banner stays in place until Anthropic adds more credits to the account. Your organization's usage against the account balance is shown on the [Analytics](/docs/government/org-admin/analytics) page. ## Seats The **Seats** section shows the pool of Anthropic-managed seats funded by this account. For each tier the table shows the **Pool** total, which is the number of seats granted to the account, the **Distributed** count, which is how many of those seats have been handed out to organizations, and the **Remaining** count, which is the number still available to distribute. <Note> The seat allocation editor below only appears when the account has at least one seat tier in its pool. </Note> An editor below the table lets you set how many seats of each tier your organization holds. Enter the number you want for each tier and click **Save**. The change takes effect immediately. ### Rules for changing seat allocations The editor enforces the following rules and will refuse a save that violates any of them. * You cannot request more seats for a tier than the billing account has remaining in its pool after accounting for other organizations. * You cannot reduce a tier's seat count below the number of users currently seated on it in your organization. Move users off the tier on the [Users](/docs/government/org-admin/users) page first, then lower the count. * You can set a tier to zero seats, which removes the tier from your organization entirely, but only if no one is seated on it. * Each tier's seat count can be at most 100,000. <Tip> Saving a seat allocation also triggers a directory provisioning sync. If users were previously left unassigned because a tier was full, the sync will now seat them automatically up to the new limit. </Tip>
government/org-admin/compliance-api First recorded · 152 lines, first recorded
# Compliance API ## Managing API keys ## Calling the API ### Query parameters ### Response format ### Identifying users ### Activity types ## Connecting to your SIEM ## When the API is disabled ## Things to know
The first capture of this source. The page was already there, and this is what it said.
# Compliance API
> Stream your organization's audit events into a SIEM or log management system.
> **Who this is for:** Organization owners and the security or compliance teams who connect Claude for Government to their agency's log management or SIEM platform.
The Compliance API is a read-only HTTP endpoint that lets your security tools pull a continuous feed of audit events covering administrative activity across your organization, such as sign-ins, role changes, key creations, and seat assignments. A scheduled job can poll the endpoint and forward each event to a SIEM such as Splunk or Microsoft Sentinel.
The API is available to every Claude for Government organization by default, and it is read-only, so a compromised key cannot change anything in your organization.
## Managing API keys
Open **Compliance API** in the organization admin portal to create and manage keys. The page lists every key that has been issued for your organization, showing its name, a hint with the last few characters of the key so you can tell them apart, when it was created, and whether it is active or revoked.
To create a key, enter a name and click **Create key**. The full value is shown once, immediately after creation. Copy it somewhere safe before clicking **Done**.
<Warning>
The full key value is shown **only once**, at creation time. If you lose it, create a new key and revoke the old one.
</Warning>
Keys never expire on their own, so rotate them on whatever schedule your agency's policy requires. You can keep more than one key active at a time, which lets you rotate without interrupting your SIEM feed: create a new key, update your collector to use it, confirm events are still arriving, and then revoke the old key. Revoking a key takes effect immediately, and the next request made with it returns a 401.
Each key is scoped to the organization it was created in. A request can only ever return events for that one organization, regardless of who holds the key.
## Calling the API
Send a GET request to `/v1/compliance/activities` on the Claude for Government host provided to you during onboarding, with your key in the `x-api-key` header.
```http theme={null}
GET /v1/compliance/activities?since=2026-07-01T00:00:00Z&limit=500
Host: <your-deployment-host>
x-api-key: <your-compliance-api-key>
```
### Query parameters
| Parameter | Description |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `since` or `created_at.gte` | The earliest event time to return, as an RFC 3339 timestamp or epoch seconds. A lower bound is required on every request that does not carry a cursor. |
| `until` or `created_at.lte` | The latest event time to return, in the same format. Optional. |
| `after_id` | An opaque cursor that continues from where a previous page left off. Pass the `last_id` value from the previous response. |
| `before_id` | An opaque cursor that pages in the other direction. Pass the `first_id` value from the previous response. Cannot be combined with `after_id`. |
| `actor_ids[]` | Return only events performed by the listed actors. Repeat the parameter to pass more than one. |
| `activity_types[]` | Return only events of the listed types. Repeat the parameter to pass more than one. |
| `limit` | Maximum events per page, from 1 to 5000. Defaults to 100. |
The exclusive bounds `created_at.gt` and `created_at.lt` are also accepted if your collector needs them.
### Response format
The response is a JSON envelope containing a page of events and the cursors for the next and previous pages.
```json theme={null}
{
"data": [
{
"id": "activity_01js0example000000000000",
"type": "user.signed_in",
"created_at": "2026-07-01T14:22:09.412Z",
"organization_id": "org_00000000-0000-0000-0000-000000000000",
"organization_uuid": "00000000-0000-0000-0000-000000000000",
"actor": {
"type": "user_actor",
"user_id": "usr_00000000-0000-0000-0000-000000000000",
"email_address": "[email protected]"
},
"user_id": "usr_00000000-0000-0000-0000-000000000000",
"user_email": "[email protected]"
}
],
"has_more": true,
"first_id": "<opaque cursor>",
"last_id": "<opaque cursor>"
}
```
The `actor` object identifies who performed the action. Its `type` is one of:
* `user_actor` for a person acting through the product or admin portal.
* `admin_api_key_actor` for an action taken through an administrative API key.
* `anthropic_actor` for an action performed by Anthropic personnel or systems on your behalf, such as initial provisioning. No individual identity is included.
Each event also carries fields specific to its type, such as the role a user was changed to or the name of a key that was created.
### Identifying users
When one of your own users performs an action, `actor.user_id` and `actor.email_address` name them, including on sign-in events. Actions taken by Anthropic personnel or automated systems appear as `anthropic_actor` with no individual identity, by design.
On every `user.*` activity, two top-level fields identify the user the event is about, so your SIEM can map events back to people in your directory without a separate lookup.
| Field | Description |
| ------------ | -------------------------------------------------------------------------------- |
| `user_id` | The Claude for Government user ID, in the same `usr_` format as `actor.user_id`. |
| `user_email` | The user's email address at the time of the event. |
The user an event is about is not always the actor. When an owner changes someone's role, the `actor` block names the owner and these fields name the user whose role changed.
```json theme={null}
{
"id": "activity_01js1example000000000000",
"type": "user.role_changed",
"created_at": "2026-07-02T09:18:33.205Z",
"organization_id": "org_00000000-0000-0000-0000-000000000000",
"organization_uuid": "00000000-0000-0000-0000-000000000000",
"actor": {
"type": "user_actor",
"user_id": "usr_00000000-0000-0000-0000-000000000001",
"email_address": "[email protected]"
},
"user_id": "usr_00000000-0000-0000-0000-000000000002",
"user_email": "[email protected]",
"old": "user",
"new": "owner"
}
```
The top-level `user_id` and `user_email` fields appear on activities recorded after they were added to the API. Earlier activities are not updated, so your collector should treat these fields as optional.
### Activity types
Event types use a dotted `resource.action` naming convention. The categories emitted today include:
* **Users** such as `user.created`, `user.signed_in`, `user.role_changed`, `user.deactivated`, and `user.reactivated`.
* **Organizations** such as `org.created`, `org.renamed`, and `org.deactivated`.
* **Credentials** such as `api_key.created`, `scim_token.created`, and `scim_token.revoked`.
* **Seats and tiers** such as `seat_allocation.set`, `seat_allocation.tier_assigned`, `seat_tier.created`, and `seat_tier.updated`.
* **Configuration** such as `org_config.capabilities_set`.
New types may be added over time, so a collector should forward unfamiliar types rather than reject them.
## Connecting to your SIEM
Most deployments run a small scheduled worker that polls the API on a fixed interval, forwards each event to the SIEM's HTTP ingest endpoint, and records a time watermark so the next run picks up where the last one left off.
A typical run requests `since=<watermark>`, forwards every event returned, and if `has_more` is true, follows `after_id=<last_id>` for each further page until `has_more` is false. After all pages are drained, advance your watermark to the newest `created_at` you saw. Event `id` values are stable and unique, so your collector can deduplicate on `id` and safely retry a page or use an overlapping `since` without creating duplicate records in the SIEM.
## When the API is disabled
Your tenant administrator can turn off the **Compliance API** setting on the [tenant Config page](/docs/government/tenant-admin/configuration). When that setting is off, the Create key button is hidden in the portal, and every call to `/v1/compliance/activities` returns a 400 error, including calls made with keys that were valid before the setting changed.
Listing and revoking existing keys in the portal remains available even when the setting is off, so an exposed key can still be revoked.
## Things to know
* The Claude for Government Compliance API is served from the Claude for Government service hostname, not from `api.anthropic.com`. Use the same host you use to reach the admin portal.
* There is no separate Splunk add-on. The polling pattern described under [Connecting to your SIEM](#connecting-to-your-siem) is the reference implementation for a Splunk HTTP Event Collector job.
* The desktop application's OpenTelemetry export is a separate log stream configured with **Telemetry endpoint (Claude Desktop)** on the [Config](/docs/government/config/settings#telemetry-endpoint-claude-desktop) page. It carries per-session tool and telemetry events to a collector you specify, while this API carries administrative audit events. See [Telemetry and egress](/docs/third-party/claude-desktop/telemetry) for what the OpenTelemetry export includes.
* The Compliance API returns governance and audit events only. It does not return conversation content, files, or anything your users type into Claude.
* Each organization can hold up to 50 active keys at once. Revoked keys do not count toward this limit.
* Events are returned newest first within each page.
* `first_id` and `last_id` are opaque cursors. Pass them back exactly as received rather than constructing them yourself.
* If your network enforces a [tenant restriction](/docs/government/tenant-admin/tenant-restrictions), the same restriction applies to Compliance API requests.
government/org-admin/configuration First recorded · 21 lines, first recorded
# Config at the organization level ## What is specific to the organization level
The first capture of this source. The page was already there, and this is what it said.
# Config at the organization level > View and change the product settings that apply to everyone in your organization, and see where each effective value comes from. > **Who this is for:** Organization owners who set product behavior, such as the session timeout, Claude Desktop banner, and product availability, for everyone in their organization. Use this page to view and change the product settings that apply to everyone in your organization, and to see where each effective value comes from. The Config page works the same way at the tenant and organization levels, with the same list of settings. See [How Config works](/docs/government/config/overview) for the levels model, locks, groups, comparing across levels, and looking up one person's settings, and [Available settings](/docs/government/config/settings) for what each setting does. This page covers only what is specific to the organization level. ## What is specific to the organization level **Managed settings.** A setting that your tenant has locked shows as **Managed** and is read-only here. Any value you had previously set is ignored while the lock is in place, and it comes back into effect if the tenant later removes the lock. See [Locks](/docs/government/config/overview#locks). **Settings only the tenant can change.** [Let organizations manage their own seat tiers](/docs/government/config/settings#let-organizations-manage-their-own-seat-tiers) and [Compliance API](/docs/government/config/settings#compliance-api) are always read-only here, regardless of whether they are locked. **Inherited plugins.** Plugins the tenant has added are labeled **Inherited from your tenant** and cannot be changed from here. See [Tool and connector cards](/docs/government/config/settings#tool-and-connector-cards). **Group settings within your organization.** A value you set for a directory group at this level applies only to people who are both a member of the group and a member of your organization, and it is the most specific level in the chain. Group priority is set by your tenant administrator and is shown here for reference; you cannot reorder it from the organization portal. See [Group-specific settings](/docs/government/config/overview#group-specific-settings). **Your own organization only.** Organization owners manage only their own organization's Config page. Tenant administrators can open any organization's Config page and act on that organization's behalf.