Windows desktop app: message input becomes unfocusable mid-conversation; force-quit and hard reboot do not clear it (logout/login reported as fix)

Environment

• Claude desktop app (Cowork), Windows 11 (x64)
• App version 1.24012.9 (Electron 42.7.0)
• August 2026

Summary

Mid-conversation, the message input box on a thread stopped accepting input — could not click into it or type. The thread was NOT generating; it simply stopped taking text. No visible error was shown. The conversation content was intact (it lives server-side); only the input editor was dead.

What I confirmed firsthand

The frozen thread's input never recovered through escalating, heavy-handed steps:

• Force-quitting the app (end task / kill) did NOT restore it.
• A full hard OS reboot did NOT restore it — after reboot, that thread's input was still dead.
• The only way I regained a usable input was to abandon the frozen thread and work in a different thread entirely.

(Recovery felt sluggish afterward, but that may just be normal cleanup following a force-quit, not necessarily part of the bug — noting it, not asserting it.)

Compounding issue on restart

After restarting, the left conversation/navigation sidebar was also missing (recovered with Ctrl+B when focus is outside the prompt box), which made getting reoriented harder.

Reported fix — NOT personally confirmed

Per prior reports (#58536), a plain restart does not clear this and logging out and back in is the reliable fix. I have not independently verified logout/login, so I'm flagging it as reported, not confirmed.

Likely root cause (per prior reports)

A transient network failure sends IndexedDB.open into a permanent retry loop ("Internal error opening backing store"); the ProseMirror input editor then fails to hydrate. This is consistent with my experience that neither a force-quit nor an OS reboot cleared it — i.e., stuck per-account local state that only a fresh login would reset.

Impact / severity

Near-loss of two days of work. It was avoided only because I run my own script that backs my work up to an offsite location every 15 minutes. A typical user has no such backup — if the input freezes and the thread's sandbox is later cleared, their unsaved work is gone, with no error and no warning. A silent-data-loss risk, not just an annoyance.

Requests

1. Fix the IndexedDB retry loop (exponential backoff; recreate the store after N failures) and surface a VISIBLE error when the backing store fails, instead of a silently dead input.
2. Document the recovery (logout/login) and the Ctrl+B sidebar toggle.
3. Persist unsaved session/thread state durably by default, so a frozen or cleared sandbox can never silently cost a user their work.

Related

#58536 (Windows input unfocusable; logout/login reported as fix), #69629 (input unresponsive across all conversations).