claude-code - 💡(How to fix) Fix [Windows] Cowork OpenTelemetry exporter does not initialize - zero events emitted to any destination, including loopback

Summary

On Windows 11 Enterprise with Claude Desktop 1.9255.2, configuring Cowork OpenTelemetry monitoring in the admin console (per the official docs) results in zero OTLP events being emitted by Cowork sessions, regardless of destination form (hostname, IP, loopback), regardless of network egress allowlist contents, and regardless of any other admin-side setting. Host-side log analysis indicates the OTel exporter code path is not being executed at all inside the Cowork VM on Windows.

This is filed as a separate issue from #39471 (currently platform:macos-labeled) because:

1. The bug reproduces on Windows independently of the macOS thread, with distinct evidence.
2. A community workaround that reportedly works on macOS (pointing OTLP at 127.0.0.1 and running a relay on the host) does not work on Windows — see the loopback test below.
3. The on-host log evidence narrows the Windows failure to exporter-initialization, not egress filtering, which appears to be a different code path than the macOS reports.

I have also posted three comments on #39471 with progressively narrower evidence; this issue consolidates that into a single Windows-focused report for triage.

Environment

• Claude Desktop: 1.9255.2 (1dc8f7) — well past the 1.1.4173 minimum stated in the docs
• Platform: Windows 11 Enterprise
• Plan: Enterprise
• Cowork status: Enabled for org in admin console
• Allow network egress (Cowork section): Toggled ON
• Domain allowlist mode: "Package managers only" + a custom additional allowed domain

Baseline: the same machine emits OTel cleanly via Claude Code CLI

To rule out environmental issues, the same Windows laptop was first verified end-to-end with the Claude Code CLI OTel exporter against the same collector:

• Self-hosted Vector 0.43.0 OTLP relay at http://<internal-host>:4318 (and at http://<internal-ip>:4318).
• Relay forwards to a downstream SIEM via webhook.
• Claude Code CLI events (claude_code.user_prompt, claude_code.api_request, claude_code.tool_result, etc.) flow through Vector to the SIEM with full attribution: user.email, prompt.id, cost_usd, model, tokens, and resources flattened correctly.
• Vector's internal counters confirm 154+ events received and forwarded with zero drops over the test period.

So the network path, the collector, and OTel reception are all known-good from this laptop for non-Cowork OTel traffic. Whatever is preventing Cowork events from arriving is Cowork-specific, not environmental.

Reproduction

1. Configure 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>
2. Save the admin form.
3. Fully quit Claude Desktop (tray icon → Quit, not just close window).
4. Reopen Claude Desktop and start a fresh Cowork session that exercises tools and file access.
5. Wait several minutes.

Result: Zero events with service.name=cowork arrive at the collector. The same collector continues to receive Claude Code CLI events from the same laptop without issue during the same time window.

All destinations tested on Windows — all return zero events

The last row is the decisive datapoint. A community comment on #39471 reported that on macOS, the Cowork MITM egress proxy blocks external destinations but allows traffic to 127.0.0.1 (the in-VM loopback reaches the host loopback through the macOS bridging path), making "Cowork → localhost relay → external collector" a viable workaround.

To test this on Windows, Vector 0.43.0 was installed locally on the laptop, configured with an OTLP/HTTP source bound to 127.0.0.1:4318 (and :4317 gRPC) and a sink to the same downstream collector. The local Vector ran cleanly: healthcheck passed, listener bound, OTLP/HTTP endpoint verified responsive by a direct loopback probe (curl -X POST http://127.0.0.1:4318/v1/logs returns HTTP 200). Cowork's admin form was then updated to http://localhost:4318, Claude Desktop fully quit and reopened, and a fresh Cowork session was run that exercised tools.

Result: Local Vector's cowork_otlp source receivedEventsTotal counter remained at 0.0 for the entire Cowork session. Not a single OTLP request, connection attempt, or HTTP probe reached the loopback listener — including TCP SYN packets that would precede any blocked-by-proxy condition.

Implication: the "MITM proxy blocks external destinations" hypothesis is ruled out on Windows. If the bug were egress-filtering, loopback would have bypassed it. Since loopback also sees nothing, the Cowork OTel exporter is not emitting at all from the Windows Cowork VM, regardless of destination.

Host-side log analysis

Cowork's host-side VM service logs corroborate this. Logs inspected:

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

What the per-session coworkd log shows during a real Cowork session

The Cowork VM starts cleanly:

• HCS-backed VM starts; TAP device + vsock bridge configured (tap=tap0, ip=172.16.10.3/24, gw=172.16.10.1)
• MITM proxy starts at /var/run/mitm-proxy.sock with ephemeral CA cert installed in guest trust store
• Network status: CONNECTED; reachability check against api.anthropic.com passes
• 69 Windows CA certificates loaded into guest trust store
• Per-session srt-settings file written with domains=5 parentProxy=false
• OAuth token added to approved-tokens list by the proxy
• The claude agent binary spawns with a long args list (model, allowed tools, etc.)
• Plan9 file shares mounted for user session paths

What the log does NOT show — and this is the diagnostic signal

A grep -i 'otel\|otlp\|exporter\|telemetry' against the user log over a complete Cowork session lifetime (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 by the proxy)
• 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 configuration, certificate installation, mount setup, srt-settings writes, etc. The complete absence of any OTel-related log entries during a full Cowork session is conspicuous.

Suspected bug location

Combining the loopback test (rules out egress-filtering) and the coworkd log analysis (no exporter activity in the verbose proxy log), the bug location on Windows narrows to the OTel exporter code path not being executed inside the Windows Cowork VM. Candidate root causes:

1. Admin → in-VM agent config propagation: the admin-side OTel settings are accepted by the form and persisted, but not delivered to the in-VM claude agent on Windows.
2. OTel exporter initialization in the in-VM binary: the config is delivered but a Windows-specific code path (or its absence) prevents the exporter from registering / starting.
3. Platform-conditional gate: an if platform == "linux" || "darwin"-style check disables OTel emission on the Windows Cowork VM.

A single line of debug logging from the in-VM agent at exporter-init time would let anyone reproducing this distinguish (1) from (2)/(3) immediately.

Notable side observation: cosmetic admin-UI behavior

When the OTLP endpoint field is set to an IP form, the admin UI displays an inline message:

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

No equivalent message appears for hostname-form endpoints. The visible domain allowlist panel never reflects an auto-added entry for either form. Because IP-form testing also produces zero events, the auto-add message appears to be cosmetic on Windows — whatever allowlist-mutation code path it implies either isn't executed or doesn't affect the actual egress filtering. (This may or may not be related to the main bug.)

Related issues

• #39471 — Cowork OTLP monitoring not emitting events despite correct configuration (currently platform:macos-labeled; three of my comments on that thread cover the Windows reproduction)
• #30112 — Cowork network egress allowlist not working
• #30861 — Cowork MITM egress proxy blocks non-API domains regardless of allowlist (closed invalid, but the underlying behavior appears reproducible per #39471 thread)

Available diagnostic data on request

• Full coworkd per-session log (redacted for paths) covering a complete Cowork session
• Vector internal-metrics screenshots showing the loopback listener at receivedEventsTotal=0.0
• Vector logs from the APP-host relay showing Claude Code CLI traffic landing cleanly in the same time window (baseline)
• Admin console screenshots of the Cowork Monitoring and Allow-Network-Egress panels
• Host-side packet capture from a Cowork session showing whether any TCP traffic to port 4317/4318 leaves the laptop (negative result anticipated based on the above evidence)

Happy to test diagnostic builds, debug-logging-enabled builds, or any other instrumentation the team would find useful.

What would unblock us

This is blocking firmwide AI audit / compliance deployment at an Enterprise customer where Cowork is the primary Claude surface. We have everything on our side built and verified. The next useful step on our end is whatever Anthropic Engineering needs to triage — a debug build, a config flag to enable verbose exporter logging, instructions to dump the in-VM agent config, or just an ack that this is being looked at.