Stale "auto-update failed" status message is misleading and can't be cleared

This is what's been visible in my iTerm for most of the day, but as Claude stated in the PR comment above, the install is actually healthy:

<img width="327" height="56" alt="Image" src="https://github.com/user-attachments/assets/6d2875d4-19b4-44ac-934e-8917f7cf8544" />

Confirming both problems on a Windows 11 native install at the same version (2.1.220). Adding hard data since this thread doesn't have a Windows native case yet.

Environment

• Windows 11 Pro 10.0.26200
• Native install: %USERPROFILE%\.local\bin\claude.exe (265,720,480 bytes)
• claude --version → 2.1.220
• autoUpdatesChannel: "latest", and the latest channel manifest also returns 2.1.220 — already current, nothing to update to

The failure record

{"timestamp":"2026-07-30T01:00:58.711Z","path":"native","outcome":"failed","status":"install_failed","version_from":"2.1.220","version_to":null,"error_code":null}

Note that error_code is null in addition to version_to, so the record carries no actionable cause whatsoever — which is a large part of why claude doctor has nothing to act on.

Timing: this is a startup check firing ~20 s in

• claude.exe process start: 2026-07-30 10:00:38 KST (UTC+9) = 01:00:38Z
• failure record written: 01:00:58.711Z

So the failure lands 20.7 s after process launch, not during a long-running background cycle. That is consistent with a transient network / version-metadata resolution failure at startup rather than an install problem — matching @owenbrown's DNS analysis in #81898, despite the install_failed label.

Nothing was actually attempted on disk

• ~/.claude/downloads/ — empty, no partial artifacts
• ~/.local/share/claude/versions/ — contains only 2.1.217 and 2.1.220; no directory was created for any newer version
• 146 GB free on C:, no proxy configured (ProxyEnable = 0)

This supports the conclusion that it failed before the install step, i.e. status: "install_failed" is mislabeled.

Problem 2 reproduces exactly as described

> claude update
Current version: 2.1.220
Checking for updates to latest version...
Claude Code is up to date (2.1.220)

After that run, the .last-update-result.json timestamp was unchanged (still 01:00:58.711Z) and the banner persisted. The "already up to date" path is a no-op that never clears the stale failure record.

Workaround — removing the record and restarting clears the banner:

Remove-Item "$env:USERPROFILE\.claude\.last-update-result.json"

One aside: ~/.claude/telemetry/ is empty on this machine, so there is no local indication that this failure is reported anywhere other than that one file. If that holds generally, the already-on-latest failure case may be substantially under-observed on your side.

Same root cause as #65093 (filed 2026-06-03, labelled bug / has repro / regression / area:installation), which has a deterministic repro: on an install already at the latest version, drop the network mid-session → the failed check is recorded as install_failed with version_to: null, i.e. no install was ever attempted.

Your point 2 is exactly the never-self-heals half of that report, also covered by #70608: the record is never reset by a subsequent successful check, so the banner outlives reconnection and restarts, and only deleting ~/.claude/.last-update-result.json by hand clears it.

Point 1 lines up too — claude doctor never reads that file, so the remediation the banner points at cannot possibly clear the state it reports.

Still reproducing on 2.1.220 (Windows 10, native, channel latest). Cross-linking so the reports don't stay split across #65093 / #81898 / #70608 / this one.

Confirming both points on macOS (Apple Silicon), native install, v2.1.220, channel latest.

One data point I don't see elsewhere in this thread or in #70608 / #65093 — the stale record regenerates, so deleting it is not a one-time fix:

• 2026-07-30: deleted ~/.claude/.last-update-result.json, restarted, banner cleared.
• 2026-07-31 08:54 local: a fresh failure record was written by the background updater — while the machine was already on the latest release:

{"timestamp":"2026-07-31T00:54:21.442Z","path":"native","outcome":"failed",
 "status":"install_failed","version_from":"2.1.220","version_to":null,"error_code":null}

Re: point 2 (claude update doesn't clear a stale record) — confirmed, with a precise observation: after a successful

Current version: 2.1.220
Checking for updates to latest version...
Claude Code is up to date (2.1.220)   # rc=0

the file's mtime was unchanged (still 08:54:21). So the success path doesn't touch the file at all, rather than writing a record that happens to be ignored.

Note that status is install_failed even though version_to is null — no target version was ever resolved, so nothing was downloaded or installed. A failed check is being recorded as a failed install, which is the same root cause as #65093.

Everything else was verified healthy at the time of the failed record, so this is not a local environment problem:

• installed 2.1.220 == https://downloads.claude.ai/claude-code-releases/latest → 2.1.220
• release endpoint reachable, HTTP 200
• ~/.cache/claude/staging empty; no partial downloads or lock files
• ~/.local/share/claude/versions/ and ~/.local/bin writable, correct uid
• 82 GB free disk
• claude doctor reports no installation issues

Since the only two outcome values are success and failed, an "already on latest, nothing to do" check has no outcome it can record — so one transient failure is latched permanently and no amount of successful checking can clear it.