[Bug]: Mobile: message queued while agent is working is never sent if the app goes to background — only delivered on next app open

[iamtoled]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

1. Start a thread and wait for the agent to be actively working on a turn.
2. Send a follow-up message while the turn is in progress — it gets queued (locally, it seems).
3. Lock the phone or switch to another app.
4. Wait for the agent to finish its turn.

Expected behavior

The queued message is delivered to the agent once the current turn settles, regardless of whether the mobile app is foregrounded. Queuing should be owned by the server/backend, not the client.

Actual behavior

The queued message stays pending indefinitely. It is only actually sent when I reopen the app. If queuing happens client-side, it silently defeats the purpose of queuing on mobile: you queue a follow-up, put your phone away, and come back later to find the agent idle and the message never delivered.

Related

Not a duplicate of #231 / #4550 (those are feature requests for Queue/Steer modes) — this is about delivery reliability of the existing queue behavior when the mobile app is backgrounded.

[nhorto]

Partial fix landed in #6543 — the foreground half of this is fixed on main, but the backgrounded case this issue is actually about is not.

What #6543 fixed

The delivery rule in apps/mobile/src/state/thread-outbox-model.ts used to be:

return input.environmentConnected && !input.threadBusy ? "send" : "wait";

#6543 dropped the threadBusy term, so a message now goes out immediately while a turn is running instead of being held on the device.

That matters more than the steer-vs-queue framing, because the "wait" branch in useThreadOutboxDrain schedules no retry — it is a bare continue (use-thread-outbox-drain.ts:319-321). Nothing wakes it. It only re-evaluates when a React dependency changes, so a message that hit "wait" sat there until an unrelated re-render shook it loose.

/compact hit this hard: the Claude adapter reports compaction as "waiting" (ClaudeAdapter.ts:3119), which ProviderRuntimeIngestion maps to session status "running". The busy gate therefore stayed engaged for the entire compaction, and the follow-up message stayed on the device until the thread was reopened.

Worth flagging for anyone triaging incoming reports: the v1.0.4 version bump was cut at 2026-08-14 00:01 UTC and #6543 merged at 11:35 UTC the same day, so git merge-base --is-ancestor confirms the fix is not in 1.0.4. Every App Store build in the wild still has the old behavior, and #6543 is JS-only (no native deps, config plugins, or patches touched), so it is OTA-eligible against the existing fingerprint runtime version.

What is still open

"wait" remains reachable on main, now gated on environmentConnected alone (thread-outbox-model.ts:172), with the same no-retry continue behind it. That is exactly the scenario in the report: queue a follow-up, lock the phone, the socket drops, and the message cannot be delivered because the queue is client-owned. It drains on next foreground — which is the reported symptom verbatim.

So the core ask here, "Queuing should be owned by the server/backend, not the client," is untouched by #6543.

Minor leftover from #6543: threadBusy is still computed at use-thread-outbox-drain.ts:317 and still declared on the resolver's input type, but is now unused.

Verified by reading main @ ad117235b.

[simonseifert]

Confirming this, and adding a data point on how disruptive it is in practice.

Repro (T3 Code Mobile on iOS, desktop backend on 0.0.34-nightly.20260816.1110):

1. Agent is mid-turn on a long-running task
2. Type a follow-up on the phone and send. It queues, as designed
3. Lock the phone, or switch to another app
4. The message is never delivered
5. Reopen T3 Code and it finally goes through

The part that makes this worse than it sounds: step 3 is the normal thing to do. You send a follow-up precisely because the agent is busy and you're going to do something else for a few minutes. So the failure mode fires on the most common path, not an edge case.

Today I sent four follow-ups across a long session and they all arrived in a burst much later, well after the context that prompted them had passed. From the user side it reads as messages being silently swallowed, because there's no indication anything is still pending while the app is closed.

Two things that would each help independently of a full fix:

• Flush the queue on background transition rather than waiting for the next foreground
• Show pending messages somewhere visible, so a queued-but-unsent message is at least discoverable. Right now there's no way to see what's stacked up or cancel it