Skip to content

Claude Code activity

Claude Code can send a record of each tool it runs to Trustle. Trustle stores each call on the person’s Claude Code agent. Admins see the calls on the agent’s page: the time, the Claude session, the MCP server, the tool, the arguments, and the result.

You turn this on once for the whole organization. You create a telemetry key in Trustle, and you push the Trustle settings to every Claude Code harness through Claude managed settings. A person cannot turn the settings off. Claude Cowork has its own setting for the same key. See Step 3.

  1. Claude Code sends OpenTelemetry log events to the Trustle endpoint. The telemetry key in the request tells Trustle which organization the events belong to.
  2. Each event carries the email of the person who signed in to Claude Code. Trustle finds the Trustle user with that email.
  3. Trustle stores the call on that person’s Claude Code agent. Trustle creates the agent on the first call. All the sessions of one person go to the same agent. The Claude session id keeps the sessions apart.

Trustle does not store a call when the email is missing or does not belong to an active user of the organization.

  • You need the org admin role in Trustle.
  • To push the settings, you need one of these:
    • The Owner or Primary Owner role in a Claude for Teams or Claude for Enterprise organization. You use the claude.ai admin console.
    • A device management tool, such as Jamf or Intune, or another way to put a file on each computer.
  • People must sign in to Claude Code with their claude.ai account. Other sign-in methods send no email. See What Trustle cannot see.
  1. In Trustle, open Policies.
  2. Find the Claude Code Telemetry card and click Create Key.
  3. Copy the Managed Settings block. Trustle shows the key only once. If you lose it, click Rotate Key to get a new one.

The block looks like this:

{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_LOGS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/json",
"OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "<endpoint>",
"OTEL_EXPORTER_OTLP_LOGS_HEADERS": "Authorization=Bearer <key>",
"OTEL_LOG_TOOL_DETAILS": "1"
}
}

OTEL_LOG_TOOL_DETAILS makes Claude Code include the tool arguments and the MCP server name. Without it, Trustle shows the tool but not its arguments. For most MCP calls, Trustle also does not show the server. The exception is the built-in servers of the Claude desktop app, which Claude Code always names.

Use one of the two options, or both. Option B is still necessary for the sign-in keys below.

When both options set telemetry variables, Claude Code takes the exporter variables as one set from the claude.ai admin console. These are the OTEL_EXPORTER_OTLP_* variables, OTEL_LOGS_EXPORTER, and the OTEL_LOG_* variables. An endpoint from one source never pairs with a key from the other. Claude Code combines the other env variables, such as CLAUDE_CODE_ENABLE_TELEMETRY, one variable at a time. This needs Claude Code 2.1.223 or later. Earlier versions take the whole env block from one source.

We recommend that you also force people to sign in with a claude.ai account of your Claude organization. Add these keys next to the env block:

{
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": "<claude-organization-id>"
}

With these keys, Claude Code does not start with an API key or with an account of another Claude organization. A token from claude setup-token can still start a session, and that session sends no email. Push these two keys with option B. Claude Code reads the console settings only after the person signs in, so the console cannot control the first sign-in. When a device has these keys in a file or a device policy, Claude Code uses them and not the console values. If you also use option A, set the two keys in the console too, until every computer runs Claude Code 2.1.299 or later.

  1. In claude.ai, open Organization settings > Claude Code > Managed settings.
  2. Paste the block from Step 1. If the editor already has settings, add the env keys to the existing env block.
  3. Save the settings.

Claude Code gets the settings when it starts, and checks for changes every hour.

The settings point Claude Code to a new telemetry endpoint. Anthropic documents that Claude Code can ask each person to approve such settings in an interactive session. If the person does not approve, Claude Code closes. Claude Code keeps one approval for each person and organization. A non-interactive run, such as claude -p, applies the settings for that run without a question.

The console settings do not reach every kind of session:

  • Cowork never gets the console settings. Cowork has its own telemetry setting. See Step 3.
  • A session that uses Amazon Bedrock, Google Vertex AI, Microsoft Foundry, or a custom ANTHROPIC_BASE_URL does not get the console settings.

Option B: A managed settings file or a device policy

Section titled “Option B: A managed settings file or a device policy”

Put the block from Step 1 on each computer in one of these places:

System Location
macOS file /Library/Application Support/ClaudeCode/managed-settings.json
macOS configuration profile Preference domain com.anthropic.claudecode, with the same top-level keys
Linux and WSL /etc/claude-code/managed-settings.json
Windows file C:\Program Files\ClaudeCode\managed-settings.json
Windows registry A REG_SZ value named Settings under HKLM\SOFTWARE\Policies\ClaudeCode, with the JSON as the value

Claude Code reads these locations when it starts. A device policy is checked for changes every 30 minutes. A file is read again when it changes.

The file and the device policy also apply to the Claude Code sessions that the Claude desktop app starts on that computer, including local Cowork sessions.

Anthropic publishes starter templates for Jamf, Intune, and Group Policy in the Claude Code MDM examples.

