Desktop composer draft replaced by a previous prompt from history, with no keystroke involved
What happened
While typing in the chat composer of the desktop app, the draft is intermittently replaced by a previous prompt from history. The typed text is unrecoverable. This has started recently - it was not happening a few days ago, so it appears to have arrived with a recent update.
It does not appear to be a keystroke
Originally assumed to be the Up key recalling history over a non-empty composer, but that has been ruled out by testing:
- Pressing Up with text in the composer does not trigger it.
- It happens during ordinary alphanumeric typing with no modifier keys.
- Crucially, it only occurs while typing without watching the screen. It has never once been reproduced while deliberately watching for it, which points at something asynchronous rather than input-driven.
~/.claude/keybindings.jsonis empty (all defaults). Setting"up": nullin both Chat and Global was tried in an earlier version and had no effect in either direction - it neither suppressed history recall nor disabled cursor-up.- Vim editor mode is off. Voice dictation is off.
No recovery
Down arrow does not restore the draft. chat:undo (Ctrl+Shift+-) does nothing. The text is simply gone.
Possibly related log entries
~/Library/Logs/Claude/main.log records no composer, draft or history events at all, so the failure itself is not logged. However it repeatedly shows:
[warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ...AutoUpdater_$_updaterState_$store$_update listeners added.
[warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 ...AppPreferences_$_preferencesChanged listeners added.
[warn] ProseMirror expects the CSS white-space property to be set, preferably to 'pre-wrap'.
[info] [process-memory] tree_rss_sum=2276MB electron(12)=1549MB top=[electron_renderer:796MB ...]Listeners stacking on the updaterState and preferencesChanged stores, with the composer being a ProseMirror instance in a renderer sitting at ~800MB, would be consistent with a store update re-rendering and resetting the editor without any key being pressed. Speculative, but it matches the timing.
Expected
A non-empty composer should never be replaced by history, matching normal shell behaviour where history is not recalled while the line has text. Losing a long draft with no undo is severe.
Environment
- Claude desktop 1.24012.9
- macOS 15.7.4
3 Comments
Additional detail from the reporter.
It is visible in the composer, not on send. The typed draft is replaced by a previous prompt from the same session while typing, on screen. It is not a rendering artefact of the sent message.
There is no way out of the state. Backspace does nothing. Down arrow does not restore the draft. The only way to clear it is Cmd+A and delete, then retype from scratch.
chat:undo(Ctrl+Shift+-) has no effect either.It cannot be reproduced deliberately. It never fires while watching for it; it only occurs while typing without looking at the screen. Multiple candidate causes were tested and eliminated: Up with a non-empty composer, Ctrl chords, vim mode (off), voice dictation (off), and
keybindings.json(empty, all defaults - and an earlier"up": nullin both Chat and Global had no effect in either direction).Version correlation. From
~/Library/Logs/Claude/main.log:The reporter ran 1.24012.1 for four days without seeing this. The first record of the problem is a few hours after 1.24012.9 was installed on 26 July, and it has occurred repeatedly since - several times within a fifteen minute stretch. That points at a regression in 1.24012.9.
Losing a long draft with no undo, and no way to clear the state short of select-all-delete, makes this expensive rather than merely annoying.
Related request: there is no supported way to roll back off a bad build.
Having identified 1.24012.9 as where this started, the obvious mitigation is to go back to 1.24012.1 and wait for a fix. That does not appear to be possible:
ShipIt_stderr.logremains in~/Library/Caches/com.anthropic.claudefordesktop.ShipIt/.Claude.appfrom a backup would be undone.That leaves a machine-level backup as the only route, which many users will not have, and which does not survive the next auto-update anyway.
Please consider publishing previous desktop releases for download, and a way to pin or defer an update. When a regression costs users their typed work, being able to step back one version until it is fixed matters more than being current.
Correction - this is history SEARCH, not history recall. A screenshot taken mid-incident shows the composer prompt reading
Search history:with the typed characters displayed as the search query. So the sequence is:history:search(Ctrl+R) fires, apparently accidentally, and the composer enters history search mode.HistorySearchcontext,historySearch:acceptis bound to both Escape and Tab. Pressing Escape - the natural way to get out of an unexpected mode - therefore confirms the highlighted history item and pastes it over the draft.That accounts for every symptom that previously made no sense:
historySearch:cancel(Ctrl+C) does not work in the desktop app - it is swallowed as the hardcoded interrupt. So once in the mode there is no non-destructive exit at all: Escape and Tab overwrite the draft, Ctrl+C does nothing.Unbinding does not help.
"ctrl+r": nullwas set in bothChatandGlobalin~/.claude/keybindings.json. Ctrl+R still opens history search. This matches an earlier attempt where"up": nullin both contexts had no effect in either direction. The keybindings file appears to be ignored entirely in this version, so users have no way to disable the shortcut that is costing them work.Two suggestions: