`claude update` hangs indefinitely on version-check when current == latest
Summary
claude update stalls at "Checking for updates to latest version..." indefinitely when the installed version equals the latest stable. Never times out, requires Ctrl+C.
Repro
$ claude --version
2.1.126 (Claude Code)
$ claude update
Current version: 2.1.126
Checking for updates to latest version...
^C # after several minutes, no progress
Diagnostic — confirms it's a hung HTTP request, not network down
While claude update is stalled, lsof on the process shows three ESTABLISHED TCP connections sitting open with no data flowing:
$ PID=$(pgrep -f 'claude update' | head -1)
$ lsof -p $PID 2>/dev/null | grep TCP
2.1.126 74526 aleks 9u IPv4 TCP 172.17.51.78:65504->17.46.190.35.bc.googleusercontent.com:https (ESTABLISHED)
2.1.126 74526 aleks 11u IPv4 TCP 172.17.51.78:65508->160.79.104.10:https (ESTABLISHED)
2.1.126 74526 aleks 14u IPv4 TCP 172.17.51.78:65515->160.79.104.10:https (ESTABLISHED)
160.79.104.10 is claude.ai, 17.46.190.35.bc.googleusercontent.com is downloads.claude.ai. So TCP+TLS completed successfully but the binary is waiting on an HTTP response that doesn't arrive.
The endpoints themselves work fine outside the binary
Manual curl against the same hosts returns immediately:
$ curl -fsSL --max-time 10 https://downloads.claude.ai/claude-code-releases/latest
2.1.126
$ curl -I --max-time 10 https://downloads.claude.ai/claude-code-releases/2.1.126/manifest.json
HTTP/2 200
content-type: application/json
content-length: ~600
So the binary is reaching a different endpoint OR sending a request the server doesn't respond to (e.g. some User-Agent / auth-header path that's currently broken on the server side).
What a correct updater should do
A version-check should:
- Fetch over HTTPS with a 5–10s timeout.
- Compare versions.
- Print "You're on the latest version" or "New version X available — run …".
- Exit cleanly.
This client has no apparent timeout on the version-check call — it sits on the open socket indefinitely. That's the actual bug. Whether the server-side issue causing the missing response is fixed or not, a CLI updater shouldn't hang forever waiting for it.
Environment
- macOS 26.3.1 (build 25D2128), arm64
- Install path:
/Users/aleks/.local/bin/claude→/Users/aleks/.local/share/claude/versions/2.1.126(native installer) claude --version:2.1.126 (Claude Code)- Network: standard residential ISP, no corp proxy/VPN;
curlto the relevant*.claude.aihosts succeeds in <1s
Workaround used
Ctrl+C and just keep running 2.1.126; nothing actually needed updating since current already equals latest. Filing this so the next person hitting the same edge case gets a real fix instead of the same workaround.
Suggested fix
Add a hard timeout on the version-check HTTP request (e.g. AbortController with a 10s deadline if it's fetch, or a signal.timeout() at request level), and on timeout exit gracefully with "Couldn't reach update server, try again later." instead of hanging.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