claude-code - 💡(How to fix) Fix [BUG] Claude for Windows: message input becomes unfocusable mid-conversation, placeholder text disappears, only logout/login restores it

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Preflight Checklist

I have searched existing issues and this hasn't been reported yet This is a single bug report (please file separate reports for different bugs) I am using the latest version of Claude Code

Note: This is a Claude Desktop app bug, not a Claude Code bug. Filing here as the only available channel for Claude Desktop issues (per precedent in #50856, #56234, #55879, and others).

What's Wrong? After a moderate amount of conversation activity (roughly half a dozen back-and-forth turns), the message input box at the bottom of the conversation enters a broken state:

The input box still renders. The "Write a message…" placeholder text disappears. The box cannot be focused — clicking inside it, tabbing to it, keyboard shortcuts, scrolling, switching to other conversations and back, restarting the conversation in a new chat — none of it restores the ability to type. All other UI elements (model picker, attach button, mic button, sidebar navigation) continue to render and respond normally. The only recovery is logging out of the desktop app and logging back in. Restarting the app alone does not fix it.

Screenshot of the broken state (note the missing "Write a message…" placeholder where it should be): Show Image (Will attach the screenshot directly when filing.) Environment

Claude for Windows: 1.7196.0 (2dbd78) Install source: Direct download from Claude (not Microsoft Store) OS: Windows 11 Pro, version 25H2, OS build 26200.8328 Frequency: Roughly once per day with normal use Account: Claude Max subscription

Reproduction I cannot produce a deterministic reproduction, but the pattern is consistent across occurrences:

Open Claude for Windows desktop app. Start or resume a conversation. Exchange messages with Claude for roughly half a dozen turns. The conversation does not need to be long; medium-length is enough. At some point during this activity, the input box transitions into the broken state described above.

It never happens on first conversation load. It always occurs after some interaction. Expected Behaviour The message input box should remain focusable and functional throughout a conversation, including its placeholder text, regardless of conversation length. Actual Behaviour The input box loses its placeholder text and becomes unfocusable, requiring full logout/login to recover. Logs Logs are at %APPDATA%\Claude\logs\claude_ai-web.log. There is a clear cascade of errors corresponding to the bug occurring this morning (2026-05-13). The smoking gun appears to be indexedDB.open failing and then never recovering — going into a multi-minute retry loop. This would plausibly explain the symptoms: if the backing store fails, persisted UI state (including ProseMirror editor state for the input box) cannot be hydrated. Trimmed log excerpt from the failure window: 2026-05-13 09:06:58 [error] [REACT_QUERY_CLIENT] QueryClient error: TypeError: Failed to fetch 2026-05-13 09:07:03 [error] [REACT_QUERY_CLIENT] QueryClient error: ["account_profile"] data is undefined 2026-05-13 09:07:07 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:09:18 [error] [REACT_QUERY_CLIENT] QueryClient error: ["account_profile"] data is undefined 2026-05-13 09:09:19 [error] [REACT_QUERY_CLIENT] QueryClient error: TypeError: Failed to fetch 2026-05-13 09:09:20 [error] Uncaught (in promise) null 2026-05-13 09:09:25 [error] [REACT_QUERY_CLIENT] QueryClient error: ["account_profile"] data is undefined 2026-05-13 09:09:29 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:09:58 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:09:59 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:09:59 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:10:08 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$...$AutoUpdater$updaterState$store$_update listeners added. 2026-05-13 09:10:08 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:10:13 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. 2026-05-13 09:11:11 [error] Uncaught (in promise) UnknownError: Internal error opening backing store for indexedDB.open. ... [continues firing every ~1–60 seconds through 09:18:53] The indexedDB.open "Internal error opening backing store" error then repeats every few seconds for approximately 12 minutes (09:07 through 09:18) without ever recovering. The app does not appear to attempt to rebuild or recover the backing store on its own. I can provide the full log file (~540 lines covering ~7 days) on request. Hypothesis The pattern in the logs suggests:

A transient network failure (TypeError: Failed to fetch) early in the session. Cache invalidation causes account_profile query to be undefined. Something attempts to write to IndexedDB and fails with "Internal error opening backing store." From that point, every attempt to open the backing store fails, and the app retries in a loop without recovering or surfacing the failure to the user. UI components that depend on hydrated state from IndexedDB (likely including the ProseMirror-based message input) fail to initialise properly — the input element renders structurally but its state-dependent behaviour (placeholder, focus, cursor) is broken.

Logout/login presumably wipes and rebuilds the IndexedDB state, which is why it's the only recovery path. Suggestions

The IndexedDB-open retry loop should have a backoff and a recovery path (e.g. close and recreate the database after N consecutive failures) rather than retrying forever. A user-visible indicator when the backing store enters a broken state would let users recover before encountering symptoms like the unfocusable input. The input editor should defensively handle the case where its persistence layer is unavailable, rather than rendering in a half-initialised state.

Additional Context There is also a separate stream of aria-hidden on a focused element warnings in the logs going back to 2026-05-07. These appear unrelated to the input bug but may be worth a separate issue from an accessibility standpoint.

What Should Happen?

I should be able to "Write a message..."

Error Messages/Logs

See attached log file

Steps to Reproduce

See details in "What's Wrong?"

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude for Windows: 1.7196.0 (2dbd78)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

claude.ai-web.log