Claude Desktop (macOS): opening Settings hangs the whole app after a model is retired

Summary

On Claude Desktop for macOS, opening Settings freezes the renderer indefinitely — the
window becomes unresponsive and has to be force-quit. While wedged, the app shows
"Remote credentials fetch failed" and the account profile reads as undefined. It looks
like corrupted settings or a broken login, but it is neither: OAuth and config files are fine.

This is the second occurrence in ~5 days on the same machine, both lining up with a model
lifecycle rollover (claude-opus-4-7 → claude-opus-4-8). It appears to recur on every model
retirement.

Environment

• App: Claude Desktop (macOS, Electron)
• OS: macOS (Darwin 25.5.0)
• Plan: Claude Max
• First seen 2026-05-29, recurred 2026-06-03

Steps to reproduce

1. Have a now-retired model id persisted as the selected/last-used model
   (e.g. claude-opus-4-7[1m] after the current default became claude-opus-4-8).
2. Open the app and open Settings (Cmd+,).

Expected

Settings opens and renders. If the persisted model id no longer exists, the app falls back to
the current default model.

Actual

• Settings never finishes loading; the renderer hangs and the app becomes unusable.
• "Remote credentials fetch failed" is shown; account profile is undefined.
• No native crash report is generated (Crashpad completed/ is empty) — confirming this is a
  renderer hang, not a process crash. The user force-quits.

Root cause (as diagnosed locally)

On Settings open, the app resolves the selected/available model via React Query, fetching
GET /api/organizations/<org>/model_configs/<model>. When <model> is a retired id
(claude-opus-4-7[1m]), the request returns 404 Not Found, and that query never
settles — so the Settings tree that depends on it hangs forever. The "Remote credentials
fetch failed" banner and undefined account profile are downstream of the same dead query;
the OAuth token (stored in config.json oauth:tokenCache + Keychain "Claude Safe Storage")
is valid the whole time.

The offending id is persisted client-side:

• Selected model → Local Storage/leveldb
• Available-models list (cache) → IndexedDB (https_claude.ai_*)

Notably: clearing Local Storage alone fixed it on 2026-05-29, but the retired id survived in
the IndexedDB model-list cache and the failure recurred on 2026-06-03 — so both stores need
to be considered.

Workaround (no re-login required)

1. Fully quit the app (live leveldb edits corrupt the store).
2. Move both stores aside (reversible):
   ~/Library/Application Support/Claude/Local Storage and .../IndexedDB.
3. Relaunch. The app recreates both, re-fetches a fresh model list, and selects the current
   default. OAuth survives in config.json + Keychain — no sign-in needed.

Suggested fixes (in priority order)

1. Don't let a single model fetch wedge Settings. Wrap the model_configs/<id> query in an
   error boundary + timeout so a 404 surfaces an error/empty state instead of hanging the panel.
2. Self-heal a stale selection. If the persisted model id 404s (or isn't in the freshly
   fetched list), fall back to the org default and overwrite the persisted id.
3. Invalidate on refresh. When the available-models list is refreshed, reconcile/evict any
   persisted selected-model id that is no longer present (covers both Local Storage and the
   IndexedDB cache).
4. Decouple the credentials banner from the model query so an unrelated 404 doesn't read as
   an auth failure.

Impact

App-wide unusability (Settings is unreachable; users perceive it as "Claude is broken
everywhere") on a predictable schedule — every time a previously-selected model is retired.