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

Preflight Checklist

• [x] I have searched existing issues and this specific combination hasn't been reported. Related: #62130 (same root cause: a transient check failure surfaced as an install failure on an already-current install), #64554 / #64292 (doctor/banner mismatch; #64292 also shows a network socket error), #61676 (Windows auto-updater regression from the 2.1.147 rework), #56189 (persistent un-suppressible banner).
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

What's Wrong?

If network connectivity drops while a Claude Code session is running (e.g. Disable the Ethernet adapter, Windows 10), the background auto-update check fails and the CLI shows:

✗ Auto-update failed · Run /doctor

The problem is not the failure itself but that the failed state is sticky:

1. The banner never clears after connectivity is restored — it keeps appearing on every startup.
2. Running /doctor does not clear it; /doctor reports Last update attempt: failed (install_failed).
3. Crucially, the install is a healthy native install already on the latest channel version (Currently running: native (2.1.161), Latest version: 2.1.161, channel latest). There was nothing to install — so a transient network/check failure is being (a) misclassified as install_failed and (b) persisted indefinitely without ever being reset on the next successful check or when the network comes back.

This is the same root cause as #62130 (transient check surfaced as install failure) but on Windows native, with a clean deterministic trigger and the added problem that the failed state is persisted and never reset.

What Should Happen?

• Distinguish a transient network / check failure from a real install failure (cf. #62130); a benign check failure should retry silently, not raise the red banner.
• When the installed version already equals the channel target (nothing to do), never show "Auto-update failed".
• The failed state must be reset on the next successful check / when connectivity returns, and /doctor should clear it (or at least offer an action to re-check), so the banner does not persist forever.

Error Messages/Logs

/doctor output (sanitized) while the banner was stuck, after the network had been restored:

Diagnostics
Currently running: native (2.1.161)
Commit: 6a550aea7c74
Platform: win32-x64
Config install method: native

Updates
Auto-updates: enabled
Auto-update channel: latest
Last update attempt: failed (install_failed) — 2026-06-03
Stable version: 2.1.150
Latest version: 2.1.161

Note: Currently running already equals Latest version (2.1.161), so no install was actually pending — yet the last attempt is recorded as install_failed.

Steps to Reproduce

1. Native install on Windows 10, auto-update channel latest, already on the latest published version.
2. Start a Claude Code session.
3. While the session is running, disable the network adapter (e.g. Disable the Ethernet NIC).
4. On the next background update cycle the banner ✗ Auto-update failed · Run /doctor appears.
5. Re-enable the network adapter → the banner stays.
6. Run /doctor → it reports Last update attempt: failed (install_failed) and does not clear the state; the banner keeps appearing on every startup.

Is this a regression?

Yes (perceived) — this did not happen on earlier versions; it started a few releases ago. Timing is consistent with the auto-updater rework noted in the 2.1.147 changelog and in #61676.

Last Working Version

Unknown (a few versions ago).

Claude Code Version

2.1.161 (Claude Code)

Platform

Claude Pro/Max (CLI)

Operating System

Windows 10 Pro 10.0.19045 (win32-x64)

Terminal/Shell

PowerShell

Additional Information

Reproducible on demand by toggling the NIC, which makes this a clean repro for the "transient check failure persisted as install_failed" class of bugs (#62130, #64554, #64292).