[Bug]: Claude Code provider update hangs and leaves a stale warning #8280

Activity

1. bozzhik

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Aug 26, 2026
2. akshaylingamaneni commented on Aug 27, 2026

   

   akshaylingamaneni

   on Aug 27, 2026

   More actions

   hey @bozzhik, can you verify this behaviour. if there is no homebrew installation. then it still shows brew upgrade command which is incorrect. isHomebrewCommandPath() treats every /usr/local/bin/* path as Homebrew. The RPC reaches the remote server, then fails with spawn brew ENOENT. In my usecase i was using a remote box which is linux and has not homebrew installtion.

   
3. bozzhik commented on Aug 27, 2026

   

   bozzhik

   on Aug 27, 2026

   Author

   More actions

   hey @bozzhik, can you verify this behaviour. if there is no homebrew installation. then it still shows brew upgrade command which is incorrect. isHomebrewCommandPath() treats every /usr/local/bin/* path as Homebrew. The RPC reaches the remote server, then fails with spawn brew ENOENT. In my usecase i was using a remote box which is linux and has not homebrew installtion.

   Thanks — I checked this against my setup.

   I cannot reproduce the no-Homebrew remote Linux case because my environment is macOS 15.7.3 arm64 with T3 Code (Alpha) 0.0.34. Claude Code 2.1.231 is installed via Homebrew Cask, Claude resolves to /opt/homebrew/bin/claude, and brew is available at /opt/homebrew/bin/brew. Running brew upgrade claude-code reports that the latest version is already installed.

   I also checked the current main implementation: isHomebrewCommandPath() classifies every path starting with /usr/local/bin/ as Homebrew. In a no-Homebrew environment this results in a brew upgrade command, and spawning brew fails with ENOENT. I was able to reproduce that classification and failure locally by simulating a PATH without Homebrew, but I have not tested it on an actual remote Linux box.

   So this looks like a valid related issue, but it is separate from my original report: my report is about the in-app server.updateProvider request hanging for more than 120 seconds on macOS even though Homebrew is installed and the Claude version is already current.
4. akshaylingamaneni commented on Aug 28, 2026

   

   akshaylingamaneni

   on Aug 28, 2026

   More actions

   Thanks for looking into it. I can open an issue and link a pr.
5. IchordeDionysos commented on Aug 31, 2026

   

   IchordeDionysos

   on Aug 31, 2026

   More actions

   I believe the issue is that the version of Claude Code on Homebrew is always slightly behind and thus the warning is always present ...
6. janpilu commented on Sep 1, 2026

   

   janpilu

   on Sep 1, 2026

   More actions

   Confirming the hypothesis in the comment above, with evidence from a t3 triage session on an affected machine.

   The Homebrew cask genuinely lags npm, and T3 compares against npm regardless of install channel. Measured today:

   $ curl -s https://registry.npmjs.org/@anthropic-ai%2Fclaude-code/latest | jq -r .version
   2.1.257
   $ curl -s https://formulae.brew.sh/api/cask/claude-code.json | jq -r .version
   2.1.236
   $ claude --version
   2.1.236 (Claude Code)
   $ brew upgrade --dry-run claude-code
   Warning: Not upgrading claude-code, the latest version is already installed
   

   resolveLatestProviderVersion (apps/server/src/provider/providerMaintenance.ts:456) always fetches from registry.npmjs.org, even when resolvePackageManagedProviderMaintenance has already classified the install as Homebrew-managed and built brew upgrade claude-code as the update command. The advisory is therefore unsatisfiable by its own suggested command until the cask is bumped. Same root cause as #7730.

   Second, separable defect: the failure is invisible in the provider settings card. The server does reach a correct terminal state — providerMaintenanceRunner.ts:356-377 re-verifies, finds the provider still behind_latest, and sets unchanged with the message "Update command completed, but T3 Code still detects an outdated provider version." But ProviderInstanceCard.tsx never reads updateState; it only swaps the button label between "Updating" and "Update now" (lines 753-757). The message is discarded.

   Trace from two consecutive clicks:

   ProviderMaintenanceRunner.runProviderUpdate  durationMs: 437.79  exit: Success
   ProviderMaintenanceRunner.runProviderUpdate  durationMs: 411.91  exit: Success
   

   The user sees a sub-second spinner, no explanation, and an infinitely re-clickable button. Note this differs from the original report's >120s hang — here the command returns almost immediately; the shared symptom is the silent no-op. ProviderUpdateEnvironmentRows.tsx does handle unchanged (renders a "Retry" button with a warning tone), so the gap is specific to the settings card.

   Repro: install Claude Code via brew install --cask claude-code; wait for any npm release to land ahead of the cask bump (happens every release); open Settings → Providers → Claude → "Update now". Spinner, then nothing, repeatable indefinitely.

   Environment: T3 Code 0.0.37, macOS darwin arm64 25.5.0, Node v26.5.0, local server via npx t3. Claude Code 2.1.236 via Homebrew cask, claude resolving through /opt/homebrew/bin/claude → /opt/homebrew/Caskroom/claude-code/2.1.236/claude. Not fixed on main — the last commit touching providerMaintenance.ts is dc0ff8f (2026-08-15), and 0.0.38-nightly.20260901.1248 still has the npm-only lookup.

   Workaround: disable the "Check provider versions" toggle in Settings, or wait for the cask bump.

   Investigated with Claude Fable 5 in Claude Code, alongside t3 triage machine facts.
7. juliusmarminge

   closed this as completedon Sep 5, 2026
8. juliusmarminge commented on Sep 5, 2026

   

   juliusmarminge

   on Sep 5, 2026

   Member

   More actions

   Closing as fixed by #9325. Same root cause as #7730. Reopen if still reproduces after this lands.