[BUG] Mobile (Pixel 8 Pro): input typed while the agent is busy stays as an unconfirmed draft and is silently discarded when the app is backgrounded
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On the Claude Android app (Claude Code on the web sessions), a message typed while
the agent is busy is NOT committed. It stays in an editable / "unconfirmed draft"
state (tappable to re-edit), not shown as a confirmed/queued message. If the app
becomes inactive/backgrounded (screen lock or app switch) while in that state, the
draft is silently discarded. Nothing remains in the conversation transcript — there
is no record the input ever existed.
Environment:
- Device: Google Pixel 8 Pro
- Android version: 16
- Claude Android app version: 1.260618.10 (26061810)
- Client: Claude mobile app, Claude Code on the web sessions (claude.ai/code)
- Agent running on Anthropic-managed cloud environment
Steps to reproduce:
- Start a session where the agent runs a long task (stays "busy" for a while).
- While the agent is busy, type a message in the Claude Android app.
- The input is not committed/sent — it stays editable (re-tappable draft).
- Background the app (lock screen / switch apps) before the agent replies.
- Return to the app: the typed input is gone, with no entry in the transcript.
Actual: the draft is silently discarded on backgrounding; instructions are lost with
no evidence in the conversation. The only way to avoid loss is to keep the app
foregrounded until the agent replies (which "confirms" the input).
Impact: silent loss of user instructions and loss of conversation evidence. High
impact for long-running tasks — exactly when queuing-while-busy is most needed.
Related issues:
- #20431 (Queued/pending user input silently lost while agent is working — closed as
"not planned"/stale; this adds the mobile draft-discard-on-background path)
- #61718 (Cowork queue: queued messages delivered but not actioned)
- #51267 (Remote Control mobile: session silently hangs mid-execution)
- #57497 (Regression: can no longer type/queue messages while agent is running)
What Should Happen?
Input typed while the agent is busy should be reliably committed and queued — shown
with a visible "queued" state, not an editable draft that can silently vanish. It
should survive the app being backgrounded (screen lock / app switch) and be delivered
to the agent on its next turn, with a record in the conversation transcript. The user
should never lose typed instructions just because the agent was busy or the app went
to the background.
Error Messages/Logs
None — and that is part of the bug. The failure is completely silent: no error
message, toast, or warning is shown when the typed input is dropped. The draft simply
disappears and leaves no entry in the conversation transcript, so there are no
client-side logs visible to the user to attach. (If maintainers can point to where
mobile app / session logs are captured, I can provide them.)Steps to Reproduce
- Start a session where the agent runs a long task (it stays "busy" for a while).
- While the agent is busy, type a message in the Claude Android app.
- The input is not committed/sent — it stays editable (a re-tappable "draft"),
not shown as a confirmed or queued message.
- Background the app before the agent replies (lock the screen or switch apps).
- Reopen the app: the typed text is gone, and there is no entry for it in the
conversation transcript.
Claude Model
Not sure / Multiple models
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude Android app 1.260618.10 (26061810) — Claude Code on the web session (no local CLI)
Platform
Anthropic API
Operating System
Other
Terminal/Shell
Other
Additional Information
This is a Claude Android app / Claude Code on the web bug, not a CLI bug. The
Operating System, Terminal/Shell, and Platform dropdowns above don't have a mobile
option, so "Other"/closest was selected.
Client details:
- Device: Google Pixel 8 Pro
- Android version: 16
- Claude Android app version: 1.260618.10 (26061810)
- Session type: Claude Code on the web (claude.ai/code), agent on Anthropic-managed cloud
Related issues: #20431 (closed not-planned/stale), #61718, #51267, #57497.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Ytterligare en reproduktion av samma mönster (annan plattform, inte bekräftat Pixel 8 Pro specifikt men samma beteende): om appfönstret tabbas bort/byts till ett annat aktivt fönster under för lång tid medan Claude arbetar, försvinner det inskrivna meddelandet helt — inte kvar som redigerbart utkast, bara borta. I kombination med det som beskrivs i #73118 (meddelanden tappas även vid busy-tillstånd utan backgrounding) verkar detta vara samma underliggande brist i hur klienten hanterar meddelanden som skickas medan agenten är upptagen, oavsett trigger (busy vs. backgrounding).
same issue. images work, but other message disappear if it is queued and my phone screen goes off or i switch to another app. doesn't seem like the app even closes.
+1, this bug completely defeats the purpose of "mobile steering" since it's forcing users to be glued to the screen waiting for the message to go through, or else, it's just deleted and gone.
Also: #63975, #65224, #65425 and probably many more...
Also hitting this on Samsung, so it isn't Pixel-specific.
I can confirm backgrounding is the trigger. Two things to add:
It only happens when subagents are outstanding. If the main agent is
just working in context, I can background the app and the draft
survives. If the main agent has dispatched subagents (Task tool) and
they're still running, backgrounding discards the draft. Same app, same
session, same action — the difference is whether subagents are in
flight. That suggests something specific to the subagent dispatch path
rather than general busy-state handling.
(Caveat: main-agent-only turns tend to be shorter for me, so I can't
fully rule out that this is really a duration threshold. But the split
has been consistent enough that I don't think it's just turn length.)
It's getting worse, and the workaround is gone. Originally the loss
was intermittent and restarting the app restored working input.
Restarting no longer recovers it. The native app is now unusable for
sending messages into affected sessions — I have to switch to claude.ai
in a browser, where input is delivered normally in the same session.
Worth noting #73118 (open, P0) describes the same failure on the VS Code
extension — queued input lost during long agent turns. These may share a
root cause rather than being client-specific.