Telemetry and egress

When Claude Desktop on third-party (3P) is configured with Google Cloud’s Agent Platform, Amazon Bedrock, or Microsoft Foundry, the app sends conversation content only to your configured inference endpoint. The app does, by default, send a small amount of operational telemetry (crash reports and product analytics) that helps Anthropic diagnose issues and improve the product. Each category can be disabled independently via managed configuration. Data handling at the inference endpoint depends on the provider. For Google Cloud’s Agent Platform and Amazon Bedrock, data handling is governed by the cloud provider. For Microsoft Foundry, Anthropic operates the Claude models and handles conversation data as an independent processor for Microsoft. See Data handling by provider on the Overview page for each provider’s data path. This page covers what each telemetry category contains, how to turn it off, and the complete set of outbound hostnames the app uses so you can configure your perimeter firewall.

​

Telemetry categories

​

Essential telemetry

Crash reports, error stack traces, and performance timings. Contains diagnostic metadata (app version, OS, error type, redacted stack frames) but never prompt or response content. Attributed to your organization via deploymentOrganizationUuid so Anthropic support can find issues you report.

​

Non-essential telemetry

Product-usage analytics: feature adoption, session counts, UI interactions. Used to understand how Claude Desktop is used in aggregate. Contains no prompt or response content. Also gates the Send button in Help → Generate Diagnostic Report; with this disabled, diagnostic bundles can only be saved locally. Leaving this enabled also adds api.anthropic.com to the agent egress allowlist automatically, so Claude Code can deliver its usage telemetry from inside the sandbox. Allow that host at the perimeter too; it appears in the non-essential telemetry table below.

​

Non-essential services

Cosmetic third-party fetches: favicons for connectors shown in the UI, the sandboxed iframe that renders interactive artifact previews, and the sandboxed iframes that render MCP Apps, the interactive widgets connectors can display. Disabling these degrades the UI (generic icons, static artifact previews, and connector tool results shown as text instead of widgets) but doesn’t affect functionality.

​

Auto-updates

Checks Anthropic’s update feed and downloads new builds.

​

Sending telemetry to your own collector

Independently of what’s sent to Anthropic, you can export session activity to your own OpenTelemetry collector by setting otlpEndpoint. This is the recommended way to retain an audit trail in environments that disable Anthropic-bound telemetry. For third-party deployments, the export includes session metadata (event names, durations, token counts, result counts, errors) by default, but not message content. It also identifies the signed-in user; see User attribution. See Monitoring for the event schema and the otlp* keys in the configuration reference. The export carries logs and metrics. Cowork sessions, Code sessions, and the desktop application’s own events arrive under the service.name values cowork, claude-code-desktop, and claude-desktop respectively. The app adds the collector host to the sandbox egress allowlist automatically, so otlpEndpoint does not need an entry in coworkEgressAllowedHosts; your perimeter firewall still needs to allow the host. For collector authentication headers, extra resource attributes, and the log level of the desktop application’s own event stream, see otlpHeaders, otlpResourceAttributes, and otlpDesktopLogLevel in the configuration reference.

​

Collector endpoint and headers

Set otlpEndpoint to the base address of your collector’s OTLP/HTTP receiver, for example https://otel-collector.example.com:4318. The app appends the OpenTelemetry request paths itself (/v1/logs, /v1/metrics, and /v1/traces when traces are enabled), so enter the address without those suffixes. A path prefix in front of them, such as https://observability.example.com/otlp, is kept. The receiver must implement the OpenTelemetry protocol (OTLP) over HTTP in both its protobuf and JSON encodings, as an OpenTelemetry Collector does by default. 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 set otlpEndpoint to the collector’s address. Each device opens its own connection to the collector, so the collector must present a TLS certificate the operating system trusts. See TLS-intercepting proxies if a TLS-intercepting proxy sits in between. otlpHeaders is a JSON object that maps each header name to its value, for example {"Authorization":"Bearer <token>","X-Tenant":"agency"}. As with the other object-typed keys described under Value types, write it as a JSON string. The app reads both keys at launch, so users must restart it after a change. If the collector refuses requests or cannot be reached, the app keeps working, shows no error, and drops the affected telemetry batches. Check the collector’s own request logs to confirm data is arriving. For a collector credential that cannot be a static header, otlpHeadersHelper names a script on the device that prints the headers, and otlpAuthMode set to inference-credential sends the user’s own inference bearer token, which suits only a collector you operate. The configuration reference describes both.

