`claude update` hangs indefinitely on version-check when current == latest

Resolved 💬 3 comments Opened May 3, 2026 by aniebyl Closed May 7, 2026

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:

  1. Fetch over HTTPS with a 5–10s timeout.
  2. Compare versions.
  3. Print "You're on the latest version" or "New version X available — run …".
  4. 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; curl to the relevant *.claude.ai hosts 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