Available settings

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.

​

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 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 page is also unavailable.

​

Compliance API

Controls whether the 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.

​

Telemetry endpoint (Claude Desktop)

The base address of the collector where Claude Desktop sends usage telemetry using the OpenTelemetry 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 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 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.

​

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. 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 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 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 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 for how each component behaves in Claude for Government and the 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 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.