[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

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.

• Device: Samsung Galaxy A36 5G (SM-A366U), T-Mobile
• OS: Android 16, One UI 8.5
• Build: BP4A.251205.006.A366USQS8CZF1

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.

Also reproducing this, in a configuration I don't think is covered yet: Remote Control driving a local Claude Code CLI session, rather than Claude Code on the web or an Anthropic-managed cloud environment.

• Client: Claude Android app 1.260721.20
• Device: Samsung Galaxy S24 Ultra (second Samsung report here, so definitely not Pixel-specific)
• OS: Android 16, One UI 8.5, kernel 6.1.145
• Host: claude CLI running locally on Debian 12, connected over Remote Control

Core behavior matches the original report. Typing while the agent is working produces a pending "about to happen" message rather than a committed one — tapping it returns the text to the input box for editing. It doesn't become real until the current turn returns, and it's discarded silently if I leave before then.

Three additions:

1. Backgrounding isn't the only trigger — switching sessions inside the app does it too. I usually have several concurrent Claude Code sessions open. Hitting back and opening a different session loses the pending message in the session I left, without the app ever being backgrounded. (This is what #77010 describes, but that one is filed against web/macOS; here it's Android + Remote Control.)

2. The pending message sometimes does land mid-turn. Not reliably at the end — occasionally it gets picked up partway through. I haven't instrumented this, but it seems to happen on turns involving tool calls, which would line up with #49373's description of the queue flushing at the next LLM pause rather than at true end of turn.

3. A workaround that survives it: copy the pending text, back out of the session, re-enter it, paste, and resubmit. That is noticeably more reliable than letting the queued message sit. Flagging it because it's different from the app-restart workaround mentioned above — restarting doesn't help me either, but re-entering the session does.

Since this reproduces against a local CLI host over Remote Control, as well as on web and (per #73118) in the VS Code extension, that seems to point at the client's handling of pending input rather than anything specific to the execution environment.

Confirming this on another account — same symptom, hit it repeatedly today during a long working session.

Reproduction matches the original report exactly: I send a message while the agent is still busy, it sits in the pending/unconfirmed state, I switch to another app, and on returning the message is gone. No trace in the transcript, and the agent never received it — from its side the message simply never existed.

Two things that make this worse in practice than it may look:

1. Silent loss. There is no error, no retry affordance, nothing marked as failed. The user believes the instruction was delivered and the agent is ignoring it, which is exactly how it read on my end until I checked with the agent whether it had received anything.

1. It bites hardest during long tasks. The failure requires the agent to be busy — which is precisely when a user is most likely to switch away and come back, and most likely to be sending follow-up corrections that matter (e.g. "stop, wrong target" / "don't touch prod").

Only workaround I have found is to wait for the pending indicator to clear before backgrounding the app, which defeats the point of being able to send follow-ups during a long run.

Environment: Claude mobile app (Claude Code session) on a POCO F5, Android.

Worth noting for triage: the original report is on a Pixel 8 Pro, this one is a Xiaomi/POCO device — so it does not look vendor- or ROM-specific.

Another data point, on a different device and a different session type — the same
failure shows up over Remote Control to a local CLI host, not just cloud/web sessions.

• Device: Samsung Galaxy S25, Android 16
• Claude Android app: 1.260824.0 (26082400)
• Host: Claude Code CLI 2.1.250, Ubuntu 24.04 (x86_64)
• Mode: Remote Control from the phone → long-running local CLI session on a desktop

When the agent is actively thinking or executing a tool, a message sent from the Android
app does not reliably reach the run. It neither steers the current turn nor visibly queues
for the next safe point — it typically appears not to send until the agent finishes. The
CLI itself handles mid-run instructions fine, so this reads as a client/transport gap
rather than a model one.

Beyond the draft-discard-on-background path in the original report, the part that bites
me is that neither behaviour is specified or indicated. The client should support, and
say which of these it is doing:

1. Immediate steering — the message is injected into the running turn, as the CLI does; or
2. Reliable queued delivery — accepted, held, and applied at the next safe point

(between tool calls / at the next turn boundary).

Either is workable. What is not workable is silence: no sent/queued/delivered/applied
status, no queue position, and no message when steering is impossible in the current
session state. If the client cannot steer, saying so is far better than accepting the
text and leaving me to guess whether it landed.

Practical impact: the only dependable way to correct course from the phone is to interrupt
the agent, which can discard in-flight progress or derail a task that was otherwise on
track. That matters most precisely on mobile — I am on the phone because I am away from
the machine and cannot fall back to the local terminal to re-steer.

Also closely related: #85924 (queued composer text silently discarded on mobile), and
#81845 for the mirror-image direction (messages typed locally during a turn never syncing
out to connected devices).

Happens for me too. Android. 100% repro rate. Any message sent to my Windows remote host is in a pending state while it is thinking. If I switch away from the session or lock the phone then it is gone. Makes the app much less useful since I can't queue things I found while it is doing anything else.

Same. Also happens after /clear and /context. Workaround is pressing stop a few times to get back attention

[Claude] Data point from a different surface: on Android in a Remote Control session, input typed while the agent is busy is committed to a visible queued message rather than left as an editable draft — so the queued-state part of the expected behavior here already exists somewhere in the app. It still gets lost, just on a different trigger: backgrounding preserves the queued message, and navigating away from the session inside the app drops it. Worth flagging because it suggests a queued state alone does not fix this. The queue has to be held by the session rather than by the screen displaying it. Remote Control side: #63975.