Cowork OTLP monitoring not emitting events despite correct configuration

Confirming this issue — independent reproduction with extensive debugging.

We stood up a simple OTLP-compatible HTTP receiver and verified the exact same behavior:

• OTLP endpoint, protocol (http/json and http/protobuf), and headers all configured correctly in Admin > Cowork > Monitoring
• Receiver confirmed working via direct curl — requests process successfully
• Started multiple fresh Cowork sessions after config changes and full app restarts
• Zero HTTP requests received from Cowork — no POSTs to /v1/logs or the base endpoint
• Process-level network inspection (lsof) confirms the Claude desktop app has no outbound connections to the OTLP endpoint

The exporter simply isn't initializing or firing. This is not an endpoint, auth, or backend issue.

Environment: macOS (Apple Silicon), Claude Desktop (latest, March 2026), Team plan, network egress set to "All domains"

Confirming this issue — independent reproduction with custom ADOT collector backend.

We deployed a standalone AWS ADOT (OpenTelemetry) collector on ECS Fargate behind CloudFront + ALB specifically to receive Cowork OTLP events. The collector is healthy, receiving traces from other
services, and correctly exporting to X-Ray. However, zero events arrive from Cowork.

Environment:

• Claude Desktop 1.2.234 (2d1855), macOS Apple Silicon
• Team plan, Cowork enabled with Dispatch
• Network egress: CloudFront domain added to allowlist

Configuration (Admin > Cowork > Monitoring):

• OTLP endpoint: https://<cloudfront-distribution>.cloudfront.net/otlp
• OTLP protocol: http/protobuf
• OTLP headers: Bearer token configured

Evidence:

1. Endpoint is reachable and working — curl -X POST https://<endpoint>/otlp/v1/traces returns HTTP 200 in <400ms
2. ADOT collector is healthy — receiving and exporting traces from other OTLP sources on the same pipeline, confirming the full ingestion path works end-to-end (CloudFront → ALB → ADOT → X-Ray)
3. Process-level network inspection confirms exporter never fires — ran lsof -i -n -P | grep Claude repeatedly during active Cowork sessions across multiple checks. Claude Desktop only connects to

Anthropic API, AWS, and Google endpoints. Zero connections to CloudFront OTLP IPs — the exporter never initiates an outbound connection.

1. X-Ray trace analysis — all ingested traces originate from our own infrastructure services. Zero traces with Cowork event attributes (session.id, prompt.id, cost_usd, user.account_uuid).
2. Initial tcpdump investigation was misleading — we captured traffic to the CloudFront domain and initially thought Cowork was connecting. Process-level filtering via lsof confirmed those connections came

from our own test tools, not Claude Desktop.

1. Tested across multiple Cowork sessions — quit and restarted Claude Desktop, ran active tasks, checked repeatedly. Same result every time.

Confirming this issue with Azure Application Insights as the OTLP endpoint.

Environment:

• Claude Desktop 1.569.0.0, Windows
• Enterprise plan
• Network egress: Endpoint enabled

Configuration (Admin > Cowork > Monitoring):

• OTLP endpoint: https://[azure region].in.applicationinsights.azure.com/v2.1/track
• OTLP protocol: http/protobuf
• OTLP headers: Authorization=Bearer [instrumentation key]

Evidence:

• Endpoint is reachable and working — curl returns HTTP 405 (expected for GET)
• Claude Desktop logs show OTLP endpoint being added to egress allowlist
• Started multiple fresh Cowork sessions after config save and full device restart
• Zero HTTP requests received by Application Insights — no POST traffic to the endpoint
• Process-level network inspection confirms the Claude app has no outbound connections to the OTLP endpoint

The exporter is not initializing. This is blocking observability for our organization.

We ran into this same issue and were able to get Claude CoWork OTEL exports working by setting CLAUDE_CODE_ENABLE_TELEMETRY=1 in the launch environment of the Claude Desktop app.

This will vary based on OS, but on Mac you can do this either manually or with a .plist file:

Option 1: Set Manually

Most useful for testing/diagnosis -- From any terminal run:

launchctl setenv CLAUDE_CODE_ENABLE_TELEMETRY "1"

...then restart Claude Desktop.

Option 2: Set via .plist

Most useful for MDM -- Create a file ~/Library/LaunchAgents/com.anthropic.claudefordesktop.plist with the contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.anthropic.claudefordesktop</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/launchctl</string>
    <string>setenv</string>
    <string>CLAUDE_CODE_ENABLE_TELEMETRY</string>
    <string>1</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
</dict>
</plist>

Then restart Claude Desktop.

Troubleshooting

In our case, a local network capture via Wireshark showed that no traffic originating from our machines was targeting our configured OTLP endpoint from usage of Claude CoWork

After setting CLAUDE_CODE_ENABLE_TELEMETRY=1 via either method above, we saw network traffic being produced by Claude CoWork activity in Claude Desktop, and it was targeting the OTLP endpoint we'd specifically configured in the Cowork organization settings.

Hope this helps (for those stuck, and for diagnosis by Anthropic)!

@rusnyder it sounds like you had to set an environment variable on a system level and not a cowork settings configuration level to get this to work reliably every time.

I'm wondering if this is something that can be added as a hook in server-managed settings https://code.claude.com/docs/en/server-managed-settings.

Can anyone else confirm?

Attempted @rusnyder's workaround — CLAUDE_CODE_ENABLE_TELEMETRY=1 did not resolve the issue in our environment.

Environment:

• Claude Desktop 1.2278.0, macOS 26.4 (Apple Silicon)
• Team plan, Cowork enabled
• OTLP endpoint: Sumo Logic (US2 region, HTTPS)

What we tried:

• Set CLAUDE_CODE_ENABLE_TELEMETRY=1 via launchctl setenv, restarted Claude Desktop
• Confirmed the variable is present in the Claude Desktop process environment via ps -E
• Confirmed launchctl getenv CLAUDE_CODE_ENABLE_TELEMETRY returns 1

What we observed:

• lsof on the Claude Desktop process during an active Cowork session shows zero outbound connections to our OTLP endpoint — only connections to Anthropic API, Google Cloud, and AWS
• Zero OTLP data arriving in Sumo Logic from any Claude/Cowork service name

@rusnyder — are you configuring the OTLP endpoint via the Admin UI, or via MDM/managed configuration?

Was able to resolve my issue. I have no idea but now they surfaced the attributes menu. I did everything else in this thread. now if you are using datadog at least my queries service:cowork or service:claude-cowork now work and I'm able to receive logs.

I believe it was due to them exposing the event attribute for service.name but I also was not looking for service:cowork.

I'm just glad its working and hope everyone best of luck.

<img width="2394" height="1214" alt="Image" src="https://github.com/user-attachments/assets/4615af26-b52c-4780-add5-30fdae4adc51" />

• https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry
• https://claude.com/docs/cowork/monitoring#service-information

@qwo did you have to do anything else in Datadog besides enabling the open telemetry integration?

@qwo , thanks for posting your solution. Did you also have to set the env variable as someone else explained in another solution ?

launchctl setenv CLAUDE_CODE_ENABLE_TELEMETRY "1"

Answering my own question for others, this is no longer needed for it to work.

Not sure if this will help some people but

the endpoint field in cowork settings wants just the base no path. if you paste in the full https://endpoint.com/blah it breaks, i think Anthropic is doing some hidden validation and wont fire off the logs. Itll append v1/traces or v1/logs

so:

yes: https://endpoint.com
no: https://endpoint.com/v1/traces
Hopefully that helps

Update on our side... I think that Claude fixed this so 'it just works' now. I got it working yesterday after trying solutions from @rusnyder and @qwo at the same time, and then removed both of their solutions to see which one made it work... and as it turns out, it actually works now with the same settings I had a couple of weeks ago when it did not work.

Root cause found — this is a manifestation of #50567 (OTLP exporter packages not bundled in the Cowork VM binary)

Independent reproduction and binary-level investigation points to #50567 as the upstream cause of every "Cowork OTLP config accepted, zero events arrive" report in this thread.