​

User attribution

Every record sent to your collector carries the user’s identity as two resource attributes, on all three service.name streams:

• enduser.id — the signed-in user’s identity. With an interactive sign-in flow (for example, Workforce Identity Federation or Google sign-in on Google Cloud’s Agent Platform), this is the identity from the provider’s claims, normally the user’s email address. With credential methods that carry no identity claims (a static key, a credential helper, or an application default credentials file), it is the operating-system login name.
• process.owner — the operating-system login name.

enduser.id is the same identity the app shows in the sidebar and account menu, and is controlled by the endUserAttribution key: set it to false to remove the identity from both the app and the export. process.owner is not gated by that key — it is standard OpenTelemetry process metadata and is always present. A static value set under otlpResourceAttributes overrides either attribute: a static enduser.id is always passed through — taking precedence over the signed-in identity, and surviving endUserAttribution: false — and a static process.owner replaces the login name. These attributes are attached only to the OpenTelemetry export; the Anthropic-bound telemetry described earlier on this page does not carry them.

​

Exporter protocol

The otlpProtocol key selects the transport for the telemetry export to your collector: http/protobuf (the default), http/json, or grpc. The protocol applies per session type:

• Code sessions export over the protocol as configured, including grpc.
• Cowork and Chat sessions export over the protocol as configured, except that when otlpProtocol is grpc they export over http/protobuf instead on Windows, and on other platforms whenever the Claude Code engine is given an HTTP proxy (from the operating system’s proxy settings, a pinned proxy, or HTTPS_PROXY/HTTP_PROXY in a Claude Code settings file).
• The desktop application’s own event stream (claude-desktop) always exports over http/json, whatever otlpProtocol is set to.

These substitutions change the protocol only, not the endpoint. A stream that exports over HTTP while otlpProtocol is grpc still goes to the same otlpEndpoint; if that address is your collector’s OTLP/gRPC receiver (conventionally port 4317), that telemetry never reaches the collector. To receive all three streams with one collector, set otlpProtocol to http/protobuf and point otlpEndpoint at the collector’s OTLP/HTTP receiver (conventionally port 4318).

​

Content capture

To include content in the export, set otlpContentCapture to an array of categories: On Claude Desktop version 1.17377 or later, enabling userPrompts also captures model responses, even if assistantResponses is not listed. On those versions, no otlpContentCapture configuration captures user prompts without model responses. Conversation titles arrive on the desktop application’s own stream (claude-desktop) as a desktop_session_title_set event that carries each Cowork and Code session’s title and the Claude Code session.id to join on. The event is exported only when otlpDesktopLogLevel is info or debug, and the title text is included only when otlpContentCapture includes userPrompts. Requires Claude Desktop 1.44121.1 or later. Content is exported only to your configured otlpEndpoint. Anthropic does not receive it.

​

Traces (beta)

The export carries logs (events) and metrics; it does not include traces unless you enable them. To export OpenTelemetry traces as well, set otlpTracesEnabled to true. Cowork and Code sessions then record a trace for each user interaction, with spans for model requests and tool executions, and every event emitted during a span carries that span’s trace_id and span_id. This lets your backend correlate a prompt’s events end-to-end natively, with no transformation on ingest. Traces use the same otlpEndpoint and otlpProtocol as the rest of the export, including the gRPC fallbacks described in Exporter protocol. Span and span-event content is gated by the same otlpContentCapture categories as events: with no categories enabled, traces carry metadata only (timing, tool names, durations, token counts). Captured content appears primarily on events; spans stay close to metadata. Two scope notes:

• The metrics in this export don’t carry trace context, so trace-based correlation covers traces and events. Correlate metrics with a session via the session.id attribute.
• Trace export uses Claude Code’s session-tracing beta, and the span structure may change while the feature is in beta.

With otlpEndpoint set, otlpTracesEnabled alone decides whether Cowork and Code sessions export traces. Leaving it unset or false keeps traces off even when Claude Code’s own settings on the device, including managed settings, turn tracing on (Claude Desktop 1.52386.0 or later). otlpTracesEnabled requires Claude Desktop 1.22209.0 or later.

​

Required egress paths

Claude Desktop on 3P has two independent network boundaries:

1. Perimeter firewall: your corporate network controls what the device can reach. The hostnames below are what you allowlist here.
2. Agent egress allowlist: the coworkEgressAllowedHosts key controls what the agent’s web-fetch and shell tools can reach. This is independent of, and stricter than, the perimeter.

All traffic is HTTPS on port 443. Allowlist by hostname (SNI); path-level rules aren’t required.

​

Always required

Without this host reachable, Cowork sessions cannot start, unless the app was installed with the offline installer variant, which includes both components in the installer package.

​

Inference provider

The host(s) for your configured provider. These carry conversation content.

​

Auto-updates (disableAutoUpdates: false)

With updateViaUpdatesHost set to true, the app reads the update feed from releases.claude.com instead of claude.ai and api.anthropic.com, so those two hosts are no longer needed for updates. Update binaries still come from downloads.claude.ai.

​

Essential telemetry (disableEssentialTelemetry: false)

The sentry.io apex is listed alongside the wildcards because some firewalls don’t match it under *.sentry.io, and *.ingest.us.sentry.io is listed separately for firewalls that match wildcards one label deep.

​

Non-essential telemetry (disableNonessentialTelemetry: false)

​

Non-essential services (disableNonessentialServices: false)

*.claudemcpcontent.com serves MCP Apps, the interactive widgets connectors can render. Each widget loads in a sandboxed iframe on its own generated subdomain, so allowlist the wildcard.

​

Optional features

​

Disabling all Anthropic-bound connections

With disableEssentialTelemetry, disableNonessentialTelemetry, disableNonessentialServices, and disableAutoUpdates all set to true, the desktop application makes no outbound connections to Anthropic-operated hosts at runtime. If Code sessions can use Web Fetch, also set skipWebFetchPreflight to true (or add WebFetch to disabledBuiltinTools), because Claude Code in Code sessions otherwise checks each fetched domain with api.anthropic.com. The only required egress is downloads.claude.ai (for the VM bundle at session start) and your inference provider. With the offline installer variant, downloads.claude.ai is not needed either, and your inference provider is the only required egress. Enabling SSH remote sessions adds downloads.claude.ai back, except on devices installed with the offline installer that connect only to Linux x64 or arm64 hosts: that installer bundles the remote-session components for those hosts, and connections to hosts on other platforms still download them. Enabling import from claude.ai likewise lets the app reach claude.ai and api.anthropic.com (and storage.googleapis.com for the export download), but only while a user runs a sign-in import from the wizard. An app managed from the Enterprise Admin Console still contacts api.anthropic.com at launch and at each configuration re-check, and claude.ai at sign-in. These settings control only the application’s telemetry, update, and non-essential service connections. They do not change how your inference provider handles conversation content at the endpoint. On Microsoft Foundry, the Claude models behind your inference endpoint run in an Anthropic-operated service, so conversation content reaches Anthropic-operated infrastructure regardless of these settings. See Data handling by provider on the Overview page. See the Locked down profile for a complete configuration.

​

Proxy support

Claude Desktop and the Claude Code engine it runs follow the operating system’s proxy settings by default, including PAC files, and on macOS and Windows so does the Cowork sandbox. You can also pin a specific proxy for all three from managed configuration. See Network proxy for the default behavior, the pinned-proxy keys, the traffic that bypasses the proxy, and TLS-intercepting proxies.