claude-code - 💡(How to fix) Fix [BUG] otelHeadersHelper blocks TUI when script is slow to return [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48138Fetched 2026-04-15 06:32:06
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Error Message

Error Messages/Logs

No error messages — the TUI simply becomes unresponsive for the duration of the helper script execution.

Fix Action

Workaround

We implemented a background-refresh pattern in the helper script: the script caches the JWT to disk, always returns immediately from the cache (or {} on first run), and refreshes the token in a detached background process. This ensures otelHeadersHelper never blocks regardless of endpoint latency.

Code Example

# Ran: while true; do ps -eo pid,ppid,command | grep '[c]url' >> /tmp/curl_watch.log; sleep 0.5; done
# Result: curl hitting the /token endpoint with 10s timeout, same PID caught repeatedly over multiple seconds

---

cat > /tmp/slow-otel-helper.sh << 'EOF'
   #!/bin/bash
   sleep 8
   echo '{"Authorization": "Bearer test"}'
   EOF
   chmod +x /tmp/slow-otel-helper.sh

---

{
     "otelHeadersHelper": "/tmp/slow-otel-helper.sh",
     "env": {
       "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
       "OTEL_METRICS_EXPORTER": "otlp",
       "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
       "OTEL_EXPORTER_OTLP_ENDPOINT": "https://localhost:4318",
       "OTEL_METRIC_EXPORT_INTERVAL": "60000"
     }
   }
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

When otelHeadersHelper is configured and the helper script takes more than a few hundred milliseconds to return (e.g., due to a slow or unreachable token endpoint), the entire Claude Code TUI freezes — no input, no rendering — until the script completes or times out.

During the freeze, the terminal tab title changes to show the command being run (e.g., "curl"), confirming it executes synchronously in the foreground of the main process.

The otelHeadersHelper is invoked by the OTEL SDK's headers() function on every metric/log/trace export. With OTEL_METRIC_EXPORT_INTERVAL=60000 (60s) and only metrics enabled, this causes a 5-10 second freeze every 60 seconds. With logs and traces also enabled, the frequency increases significantly.

This affected multiple users across our organization (~thousands of engineers) after deploying otelHeadersHelper org-wide via managed settings.

What Should Happen?

otelHeadersHelper should run asynchronously so that a slow or failing helper does not block user interaction. If the helper is slow or fails, telemetry export should degrade gracefully (skip the export or use stale/cached headers) rather than freezing the UI.

Error Messages/Logs

No error messages — the TUI simply becomes unresponsive for the duration of the helper script execution.

Diagnostic output from monitoring curl processes during freezes:

# Ran: while true; do ps -eo pid,ppid,command | grep '[c]url' >> /tmp/curl_watch.log; sleep 0.5; done
# Result: curl hitting the /token endpoint with 10s timeout, same PID caught repeatedly over multiple seconds

Steps to Reproduce

  1. Create a slow helper script:

    cat > /tmp/slow-otel-helper.sh << 'EOF'
    #!/bin/bash
    sleep 8
    echo '{"Authorization": "Bearer test"}'
    EOF
    chmod +x /tmp/slow-otel-helper.sh
  2. Configure Claude Code settings (in settings.local.json or via managed settings):

    {
      "otelHeadersHelper": "/tmp/slow-otel-helper.sh",
      "env": {
        "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
        "OTEL_METRICS_EXPORTER": "otlp",
        "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
        "OTEL_EXPORTER_OTLP_ENDPOINT": "https://localhost:4318",
        "OTEL_METRIC_EXPORT_INTERVAL": "60000"
      }
    }
  3. Launch claude in a terminal

  4. Observe periodic TUI freezes (~8 seconds each) coinciding with the helper script execution. The terminal tab title changes to "sleep" during the freeze.

Workaround

We implemented a background-refresh pattern in the helper script: the script caches the JWT to disk, always returns immediately from the cache (or {} on first run), and refreshes the token in a detached background process. This ensures otelHeadersHelper never blocks regardless of endpoint latency.

Claude Model

Not applicable

Is this a regression?

I don't know

Claude Code Version

2.1.108

Platform

macOS

Operating System

macOS 15

Terminal/Shell

Terminal.app, iTerm2, VS Code integrated terminal, GoLand terminal

extent analysis

TL;DR

Run the otelHeadersHelper script asynchronously to prevent it from blocking the Claude Code TUI.

Guidance

  • The otelHeadersHelper script is currently running synchronously, causing the TUI to freeze when the script takes too long to return.
  • To fix this, the script should be run asynchronously, allowing the TUI to remain responsive even if the script is slow or fails.
  • Consider implementing a caching mechanism, like the background-refresh pattern, to ensure the script never blocks regardless of endpoint latency.
  • Verify the fix by checking if the TUI remains responsive during script execution and if the terminal tab title no longer changes to the command being run.

Example

# Run the script asynchronously using &
/tmp/slow-otel-helper.sh &

However, this approach may not be directly applicable as it depends on how the otelHeadersHelper is invoked by the OTEL SDK's headers() function.

Notes

The provided workaround, which implements a background-refresh pattern in the helper script, seems to be an effective solution. However, the root cause of the issue lies in the synchronous execution of the otelHeadersHelper script.

Recommendation

Apply the workaround by implementing a background-refresh pattern in the helper script, as it ensures the otelHeadersHelper never blocks regardless of endpoint latency.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING