[BUG] 60-second latency on ALL `--print` mode requests - OAuth/Max subscription (v2.1.19, macOS, M4)

Preflight Checklist

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

What's Wrong?

NOTE: While I have searched existing issues and found potentially related, the details are considerably different. Potentially related: #17330, #16429

Every claude --print request takes exactly 60-63 seconds regardless of prompt complexity. This started suddenly on 2026-01-23 after working normally earlier the same day.

Even the most trivial prompt exhibits this delay:

$ time echo "Say 1" | claude --print 2>&1
1
claude --print 2>&1  1.47s user 0.76s system 3% cpu 1:02.89 total

Key observation: The ~60 second timing is suspiciously consistent, suggesting a timeout/retry mechanism is being hit before the request succeeds.

Timing Evidence (5 consecutive tests)

| Test | Prompt | Response Time |
|------|--------|---------------|
| 1 | echo "Say 1" \| claude --print | 63.32s |
| 2 | echo "Say 1" \| claude --print | 64.07s |
| 3 | echo "Say 1" \| claude --print | 62.89s |
| 4 | echo "Say 1" \| claude --print --model haiku | 64.07s |
| 5 | Complex prompt with file read | 63.00s |

All requests take 60-65 seconds. Model choice (Opus, Sonnet, Haiku) does not affect timing.

Environment

| Component | Value |
|-----------|-------|
| Claude Code | 2.1.19 |
| OS | macOS 26.3 (Build 25D5101c) |
| Hardware | Apple M4 Max, 128GB RAM |
| Node.js | v24.13.0 |
| Auth | OAuth (Max $200/month subscription) |
| Network latency | 37-46ms to api.anthropic.com |

Network Verification

$ ping -c 3 api.anthropic.com
round-trip min/avg/max/stddev = 37.015/40.262/46.223/4.220 ms

Network is not the issue. 40ms latency cannot explain 60-second delays.

---

Detailed Debug Analysis

To isolate whether the issue was in reading CLI output vs the CLI itself, I instrumented a wrapper script with 0.5-second polling that checks:

• IO.select readiness (is there output to read?)
• wait_thr.alive? (is the CLI process still running?)

Full Debug Output (126 iterations)

[DEBUG iter=1] IO.select wait_time=0.5s alive=true
[DEBUG iter=1] IO.select returned ready=false
[DEBUG iter=2] IO.select wait_time=0.5s alive=true
[DEBUG iter=2] IO.select returned ready=false
[DEBUG iter=3] IO.select wait_time=0.5s alive=true
[DEBUG iter=3] IO.select returned ready=false
...
[DEBUG iter=124] IO.select wait_time=0.5s alive=true
[DEBUG iter=124] IO.select returned ready=false
[DEBUG iter=125] IO.select wait_time=0.5s alive=true
[DEBUG iter=125] IO.select returned ready=false
[DEBUG iter=126] IO.select wait_time=0.5s alive=true
[DEBUG iter=126] IO.select returned ready=true
[DEBUG iter=126] drained 181 bytes
[DEBUG iter=127] IO.select wait_time=0.5s alive=true
[DEBUG iter=127] IO.select returned ready=false
[DEBUG iter=128] IO.select wait_time=0.5s alive=true
[DEBUG iter=128] IO.select returned ready=true
[DEBUG iter=128] EOF after 0 bytes

Analysis

| Metric | Value | Interpretation |
|--------|-------|----------------|
| Iterations until first output | 126 | 126 × 0.5s = 63 seconds |
| Process alive during wait | Always true | CLI is running, not crashed |
| Output ready during wait | Always false | CLI produces zero output for 63s |
| CPU usage during wait | 3% | CLI is I/O bound, waiting on something |
| Bytes received | 181 | Tiny response for "Say 1" prompt |

Conclusion from Debug Data

┌─────────────────────────────────────────────────────────────────┐
│  The Claude CLI process runs for 63 seconds producing ZERO      │
│  output, then suddenly emits the response and exits.            │
│                                                                 │
│  This is NOT:                                                   │
│  - A pipe/buffering issue (process alive, just not writing)     │
│  - A network issue (40ms ping, 63s delay)                       │
│  - A model issue (same timing for Opus, Sonnet, Haiku)          │
│  - A prompt complexity issue (same timing for "Say 1")          │
│                                                                 │
│  This IS:                                                       │
│  - Something inside the CLI waiting ~60s before making the      │
│    API call, OR                                                 │
│  - The API itself queueing/delaying OAuth/Max requests ~60s     │
└─────────────────────────────────────────────────────────────────┘

The 60-Second Signature

The consistent ~60s timing across ALL tests strongly suggests hitting a timeout threshold somewhere:

Possible causes:
1. OAuth token refresh hitting 60s timeout before fallback
2. API queue timeout for Max subscription tier
3. Connection pooling/retry with 60s initial timeout
4. Rate limiting queue with 60s delay

Timeline

• Earlier on 2026-01-23: Working normally (responses in 1-3 seconds)
• ~2026-01-23 22:00 UTC onwards: Every request takes 60+ seconds
• 2026-01-24 04:00 UTC: Issue persists

Co-occurring Issue

When using --allowedTools Read, also hitting API error (separate bug, but may share root cause):

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
"message":"messages.1.content.1: `tool_use` ids must be unique"}}

This is tracked in #20508 but may be related to whatever is causing the 60s queue delay.

Possibly Related Issues

• #17330 - Same symptoms (60-96s latency on Max subscription) - 13 days open, no resolution
• #16429 - Severe delay in WSL2, fixed by downgrading to 2.0.72
• #20508 - tool_use ids must be unique error (separate but co-occurring)

Impact

• --print mode is completely unusable for automation/scripting
• All downstream tools using Claude CLI timeout or appear broken
• Affects all models: Opus, Sonnet, Haiku
• Sudden regression - was working same day

Request

Please investigate:

1. What is causing the consistent ~60s delay before first byte?
2. Is there a timeout/retry/queue mechanism being hit?
3. Why does this specifically affect OAuth/Max subscription users?
4. Can this be prioritized given #17330 has been open 13 days?

What Should Happen?

A 1-token response to "Say 1" should complete in 1-3 seconds, not 60+ seconds.

Error Messages/Logs

Steps to Reproduce

1. Have Max subscription with OAuth authentication
2. Run: time echo "Say 1" | claude --print
3. Observe 60+ second response time for trivial query
4. Repeat - timing is consistent

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.17

Claude Code Version

2.1.19

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Keywords for searchability

latency, delay, slow, timeout, 60 seconds, 63 seconds, one minute, --print, print mode, OAuth, Max subscription, stdin, pipe, CLI, headless, automation, scripting, M4, M4 Max, macOS, macOS 26, API queue, throttling, wait, hang, blocked, no output, first byte, TTFB, time to first byte, response time, regression, 2.1.19, polling, IO.select, subprocess, popen