What's actually happening inside the Cowork VM

The Cowork VM ships a bundled Claude Code binary (~/Library/Application Support/Claude/claude-code-vm/<version>/claude) whose OTel SDK initializes correctly but whose OTLP exporter packages are not bundled. The exporter factory does a dynamic require() for the OTLP transport, the require resolves to null, the subsequent { OTLPMetricExporter: H } = ... destructure throws, and a surrounding try/catch silently swallows the error. Zero HTTP requests fire. No error is logged. The configuration UI accepts everything and looks healthy.

Confirming evidence (from the 2.1.111 binary that ships in Claude Desktop 1.3883.0)

Strings on the VM binary:

$ strings -a <bin> | grep -oE '@opentelemetry/[a-z0-9._/-]+' | sort -u
@opentelemetry/api

$ strings -a <bin> | grep -oE 'exporter-[a-z-]+-otlp-[a-z-]+' | sort -u
(no output)

$ strings -a <bin> | grep "Cannot destructure property 'OTL"
Cannot destructure property 'OTLPMetricExporter' from null or undefined value
Cannot destructure property 'OTLPLogExporter' from null or undefined value
Cannot destructure property 'OTLPTraceExporter' from null or undefined value

Only @opentelemetry/api is bundled; every @opentelemetry/exporter-*-otlp-* transport package is absent. The exact silent-swallow error strings from #50567's root-cause analysis are present verbatim.

Inside an active Cowork session, switching to the console exporter confirms the SDK itself is healthy:

CLAUDE_CODE_ENABLE_TELEMETRY=1 \
OTEL_METRICS_EXPORTER=console \
OTEL_METRIC_EXPORT_INTERVAL=2000 \
  claude --print "hello"

Emits claude_code.session.count with full attributes within ~89 ms. The OTel pipeline works end-to-end up to the exporter boundary — only the OTLP transport is broken.

Also verified that the Admin UI → Cowork → Monitoring config (OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, OTEL_LOG_USER_PROMPTS=1, etc.) does propagate correctly into the VM claude subprocess environment. This rules out env-var propagation as the culprit and narrows the failure exclusively to exporter packaging.

Why launchctl setenv CLAUDE_CODE_ENABLE_TELEMETRY=1 helped some people and not others

The Admin UI config already sets everything needed inside the VM subprocess, so that launchctl workaround is orthogonal to the real bug. Whether it "worked" in a given environment correlates with the Desktop build and the coincidental state of the OTLP exporter registry at that moment, not with whether the env var itself was required. @myrison's updated note in this thread ("it just works now with the same settings I had a couple of weeks ago when it did not work") is consistent with intermittent behavior driven by the silent-swallow path, not a deterministic fix.

Why curl from inside the VM works but the Cowork OTLP exporter doesn't

curl is a host-allowed binary that bypasses the Node OTel exporter path entirely. The OTLP exporter in the claude process goes through the exporter factory, which is where the dynamic require fails. Endpoint reachability was never the problem — the request was never constructed in the first place.

Why upgrading standalone Claude Code CLI doesn't fix Cowork

The Cowork VM SDK version is pinned by the Claude Desktop app release (grep -a -oE 'claude-code/[0-9]+\.[0-9]+\.[0-9]+' /Applications/Claude.app/Contents/Resources/app.asar returns the pinned version as a string baked into app.asar). It does not track the npm CLI release channel. Your standalone claude may be 2.1.118+, but the Cowork VM will still run whichever SDK version the installed Desktop pins — currently 2.1.111 for Desktop 1.3883.0, which has the same exporter-bundling bug as 2.1.113.

Bottom line

A fix for this issue requires Anthropic to:

1. Bundle @opentelemetry/exporter-{metrics,logs,traces}-otlp-{proto,http} into the native Claude Code binary (tracked at #50567).
2. Ship a Claude Desktop release that pins a VM SDK version containing that fix.

Until both land, no OTLP configuration in Admin → Cowork → Monitoring will produce events, regardless of backend, protocol, endpoint format, egress settings, or environment variables. Recommend closing this issue as a duplicate of #50567 once the exporter-packaging fix lands, or keeping it open until a Desktop release with a fixed VM SDK ships.

Confirming this is still broken on Claude Desktop 1.4758.0,
macOS Apple Silicon.

Same symptoms as the original report: configured endpoint via
Admin settings > Cowork > Monitoring, settings persist across
relaunches, zero events reach the endpoint.

Additional diagnostic data localizing the failure to env var
injection (not exporter, network, or collector):

1. In-VM probe via Cowork's bash tool:

env | grep -iE "OTEL|TELEMETRY|OTLP" -> empty
cat /proc/self/environ | grep ... -> empty
for p in /proc/[0-9]*/environ; do ... -> empty
None of CLAUDE_CODE_ENABLE_TELEMETRY,
OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_RESOURCE_ATTRIBUTES, or any
variable visible in main.log's env var template are present
in any process inside the agent VM.

1. Binary test with deliberately unreachable endpoint

(http://1.2.3.4:9999): saved + Cmd+Q + relaunch + tool action

• 60s wait. Zero connection-refused or timeout errors anywhere

in ~/Library/Logs/Claude/.log or per-session scan_.log.
The exporter is not initialized at all - no SDK exists to
fail at sending.

1. Earlier build (1.3883.0) produced one log line at session

start: "Replaced localhost in OTLP endpoint with VM host IP".
Build 1.4758.0 produces zero such entries across many VM
boots, suggesting the orchestrator code path that reads saved
config and constructs env vars no longer runs.

1. Network independently verified: curl from inside the VM to

the host's collector returns HTTP 200 in 5ms. Local collector
receives synthetic OTLP payloads correctly. The bug is purely
on the orchestrator side.

Likely overlaps with #39125 and #40495 - same pattern of the
orchestrator failing to propagate config/settings/env into the
Cowork VM, just for different config scopes.

Adding data points from extensive troubleshooting on this issue (May 2026):

Confirmed: external SaaS OTLP endpoints do not work; localhost does

Spent some time on and off attempting to point Cowork OTel directly at a CrowdStrike Pangea AIDR SaaS endpoint (https://api.us-2.crowdstrike.com/aidr/aiguard/v1/otel/logs) on both Windows 11 and macOS.

Despite the endpoint returning HTTP 202 from PowerShell/curl on the host machine, Cowork emitted zero events to the configured endpoint.

Switched the Cowork admin portal endpoint to http://localhost:4318 pointing at a local otelcol-contrib instance, and the full event stream immediately appeared:

• user_prompt
• tool_decision
• tool_result
• api_request
• hook_execution_start
• hook_execution_complete

All with full prompt and tool content. This strongly supports the MITM proxy / hardcoded domain allowlist hypothesis raised in the OP.

Windows 11 secondary issue: Hyper-V Default Switch has no default route

Even before hitting the SaaS endpoint blocking issue, Cowork OTel was completely broken on Windows 11.

Root cause: the Hyper-V Default Switch interface (vEthernet (Default Switch), used by the Cowork sandbox VM) has no 0.0.0.0/0 default route in its routing table by default. Cowork VM packets were being silently dropped at the host routing level — no firewall logs, no destination reached, no errors.

Required manual route addition:

New-NetRoute -InterfaceAlias "vEthernet (Default Switch)" `
  -DestinationPrefix "0.0.0.0/0" `
  -NextHop <physical_NIC_gateway> -RouteMetric 10

The route is non-persistent and must be re-added on reboot via scheduled task. This appears to be a Windows-specific gap not present on macOS (where Apple Virtualization.framework handles routing automatically).

Event schema observation for downstream collectors

Cowork emits events with:

• service.name=cowork
• terminal.type=non-interactive
• Event names like user_prompt, tool_result, api_request (not gen_ai.* prefixed)

The Body field uses claude_code.* prefixed names (e.g., claude_code.user_prompt), but the event.name attribute is unprefixed.

Downstream OTel collectors filtering on gen_ai.* will drop everything.

Workaround that works today (May 2026)

Local otelcol-contrib on each user machine, Cowork pointed at http://localhost:4318. Not a viable production deployment pattern.

A remote OTLP gateway (as Elastic's InfoSec team documented) would solve this but requires the MITM proxy issue to be fixed first.

Confirmed empirically on May 18, 2026 with agent SDK 2.1.142:

• Changed Cowork OTLP endpoint to http://localhost:4318

(per cynicaldev's reported workaround)

• Full Cmd+Q + relaunch
• Opened a new Cowork chat and triggered a tool-using prompt
• Queried Grafana Cloud Tempo for {} over Last 15 minutes:

only synthetic test writes appear, no Cowork-emitted traces

• Queried Grafana Cloud Loki for {service_name=~".+"} over Last

15 minutes: "No logs found" - zero data

Localhost workaround does not apply to all macOS
configurations. Bug persists in 2.1.142 even with localhost
endpoint.

Hitting the exact same symptoms on Windows as a paying Enterprise customer. The current platform:macos label may understate the spread — this affects Windows too. Posting a reproduction in case it helps narrow the bug location.

Environment

• Claude Desktop 1.9255.2 (1dc8f7) — well past the 1.1.4173 minimum stated in the help article
• Windows 11 Enterprise
• Plan: Enterprise
• Org has Cowork enabled and "Allow network egress" toggled ON for the Cowork section
• Domain allowlist set to "Package managers only" + a custom additional allowed domain

Reproduction

1. Stood up a self-hosted Vector 0.43.0 OTLP relay reachable at http://<internal-host>:4318 (and at http://<internal-ip>:4318). Relay receives OTLP/HTTP protobuf and forwards to a downstream SIEM via webhook.
2. Pipeline pre-validated end-to-end with real Claude Code CLI telemetry from the same machine — events flow through Vector → SIEM with full user.email, prompt.id, cost_usd, model, tokens, etc. So the network path and collector are known-good for non-Cowork OTel traffic from this laptop.
3. Configured Cowork OTLP per the docs:

• OTLP endpoint: http://<internal-host>:4318
• OTLP protocol: http/protobuf
• OTLP headers: empty
• Resource attributes: deployment.environment=pilot,surface=cowork,pilot.user=<user>

1. Saved the admin form. Fully quit Claude Desktop (tray → Quit) and reopened.
2. Started a new Cowork session and exercised it with a tool-using task.
3. Waited several minutes.

Result: zero events received at the collector for service.name=cowork. Vector's internal counters confirm no inbound OTLP requests other than the Claude Code CLI traffic from the same machine. The same collector receives Claude Code CLI events fine in the same time window.

What changed when I tested IP-form endpoint

When I later edited the OTLP endpoint field to use the IP form, the admin UI displayed an inline message:

"<internal-ip> will be automatically added to Cowork's network egress allowlist."

No equivalent auto-add message appeared when I originally entered the hostname form. That hostname does not appear in the Cowork allowlist auto-add path the way the IP did. The allowlist also continued to display "Package managers only" with my manually-added domain — the auto-add for the OTLP destination is invisible to the admin UI.

Symptoms / Behavior summary

| Setup | Auto-add to allowlist? | Events arrive? |
|---|---|---|
| Endpoint = hostname | No (or not surfaced in UI) | No |
| Endpoint = IP | Yes (UI displays "will be automatically added to Cowork's network egress allowlist") | No |
| Domain manually added under "Additional allowed domains" | n/a | No |

Suspected bug location

The IP-form admin UI message appears to be cosmetic on Windows — the message is displayed, but events still don't actually reach the configured endpoint. Whatever code path the message implies should be triggered, it isn't delivering. Combined with the existing blocked-by-allowlist reports in #30112 and #30861, the practical effect is: an OTLP endpoint configured by either hostname or IP is silently filtered out (or the exporter never initializes) on the Cowork side, regardless of admin-UI configuration. Hostname/IP distinction does NOT change the failure mode on Windows.

Two possible bug locations consistent with these symptoms:

1. The Cowork OTel exporter never initializes on Windows even when admin-side config is valid (i.e. event emission doesn't fire at all — would explain zero packets leaving the Cowork sandbox).
2. The exporter initializes and emits, but the MITM egress proxy blocks regardless of allowlist state (matches behavior in #30861).

These are distinguishable with a packet capture from the host showing whether any TCP SYN packets to port 4318 leave the laptop during a Cowork session. Happy to provide this if it would help triage.

Other diagnostic data available on request

• Packet capture from host showing whether the Cowork VM emits any TCP SYN to port 4318 during a Cowork session
• Vector logs and internal-metrics confirming the collector is healthy and receiving from non-Cowork sources
• Anthropic admin console screenshots of the relevant panels

Happy to provide any of the above if it would help triage. Also happy to test a fix candidate against this environment.

Pulled the Cowork VM service logs from the host to narrow down which of the two bug locations from my previous comment is in play. Strong evidence for #1 (OTel exporter never initializes), not #2 (proxy blocks emitted traffic).

Where the logs live (in case useful for other Windows reporters)

• Event Viewer: Application log, CoworkVMService provider — shows VM start/stop events
• Service log: C:\ProgramData\Claude\Logs\cowork-service.log — host-side VM lifecycle (HCS calls, VM config, etc.)
• Per-user coworkd log: C:\ProgramData\Claude\Logs\coworkd\user-S-1-5-21-…log — the per-session Cowork daemon activity

What the coworkd user log shows during a Cowork session

The Cowork VM starts and configures itself successfully:

• MITM proxy starts at /var/run/mitm-proxy.sock with ephemeral CA cert installed to system trust store
• TAP device configured (tap=tap0, ip=172.16.10.3/24, gw=172.16.10.1) and bridged to host over vsock port 1024
• Network status: CONNECTED; API reachability check against https://api.anthropic.com/ passes
• 69 Windows CA certificates loaded into the guest trust store
• Per-session srt-settings file written with domains=5 parentProxy=false (presumably package-manager domains + my custom-added domain)
• OAuth token added to the approved-tokens list by the proxy
• The claude binary gets spawned as the Cowork agent with a long args list (model, tools, etc.)

What the coworkd user log does NOT show

A grep -i 'otel\|otlp\|exporter\|telemetry' against the user log over a complete Cowork session (from VM start through agent process exit) returns zero matches. Specifically:

• No "starting OTel exporter" or equivalent initialization line
• No attempted POST to the configured OTLP endpoint
• No proxy blocked-by-allowlist line (which would be expected if the exporter were running but being denied)
• No connection error to the OTLP endpoint
• No mention of the OTLP endpoint hostname or IP anywhere in the log

The proxy is otherwise quite verbose (it logs OAuth token additions, MTU changes, certificate installation, mount setup, etc.). The complete silence on anything OTel-related is conspicuous.

Interpretation

This is consistent with the OTel exporter code path never executing on Windows — i.e., the admin-side config is accepted and persisted, but the in-VM agent that's supposed to emit OTel events either doesn't receive that config or doesn't act on it. It is not consistent with the exporter running and the egress proxy then dropping traffic (that would show up as proxy log entries).

What this narrows the bug to

If this analysis is right, the bug location is upstream of the egress proxy — somewhere in:

1. The admin → in-VM-agent config propagation path for Cowork OTel settings, OR
2. The OTel exporter initialization in the in-VM claude binary on Windows, OR
3. A platform-conditional check that disables OTel emission on the Windows Cowork VM

Happy to share the full log (redacted for paths) with engineering if it helps further narrow. Also happy to test whether setting OTEL_* env vars at any pre-VM-spawn entry point makes a difference, if there's one accessible to admins.

For a Windows-specific report that consolidates the evidence in my earlier comments above — including a loopback (127.0.0.1) test that rules out the MITM-egress-proxy hypothesis on Windows and narrows the bug to OTel exporter initialization not executing in the Windows Cowork VM — see #63171.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

We'd love to know if there was any movement on this