iOS remote app: queued/unsent prompt is discarded when navigating away from a session and back
Platform
Claude Code remote control iOS app (mobile companion app).
Summary
While the agent is busy processing a turn, a prompt entered into the composer — a message that has not yet been consumed by an LLM turn — is held only in the in-memory chat view. If you navigate away from the session (to another session, or back to the session list) and return, that pending prompt is silently discarded. It is not persisted across the app's navigation.
This is a functional / data-loss problem, not just a cosmetic UI glitch: the queued prompt is often a long, carefully-composed message, and losing it silently can wipe out a lot of context and significantly degrade the experience.
Steps to Reproduce
- Open a session where the agent is actively working on a task (busy / mid-turn).
- Enter a prompt into the composer. It stays visible in the chat as a pending/queued prompt — not yet consumed by an LLM turn.
- Navigate away — either open a different session, or go back to the session list.
- Return to the original session.
Expected Behavior
The pending, unsent prompt is still present when you return, ready to be consumed by the next turn. Queued input should survive in-app navigation just like it survives waiting for the current turn to finish.
Actual Behavior
The pending prompt is gone. It was only held in the chat view and is not preserved across navigation, so it is silently lost on return — with no warning and no way to recover it.
Impact
This is a functional data-loss bug, not merely a UI issue. Any prompt queued while the agent is busy is lost the moment you briefly leave the session (or glance at another one), forcing the user to retype it from scratch. Queued prompts are frequently long and context-rich — losing one can mean losing a significant amount of carefully-composed input with no warning and no way to recover it, which materially degrades the user experience.
Environment
- App: Claude Code remote control (iOS)
- OS: iOS
- Trigger: Navigating away from a session (to another session or the session list) and back, while a prompt is queued/unsent.
Attachments
https://github.com/user-attachments/assets/3debd8df-07f5-497f-b57b-67dd1cd3b7c1
3 Comments
Please fix this, should be a simple fix!!
Confirming this on Android — same repro, and with a contrast that I think narrows the bug down to exactly one place.
Environment
Repro (identical to the one above)
The part that isolates it: backgrounding does not lose it
On this build, if I leave the pending message in place and switch apps entirely — go to Gmail, do something else, come back — the message is still there, still pending. It survives the app going to background.
Only in-app navigation destroys it.
That contrasts with #71603 (Android, backgrounding) and with symptom 1 in #85924. If backgrounding is now safe on Android while
backstill isn't, the draft is being preserved at process/app level but nothing saves it when the session screen itself is unmounted on navigation. That would make this a single-site fix — persist the composer draft keyed by session id across the navigation stack — rather than a general persistence problem.(Worth someone re-checking #71603 on a current Android build; it may already be fixed, which would leave this issue as the only live half.)
Why this hits the multi-session workflow hardest
The whole point of the Code tab is supervising several remote sessions at once. Steering N busy agents necessarily means: queue a message here, back out, go check that one, come back. So the exact navigation pattern the tab is designed for is the one that destroys queued input. The workaround suggested in #85924 (back out and re-enter before typing) doesn't apply either — here backing out is what causes the loss, not what avoids it.
Dictated input makes it worse, as noted in #85924: you can't re-read what you lost, you have to reformulate the whole instruction from memory.
Minimum fix
Persist the pending composer text per session across navigation, the same way it already survives backgrounding. Even without send-on-turn-end, simply not discarding it would remove the entire problem.
Confirming this on iOS, still a major headache in October 2026. How has this not been fixed? ChatGPT/Codex figured this out ages ago. Imagine starting a text message, getting a text from someone else, replying to them, then going back to your first message and finding it gone because the developer was this sloppy. Unbelievable.
Claude Code on iOS deletes unsent drafts. This is data loss, not a UX nitpick.
In Claude Code sessions on the iOS app (Remote Control), anything typed in the composer is permanently destroyed if you leave the session before sending. A one-pixel mis-tap or a left-edge swipe wipes out paragraphs of work. There's no warning, no undo, and no way to recover it.
Affected: iPhone and iPad, on both iOS 26 and iOS 27. Claude app version: latest.
This isn't one device or one OS version. It's how the app is built.
It's not limited to queued prompts. Unsent text is lost even when the agent is idle, and tapping outside the session triggers it just like the back swipe does.
Repro: Open a Code session → type a long message → tap outside or swipe back to the session list → reopen the session → the composer is empty.
This has been reported repeatedly: #53598 (April, closed but never fixed), #63975 (May), and this issue (July). Months later, it still happens every time.
This is bad design. The regular Claude chat in the same app keeps drafts. ChatGPT/Codex on iOS keeps drafts. Developers with a fraction of your resources solved this long ago. You need to as well.
As @victorrentea points out above, the Code tab is built for juggling multiple sessions, and that's exactly the navigation that destroys input. If Remote Control is going to be taken seriously as a way to do real work from a phone or tablet, this has to be a top-priority fix. Right now it costs me work every week, and I hesitate to put anything substantial in the Code tab at all.
Fix required:
• Save drafts locally, per session, until I send or clear them. They need to survive navigating away, switching sessions, backgrounding the app, and the agent being mid-turn, whether or not a turn is running.
• At the very least, warn before discarding unsent text, or block the dismiss gesture while the composer has content.