Queued composer text is silently discarded on mobile
Platform: Claude Code mobile app (Android)
What happens
While Claude is running a tool or generating a response, the composer switches to "Queue feedback…" mode. Text typed there is silently discarded in two cases:
- When Claude's turn ends and a new response renders, the queued text disappears without ever being sent.
- If the phone screen sleeps while text is sitting in the queue, the text is gone on wake.
There is no warning, no draft recovery, and no way to get the text back. It has happened dozens of times, including with messages several paragraphs long.
Expected
Queued text should either send when the current turn finishes, or persist in the composer as a draft. It should never be discarded without the user acting.
Impact
It makes iterating during a long run impossible. The only workaround is composing in a separate notes app and pasting in, which defeats the purpose of having a composer at all. For a paid product, silently destroying user-authored text is a data-loss bug, not a polish issue.
The moment an idea arrives is while Claude is working. That is exactly the window where the box is least trustworthy.
Frequency
Multiple times per day, every session.
Also
/bug does not exist in the mobile client — only /debug appears — so there is no in-app way to report this from the device where it happens.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Still happening a day later, multiple times today.
To be concrete about why this is severe and not a polish issue: the queue exists so I can keep thinking while Claude works. Losing it means that when I hand off a task, I'm not allowed to type the next thought until the work comes back. That's like telling an employee to go do something and then being unable to write down anything else you want done until they walk back in the door. The composer being untrustworthy during a run removes the entire reason to have a composer during a run.
The workaround being suggested is "draft in Notes and paste." That is not a workaround for a text box, that is an admission the text box doesn't work.
I run six projects through Claude Code and I'm on a plan that costs me real money every month, with a second seat under consideration. This bug alone is what has me evaluating whether to keep paying for it. Silently destroying user-authored text is the kind of defect that loses paying customers, and I'd rather tell you that than just cancel.
Minimum acceptable fix: queued text persists as a draft in the composer and is never discarded without the user acting. Send-on-turn-end would be better.
Second symptom, and I think it's a sharper version of this bug: the composer stays in queue mode after the turn has already ended.
Repro on Android:
To recover I have to tap the pill, select the text, copy it, switch to another work session, switch back, and paste it in again. Sometimes that gets picked up. Sometimes it doesn't and I retype the whole thing.
So the underlying problem may not only be that queued text gets discarded. It's that the client doesn't register the end of a turn and leaves the composer in queue mode when nothing is actually running. Every message typed in that state is stranded.
That also means the workaround suggested for the original report, "just wait until the run finishes before typing," does not help. The run has finished. The composer just doesn't know it.
Two things that would each fix this independently:
Fresh instance today, and it's the cleanest repro I can give you.
The assistant finished its turn and stopped. Nothing running: no tool call, no permission dialog, no picker, no streaming. The turn was fully complete and had been for some time.
I typed a single character,
y, and hit send.It did not send. It rendered as a gray queued pill. It stayed there. I backed out of the session to recover, and the
ywas lost.Worth stressing how small the payload is here. This is not a long message hitting some size limit, and it is not a race against a running turn. It is one character, typed into an idle session, silently swallowed.
That rules out most of the explanations that would make this a minor issue. The composer is entering queue mode when there is nothing to queue behind, and anything typed in that state is unrecoverable without leaving the session.
Practical effect: any exchange where the assistant stops and waits for a short confirmation is a coin flip on whether my answer survives. I have been rewriting my own working rules across six repos to avoid ever needing to send a short reply, which is a strange thing to have to design around in a chat client.
This happens _constantly_ and I don't know how it's not driving everyone who uses it internally at Anthropic insane enough to fix it
Queued messages also get erased if you switch to another convo.
And making this more frustrating is that in the Claude Code mobile app, queued messages don't seem to get accepted into the turn until the agent is done _everything_ whereas in claude code web, desktop, and CLI queued messages get accepted between tool calls