[Bug]: Mobile messages return from Pending to the composer on desktop-created threads

[NitayRabi]

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. Create or start a thread from the T3 Code desktop app.
2. Open that existing thread in the mobile client.
3. Type a follow-up message and tap Send.
4. Watch the message state in the mobile UI.

Expected behavior

The message should remain queued/pending until it is accepted, then start a turn in the existing thread.

Actual behavior

The message briefly moves into the Pending state, then leaves Pending and is restored to the composer text box. No message is sent and no turn starts.

This is distinct from #11755: in that issue the Send tap is swallowed before dispatch while the iOS editor is focused. Here the UI visibly enqueues the message into Pending before delivery rolls back and restores the draft. It is also distinct from #7390, where the Send button remains disabled while a stale native draft carries between threads.

The failure has been observed on threads opened from the desktop app. Whether the same rollback occurs for threads created entirely on mobile has not yet been confirmed.

Impact

Major degradation or frequent failure

The affected thread cannot be continued from mobile; the desktop client is required as a workaround.

Version or commit

Not collected.

Environment

T3 Code desktop and mobile clients. Mobile OS, app versions, provider, and connection mode were not collected.

Logs or stack traces

No logs collected. The visible state transition is: composer -> Pending -> composer.

Screenshots, recordings, or supporting files

None collected.

Workaround

Send the follow-up from the desktop app.

[juliusmarminge]

Triage

Confirmed as a real mobile send bug, distinct from the two issues called out in the report.

This is not a duplicate of #11755 (Send tap never dispatches while the iOS editor is focused) or #7390 (Send stays disabled; native draft bleeds across threads). Here the UI does enqueue: the feed shows Pending, then the message leaves Pending and the text returns to the composer. That is the thread-outbox restore path, not a swallowed tap.

What’s going on

Mobile follow-ups do not call startTurn on the tap. They go through the durable outbox:

1. use-thread-composer-state.ts publishes the queued message, clears the draft, and the feed labels the row Pending (ThreadFeed.tsx / pending-thread-feed.ts).
2. use-thread-outbox-drain.ts confirms the write, then delivers thread.turn.start.
3. On a failure classified as restore, restoreRejectedQueuedMessage merges the payload back into the composer and deletes the outbox entry — exactly composer → Pending → composer.

thread-outbox-model.ts treats transport / RpcClientError as retry (message stays Pending). After #10245, a dropped socket should not look like this. Immediate rollback means a deterministic restore:

• OrchestrationDispatchCommandError or EnvironmentAuthorizationError from startTurn
• Antigravity model treated as unavailable
• Non-retryable attachment / file-capability rejection

If the thread were missing from the live shell list, the drain removes the outbox row and does not put text back. The reported restore is the reject-and-recover path, not that drop.

Desktop-created threads are a plausible trigger: existing session, desktop model/runtime/interaction mode, or a dispatch invariant on thread.turn.start (decider.ts / Normalizer.ts). #10202 / #10205 is a related desktop↔mobile model-override handoff, but that bug keeps the wrong model rather than rolling the message back.

Suggested fix

1. Reproduce: create a thread on desktop, open it on mobile, send a plain-text follow-up. Compare with a thread created entirely on mobile (still unconfirmed).
2. Read the restore reason: the connection-error banner (setPendingConnectionError) and [thread-outbox] queued message delivery failed (stage, action, cause). That string is the bug.
3. If startTurn is rejected, fix the command/payload or stop classifying that error as restore. If the model is unavailable, block Send before enqueue. If it is auth/scope, say so instead of silently returning the draft.
4. Do not change [Bug]: iOS composer requires tapping outside text box before Send works on follow-up messages #11755 (focus/Send remount) or [Bug]: iOS composer wedges — send stays disabled and the draft carries into other threads #7390 (revision-gated editor) as part of this.

Severity: high — the thread cannot be continued from mobile; desktop is the workaround.

Accepting this. Localized to the mobile outbox drain + startTurn for existing threads. New-task / mobile-created threads are the control once confirmed.

Please add if you still have the thread

• Did a connection / send error banner appear when Pending rolled back? Exact text.
• Same rollback on a thread created only on mobile?
• Mobile OS and app version, provider, connection mode (local / Tailscale / T3 Connect).
• Any [thread-outbox] lines from device logs around the Send tap.