›_ Claude Code Issues
Claude Code Issues / #49563

[BUG] Claude Code hangs indefinitely on first message — startup quota_check API request never completes

Status Fixed / completed
Reported on v2.1.112
Maintainer reply None cached
Activity 3 comments · opened Apr 16, 2026 · closed Apr 17, 2026

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?

Summary

Claude Code hangs indefinitely on the first message of any session. The UI shows a "thinking" spinner (Flambéing / Improvising / Cultivating / etc.) but no API request is made for the user's message. Debug logs show a startup /v1/messages request with source=quota_check that never gets a response logged, suggesting the app is wedged waiting on an uncompleted quota check.

Environment

  • Claude Code version: 2.1.112 (native installer, ~/.local/bin/claude)
  • macOS
  • Reproduces in both Ghostty and Terminal.app
  • Opus 4.7 with xhigh effort AND Sonnet with low effort both hang
  • Subscription: Claude Max

Steps to Reproduce

  1. Open terminal, cd to any directory (including empty ones like /tmp/claude-test)
  2. Run claude --debug
  3. Type "hello" and press Enter
  4. Session hangs indefinitely with thinking spinner; no response ever returned

What I've Ruled Out

Spent ~1 hour systematically eliminating local causes:

  • ✅ Disabled remoteControlAtStartup in ~/.claude.json
  • ✅ Removed all MCP servers (Gmail, Google Calendar, Notion disconnected from web UI)
  • ✅ Moved ~/.claude/plugins aside — still hangs
  • ✅ Tested in empty directory with no project CLAUDE.md
  • ✅ Tried both Opus 4.7 (xhigh) and Sonnet (low effort) — both hang
  • ✅ Tested in Terminal.app (not just Ghostty) — same behavior
  • ✅ curl to https://api.anthropic.com/v1/messages returns 401 in 25ms (network healthy)
  • ✅ claude auth logout + claude auth login — still hangs
  • ✅ Piped input via echo "hello" | claude --print — also hangs (not a keyboard/input issue)
  • ✅ Full clean reinstall: rm -rf ~/.local/bin/claude ~/.local/share/claude + curl -fsSL https://claude.ai/install.sh | bash + fresh claude auth login — still hangs

Key Debug Log Evidence

The startup quota check fires but no response is ever logged:
[DEBUG] [API REQUEST] /v1/messages x-client-request-id=ea0ff8e1-043d-43f6-8f69-4981a3530833 source=quota_check

After this line, the log shows only plugin init, LSP init, and periodic heartbeats/presence pulses. When "hello" is typed, NO new API request is logged — the app never submits the user's message. This suggests the quota check is blocking all subsequent requests.

Additional Notes

  • Before disabling remoteControlAtStartup, /remote-control is active appeared at every session start despite never explicitly enabling it
  • Three claude.ai MCP servers (Gmail, Google Calendar, Notion) were stuck in "Needs authentication" state but could not be removed via claude mcp remove — they are account-level and had to be disconnected via claude.ai web UI
  • Happy to attach full debug log from ~/.claude/debug/latest if needed

30bd82d3-68de-48fe-adfb-4bb514576791.txt

What Should Happen?

Claude should respond when i say 'hello' upon starting claude

Error Messages/Logs

Steps to Reproduce

i mean i think its on my instance somehow. but i go to terminal, type in claude, it opens, i enter 'hello' and it stalls forever

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.112 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/26224
  2. https://github.com/anthropics/claude-code/issues/41912
  3. https://github.com/anthropics/claude-code/issues/47336

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

josephyeewang · 6 months ago

Update: Resolved. Root cause identified.

The hang was caused by my SessionStart hook running a shell script that launched caffeinate with standard bash & backgrounding. Despite the &, Claude Code's hook runner appeared to wait on the backgrounded process, which never exited (caffeinate runs until killed). This wedged the session from startup — the UI showed a thinking spinner but no API request was ever submitted for user prompts, because the hook event itself never completed.

Isolation steps that pinpointed it:

  1. Moved ~/.claude config aside entirely → claude worked fine.
  2. Restored config piece-by-piece, testing after each addition.
  3. With only a single SessionStart hook active (caffeinate-start.sh using &), the hang reproduced reliably — 90s+ with no response to "hello".

Fix: Rewrote the script to use nohup ... & disown instead of just &:

#!/bin/bash
CLAUDE_PID=$PPID
nohup caffeinate -i -w "$CLAUDE_PID" >/dev/null 2>&1 &
disown
exit 0

After this change, startup is instant and sessions work normally.

Why I think this is worth a bug: The original script was correctly structured from a shell perspective — the backgrounded process should have detached and let the hook return. Other users writing SessionStart hooks that launch long-running background processes (caffeinate, tmux sessions, file watchers, etc.) will hit this exact issue with no clear error. Suggestions:

  1. Document the nohup + disown requirement for hooks that spawn long-running background processes.
  2. Add a hook timeout with a visible warning, so instead of hanging forever, users see "Hook X exceeded Ys, continuing without it."
  3. Run hooks in a detached process group by default so standard & backgrounding works as expected.

Unrelated but worth flagging from the same debugging session: remoteControlAtStartup: true was silently set in ~/.claude.json (I don't recall opting in), which caused every session to route through the remote-control bridge and contributed to initial confusion. Flipping it to false was required before the hook issue became visible.

Versions tested: 2.1.112 on macOS, both Ghostty and Terminal.app, Opus 4.7 (xhigh) and Sonnet — identical behavior.

github-actions[bot] · 5 months ago

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.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Rate limit errors, Authentication & login failures, MCP server connection issues, Crashes, hangs & freezes

Browse all Claude Code issue topics →