claude-code - 💡(How to fix) Fix setup-token: parallel `claude -p` spawns sharing CLAUDE_CODE_OAUTH_TOKEN see ~5-10s server-side serialization tax (different tokens unaffected) [1 participants]

Summary

When two or more claude -p ... spawns run in parallel and share a single CLAUDE_CODE_OAUTH_TOKEN (issued by claude setup-token), one runs at normal latency (~6s) and the other(s) experience a consistent ~10-16s tax. With distinct tokens (different setup-token-issued tokens for different accounts), parallel runs are clean (~8s each).

The serialization is server-side, keyed on Bearer-token identity. Local syscalls are identical between the fast and slow paths; both processes connect to api.anthropic.com simultaneously; the server delays response on one of them. Likely the same family as #54443 / #27933 / #25609 but with setup-token the failure mode is slow rather than failed (no refresh dance to race).

Reproduction (10/10 trials show the pattern)

CLI v2.1.123 on Linux x86_64.

# Mint two distinct setup-tokens (or use the same one twice).
# Stash as TOKEN_A and TOKEN_B.

# Same-token parallel:
mkdir /tmp/repro && cd /tmp/repro
for i in $(seq 1 10); do
  (time env CLAUDE_CODE_OAUTH_TOKEN="$TOKEN_A" claude -p "Reply: A" </dev/null > a$i.out 2>&1) 2>&1 | grep real &
  (time env CLAUDE_CODE_OAUTH_TOKEN="$TOKEN_A" claude -p "Reply: B" </dev/null > b$i.out 2>&1) 2>&1 | grep real &
  wait
  echo "trial $i done"
done

# Result: 9/10 trials, A=5.8-8.2s and B=9.1-15.6s (mean B-A delta ≈ 4s)

# Different-token parallel control:
for i in $(seq 1 10); do
  (time env CLAUDE_CODE_OAUTH_TOKEN="$TOKEN_A" claude -p "Reply: A" </dev/null >/dev/null 2>&1) 2>&1 | grep real &
  (time env CLAUDE_CODE_OAUTH_TOKEN="$TOKEN_B" claude -p "Reply: B" </dev/null >/dev/null 2>&1) 2>&1 | grep real &
  wait
done

# Result: clean ~8s each.

What the local side does

strace -f -e trace=openat,connect,flock,fcntl shows the env-var spawn and the ~/.claude/.credentials.json spawn make nearly identical syscalls. No local lock contention. No extra file IO on the env-var path. Both spawns connect to api.anthropic.com within milliseconds of each other. The variance is on the server side.

Operational impact

For headless / cron / CI use cases (the documented target of setup-token), parallel-spawn workloads sharing a single token take a measurable latency hit. Not a hang in v2.1.123 — just consistent slowness on N-1 of N parallel spawns.

Workaround for users with multiple subscription accounts: round-robin across distinct tokens (1 token per account). Workaround for single-account users: serialize spawns at the dispatch layer.

Environment

• CLI: 2.1.123
• OS: Linux x86_64
• ~/.claude/.credentials.json: present, fresh (CLI silently refreshes hourly)
• Token format: sk-ant-oat01- + 95-char tail per documented setup-token output
• No apiKeyHelper configured. No ANTHROPIC_API_KEY. No ANTHROPIC_AUTH_TOKEN.

Related

• #54443 (concurrent OAuth, 2026-04-28) — closest existing report
• #27933, #25609 (OAuth refresh races, closed) — same family, refresh-token variant
• #11639 (apiKeyHelper TTL cache) — adjacent