[BUG] Log/events exporter emits nothing while metrics work fine (Windows native v2.1.159)

Update: confirmed this is a regression with a known last-working version.

I found CloudWatch Logs Insights exports from my own account showing that
log/events were ingested correctly on earlier versions:

• 2026-05-07: events present with service.version 2.1.94 and 2.1.132
• 2026-05-11: events present with service.version 2.1.128

Event types received back then: claude_code.user_prompt, api_request
(with input_tokens / output_tokens / cost_usd), tool_result, tool_decision,
mcp_server_connection, hook_execution_start / hook_execution_complete.

Same machine, same CloudWatch Logs OTLP endpoint, same config family.
On 2.1.159 none of these events are emitted (not even to the console exporter),
while metrics still work.

Last working version: 2.1.132 → regression introduced somewhere between
2.1.132 and 2.1.159.

This is a real rollout blocker — enterprise auth/proxy friction is one of the top reasons AI coding tools fail internal adoption. Here's what I'd check immediately:

Diagnostic matrix (4 steps):

1. Certificate chain visibility — run NODE_EXTRA_CA_CERTS=/path/to/corp-ca.pem claude explicitly. Many proxy issues are CA trust issues, not auth issues. Also check: npm config get cafile and export NODE_TLS_REJECT_UNAUTHORIZED=0 (temporary diagnostic only).

1. Proxy protocol mismatch — some corporate proxies intercept CONNECT differently. Test HTTPS_PROXY=http://proxy:port vs HTTPS_PROXY=https://proxy:port and HTTP_PROXY variants. The tool may be using a different transport than you expect.

1. Auth header passthrough — if the issue is API calls through the proxy failing auth, verify whether the proxy strips/modifies Authorization headers. Capture with curl -v --proxy ... and compare to direct.

1. Policy bypass diagnostic — ENOEXEC / postinstall blocks are usually group policy or endpoint protection, not the tool itself. Try running the blocked script manually: bash -x $(which claude). If it works manually but not via npm/yarn lifecycle, the package manager's sandboxed execution is the culprit.

I write about this class of problem regularly — enterprise rollout friction kills more AI coding ROI than any bug. The pattern is almost always: (1) CA trust, (2) proxy protocol, (3) execution policy, in that order. Happy to share a hardening checklist if you want to go deeper.

Hi, thank you very much for taking the time to share these diagnostic
suggestions — I really appreciate the detailed write-up.

That said, I'd like to clarify that this issue is not network, proxy,
or authentication related. As described in the issue body, I have
already ruled out those layers through the following observations:

1. The console exporter (which involves no network at all) also

produces zero log records, while the metrics exporter works fine
within the very same process.

1. A manual OTLP POST to the same CloudWatch Logs endpoint from the

same machine returns HTTP 200, which confirms that the backend,
credentials, and network path are all healthy.

1. The behavior is identical on both the native installer build and

the npm package, so it is not install-method-specific either.

Given these results, the failure appears to be upstream of any
transport layer — specifically within the log/events pipeline itself.

If you happen to have observations specifically related to the OTel
logs exporter behavior on Windows v2.1.159, I would be very glad to
hear them. Thank you again for your input!

I've been operating multi-agent coding systems in production and this looks familiar. A few things that might help narrow it down:

1. Check if it reproduces with a minimal config — strip down to one agent, one tool, and see if the issue persists. This isolates whether it's a load problem or a logic problem.

1. Look at the timing pattern — does it always happen at the same point in the session (e.g., after N tool calls, or after a specific operation type)? Session JSONL logs are your friend here.

1. Consider adding explicit checkpoints before risky operations so recovery is faster even if the root cause takes time to fix.

Happy to dig deeper if you share more details about when it triggers.

Thanks again for following up — I appreciate your continued interest in this one.

To clarify, though, this isn't a multi-agent or tool-execution issue.
The problem reproduces even with a single, minimal claude -p prompt
and no tools involved, so there's no load or logic pattern to narrow
down on the agent side.

To re-summarize the key signals from the issue body:

• The console logs exporter (no network, no agents) emits zero

records, while the metrics exporter works fine in the same run.

• It reproduces consistently from the very first prompt — not after

N tool calls or any specific operation.

• Identical behavior on both the native installer and the npm package.

So the scope is narrower than it might look: it's specifically the
log/events pipeline that produces nothing, regardless of agent
workflow or session length.

If you've seen this specific behavior with the OTel logs exporter
itself, I'd genuinely love to compare notes. Thanks again!

Still reproduces on 2.1.160 (native installer): with OTEL_LOGS_EXPORTER=console, metrics print but zero log/events. No fix yet.

Possibly related:

• #64436 — same event types (user_prompt/api_request) dropped, background/agent sessions on macOS
• #50567 — Bun-compiled binary doesn't bundle OTLP exporter packages; dynamic require() fails

silently. Reported for metrics, but the same pattern would hit OTLPLogExporter.
Note: in my case it also reproduces on the npm build, so it may not be Bun-only.

Update — root cause found; correcting my original report

After deeper investigation, my original "log/events are never emitted" framing turned
out to be inaccurate. The log records ARE generated and POSTed. The real bug is that
OTEL_EXPORTER_OTLP_HEADERS is ignored on http/json log export in 2.1.159/2.1.160.
Here is the full picture.

1. Why "console shows nothing" was misleading

Binary inspection of the 2.1.160 native (Bun-compiled) executable:

LOGS:    OTLPLogExporter=15, BatchLogRecordProcessor=3, LoggerProvider=24,
         ConsoleLogRecordExporter = 0   ← absent
METRICS: ConsoleMetricExporter=14, PeriodicExportingMetricReader=23

ConsoleLogRecordExporter is not bundled, while ConsoleMetricExporter is. So
OTEL_LOGS_EXPORTER=console printing nothing does NOT prove events aren't generated —
the console log exporter simply isn't there. (cf. #50567 bundling gaps.)
OTLPLogExporter IS bundled, so OTLP export does run.

2. Logs ARE generated and sent — verified with a local OTLP receiver

Pointing the exporter at a local node http server, every claude -p run produces
multiple POST /v1/logs (e.g. bytes=13372, 2949, ...). So generation + OTLP send work.

3. Decisive control test: OTEL_EXPORTER_OTLP_HEADERS is ignored

Same local server, same 4 headers, only the sender differs.

Config for the Claude Code run:

OTEL_EXPORTER_OTLP_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=http://localhost:4318/v1/logs
OTEL_EXPORTER_OTLP_HEADERS="X-Test-A=alpha,X-Test-B=bravo,Authorization=Bearer DUMMYTOKEN123,X-Test-C=charlie"

Received by the server:

# Manual POST (Invoke-WebRequest) with the same 4 headers:
POST -> {"x-test-c":"charlie","x-test-b":"bravo","authorization":"len=20","x-test-a":"alpha"}
# Claude Code (claude -p "say hi"), 7 export batches:
POST -> {"authorization":"len=71"}   x7

• Manual POST delivers all 4 headers; authorization len=20 == the configured

"Bearer DUMMYTOKEN123".

• Claude Code drops X-Test-A/B/C entirely, and sends authorization **len=71 — NOT

the configured 20-char value**. The 71-char value is constant regardless of the
configured token (a 128-char CloudWatch API key also came out as 71).

→ Claude Code does not apply the user-configured headers. Custom headers are dropped,
and the Authorization value is overridden by an internal 71-char token.

4. Why this breaks CloudWatch Logs

CloudWatch Logs OTLP requires x-aws-log-group / x-aws-log-stream headers and a
specific bearer token. All three are dropped/overridden, so ingestion always fails —
while a manual PowerShell POST with the same headers returns HTTP 200, confirming the
backend and credentials are fine.

5. Regression range

Worked on 2.1.132 (CloudWatch ingest confirmed in my own logs from 2026-05-07).
Broken on 2.1.159 and 2.1.160, on both the native installer and the npm package.
So the regression landed somewhere between 2.1.132 and 2.1.159.

Questions for maintainers

1. Why is OTEL_EXPORTER_OTLP_HEADERS not applied to http/json log exports?
2. What is the internal 71-char Authorization being sent to the configured endpoint?

(Potential concern: an internal token is sent to whatever OTLP endpoint is set.)

Possibly related

• #64436 — same event types (user_prompt/api_request) not reaching the backend
• #50567 — Bun binary doesn't bundle some OTel exporter packages (here: ConsoleLogRecordExporter missing)

Self-resolved — this was NOT a Claude Code bug. Root cause: my org ships a
remote-settings.json (org-managed telemetry config) that overrides my local
settings.json env, redirecting OTLP to an internal endpoint with its own token.
That's why my CloudWatch headers/token were "ignored". Closing. Apologies for the noise.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.