[Bug] Transient network loss is recorded as a persistent install_failed; "Auto-update failed" banner never clears after reconnect (Windows native, already on latest)

Confirming on macOS (darwin-arm64) — and a data point that rules network out as the trigger

Seeing this exact sticky install_failed banner on macOS native, so it isn't Windows-specific. More importantly, in my case there is no network involvement at all — it reproduces on a healthy connection, which suggests the "transient network/check failure" framing is too narrow: there appears to be a code path that throws on the already-on-latest run itself.

Environment

• Claude Code 2.1.177 (native installer), darwin-arm64, macOS 26.5.1 (build 25F80 / Darwin 25.5.0)
• Channel latest; Currently running == Latest version == 2.1.177 (nothing to install)
• installMethod: native, autoUpdatesProtectedForNative: true. Independent of the autoUpdates flag — it failed identically while that flag was false (6-13, 6-14) and after flipping it to true (6-15).

Symptom — identical to this issue: ✗ Auto-update failed · Run /doctor, sticky across restarts.

It recurs ~once per day, deterministically, on a full connection. ~/.claude/.last-update-result.json was rewritten on three consecutive days, byte-identical except the timestamp:

{"path":"native","outcome":"failed","status":"install_failed","version_from":"2.1.177","version_to":null,"error_code":null}

(2026-06-13, -14, -15 — all while already on 2.1.177, the latest.)

What I ruled out (so it's not environment, and not network):

• The latest channel and …/2.1.177/manifest.json both fetch fine (HTTP 200); the published darwin-arm64 size/checksum match the installed binary exactly.
• Plenty of free disk; versions/, staging/, and the lock dir are all clean (staging empty, no stale locks).
• Manual claude update succeeds every time → Claude Code is up to date (2.1.177), and notably does not write .last-update-result.json.

Root-cause mechanism (from the 2.1.177 bundle). The native updater records its result like this:

// happy path
if (G.wasUpdated)  huH({ outcome:"success", status:"success", version_to:G.latestVersion })
else               /* tengu_native_auto_updater_up_to_date — writes NO result file */
// failure path
catch (G) {
  N(`Native auto-updater failed: ${G.message}`, { level:"error" })
  huH({ outcome:"failed", status:"install_failed", version_from:<cur>, version_to:null, error_code:null })
}

Two things fall out of this and together explain the "never clears" behavior:

1. The clean already-up-to-date path writes no result file at all, so it can never overwrite a prior install_failed. Any earlier failure is sticky until a real update lands or the file is removed by hand. (This is the persistence half of the bug.)
2. In my case the updater is hitting the catch on an already-latest run — version_to: null and error_code: null (so it threw before resolving a target, and it's none of the categorized cases: exe-lock / restore-failed / env-setup). The thrown message only goes to N(…, {level:"error"}) and isn't persisted anywhere I could find, so I can't capture the exact exception from outside the process — but with network/manifest/disk/locks all healthy and manual update working, the throw looks intrinsic to the background already-latest path rather than a transient external failure.

Net: the two fixes requested in this issue would cover the macOS case too — (a) never record/show install_failed when current == latest (nothing to install), and (b) reset the persisted state on the next successful or up-to-date check, not only on a real update. It would also help to surface that caught Native auto-updater failed: … message in a durable debug log so the underlying throw can actually be diagnosed.

Happy to provide /doctor output or anything else useful.

Confirming the same misclassification + never-reset behavior on Linux (no network loss involved) — this is not Windows- or connectivity-specific.

Environment

• Debian, kernel 6.12.94+deb13-amd64
• Native installer (~/.local/share/claude/versions/, symlink from ~/.local/bin/claude), channel latest
• Note: this box routinely runs several concurrent Claude Code sessions, so background update checks fire more often than a typical single-session setup

Symptom
/doctor has shown Last update attempt: failed (install_failed) persistently across many versions (first noticed around 2.1.191), while updates actually land successfully every day:

~/.local/share/claude/versions/
  2.1.196  (installed 2026-06-30)
  2.1.197  (installed 2026-07-01)
  2.1.198  (installed 2026-07-02 05:00, symlink flipped 05:04)

Staging dir clean, no locks, symlink correct — install is healthy and on latest.

The stale record
~/.claude/.last-update-result.json at the time /doctor reported the failure:

{"timestamp":"2026-07-02T08:17:05.522Z","path":"native","outcome":"failed","status":"install_failed","version_from":"2.1.198","version_to":null,"error_code":null}

version_from equals the installed latest and version_to is null — i.e. a background check that resolved no target version (already up to date) was recorded as install_failed. No connectivity outage occurred here, so the trigger differs from the OP's repro, but the failure mode is the same: a check-phase no-op/transient is persisted as an install failure and never reconciled.

Manual path doesn't clear it
claude update → Claude Code is up to date (2.1.198), exits clean — and does not rewrite .last-update-result.json, so the stale failed record survives and /doctor keeps displaying it indefinitely.

Suggests the fix shape in the OP holds generally: treat version_from == latest && version_to == null as success/no-op, and reset the persisted state on any successful check (including the manual up-to-date path).

Still reproducing on 2.1.220 — Windows 10 Pro 10.0.19045 (win32-x64), native install, channel latest.

Almost two months and many releases after the original report, the signature is unchanged. Current content of ~/.claude/.last-update-result.json:

{"timestamp":"2026-07-30T18:12:39.840Z","path":"native","outcome":"failed","status":"install_failed","version_from":"2.1.220","version_to":null,"error_code":null}

version_to: null confirms no install was ever attempted: the check failed (network dropped while the session was running) and the outcome was recorded as install_failed. 2.1.220 is already the current version, so there was nothing to install in the first place.

Once that record is written it is never reset — the banner survives reconnection, restarts and subsequent successful checks. Neither claude doctor nor claude update clears it; the only way out is deleting ~/.claude/.last-update-result.json by hand.

Newer reports describing the same behaviour: #81898 (false banner on 2.1.220 while already up to date), #82408 (claude update does not clear the stale record, and claude doctor never reads that file), #70608 (failed state never self-heals) — in addition to #62130 / #64554 / #64292 already linked in the description.

The fix asked for in the original report still stands: do not persist a failed check as install_failed, and reset the record on the next successful check.