Claude Code cloud sessions and cloud scheduled tasks (formerly routines) run on Anthropic’s servers, not on a person’s computer. They get the settings from the claude.ai admin console (option A). They never get a file or a device policy (option B).

A cloud session sends the calls through the network of its cloud environment. The Default environment allows only a fixed list of hosts, so it blocks the Trustle endpoint. The session still runs, but Trustle receives nothing. Allow the endpoint’s host in each cloud environment that people use:

  1. Open the environment settings. For a scheduled task, open the task, click Edit, then Advanced settings > General > Cloud environment.
  2. Set Network access to Custom.
  3. Add the host of the endpoint from Step 1 to Allowed domains. Keep Also include default list of common package managers selected.
  4. Save the environment.

No managed setting adds a host to an environment. Each person’s own environments need the host. To give everyone one environment, an Owner can create an organization-shared environment with Custom network access and the Trustle host.

Cloud sessions send the same identity as a local claude.ai session: the email of the person who owns the session or the task.

Claude Cowork does not get the Claude Code settings from the claude.ai admin console (option A). Cowork telemetry has its own setting in the admin console. Trustle stores Cowork calls on the same Claude Code agent as the person’s Claude Code calls.

  1. In claude.ai, open Organization settings > Data and privacy.
  2. Under Monitoring, find the section for Cowork, Cowork in the cloud, and unified chat and Cowork.
  3. In OTLP endpoint, enter the endpoint from Step 1 without the /v1/logs at the end. Cowork adds that path itself.
  4. Set OTLP protocol to http/json.
  5. In OTLP headers, enter Authorization=Bearer <key> with the key from Step 1.
  6. Click Save changes. New Cowork tasks use the settings. Tasks that are already running do not.

Cowork adds the Trustle host to its own network allowlist, so you do not need to change a cloud environment for Cowork.

What Trustle receives depends on where the task runs. The Cowork in the cloud setting in Organization settings > Cowork controls this.

Where the task runs Tool and server Tool arguments
Cowork in the cloud Tool name only. A connector call shows as mcp_tool, with no connector name. Not sent
Cowork on the person’s computer Tool and server. A connector shows its connector ID instead of its name. Shell commands show the server workspace. Only with the device setting below

To receive the arguments of Cowork tasks that run on people’s computers, set otlpContentCapture to ["toolDetails"] in the Claude Desktop managed configuration on each computer. Use your device management tool and the preference domain com.anthropic.claudefordesktop on macOS. Cowork in the cloud never sends tool arguments.

  1. On one computer, start Claude Code and run claude doctor. For option A, the Managed settings (remote) line says that the settings loaded. For option B, run /status in a session and look for the managed settings source.
  2. Ask Claude Code to run a tool, such as a shell command.
  3. In Trustle, open Agents and find the Claude Code agent of that person. The Session Activity tab shows the call in the Tool Calls card within a few minutes.

No. Settings in managed settings take precedence over the person’s own settings and shell variables. Trustle tested these attempts with the settings in a managed settings file and in the claude.ai admin console. Claude Code sent each call to Trustle:

  • CLAUDE_CODE_ENABLE_TELEMETRY=0 in the user settings or the shell
  • OTEL_LOGS_EXPORTER=none in the user settings or the shell
  • A different OTEL_EXPORTER_OTLP_LOGS_ENDPOINT in the user settings
  • DISABLE_TELEMETRY=1 in the user settings, or OTEL_SDK_DISABLED=true in the shell
  • A --settings file that sets all of the above

A person can still avoid the record if they sign in with a method that sends no email. The forceLoginMethod setting in Step 2 prevents this.

  • Sessions without a claude.ai sign-in. Sessions that use an API key, a token from claude setup-token, Amazon Bedrock, or Google Vertex AI send no email. Trustle cannot tell who ran them and does not store their calls.
  • Which account a tool used. The record shows which person ran Claude Code. It does not show which account an MCP server or a connector used.
  • Cloud sessions that cannot reach Trustle. A cloud session or a scheduled task in an environment that does not allow the Trustle host sends nothing. See Cloud sessions and scheduled tasks.
  • Tool details of Cowork in the cloud. Trustle sees the person, the time and the tool name, but not the connector or the arguments. See Step 3.
  • Cloud sessions in Claude Tag. These sessions do not get managed settings.
  • Rotate Key keeps the endpoint and replaces the key. Update the Authorization header in managed settings right away. Until you do, Trustle rejects the events.
  • Revoke Key ends the key and its endpoint. A new key gets a new endpoint, so you must update the whole block.

No calls show on the agent page.

  • Run claude doctor. If it says that Claude Code skipped the fetch of the managed settings, look for CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, or ANTHROPIC_BASE_URL in the person’s shell.
  • Make sure that the person signed in with claude.ai. Run claude auth status and check that authMethod is claude.ai and that email shows their address.
  • Make sure that the email belongs to an active user in Trustle.
  • Make sure that the key in managed settings is the current key. After a rotation, the old key no longer works.

The approval dialog appears again. Claude Code asks again when the settings that need approval change, and when a person signs in with a different account.