Thread outbox: UI polish, queue images, send-and-interrupt — and decide whether the queue should survive

[radroid]

Follow-up on the thread outbox (queue-while-running) feature from #26. Three concrete gaps plus one
design decision that should be settled first, because it changes how much of the rest is worth
building.

---

0. The decision: does the queue earn its keep?

The queue exists because you can't talk to a running turn. The alternative is send-and-interrupt:
type, hit send, the current turn is interrupted and your message starts the next one immediately.
That is what most agent UIs do, and it is what people reach for reflexively.

I checked whether upstream already covers this — it does not:

// packages/contracts/src/provider.ts:87
export const ProviderInterruptTurnInput = Schema.Struct({
 threadId: ThreadId,
 turnId: Schema.optional(TurnId),
});

Interrupt is a pure stop with no message payload, so there is no upstream path that both stops the
turn and submits text. The queue is not redundant today.

But if we add send-and-interrupt, the queue's genuinely unique value shrinks to:

• Deferred send — "finish what you're doing, then do this" (interrupting would discard in-flight work)
• Disconnected buffering — composing while the backend is unreachable
• Survives reload — localStorage-backed, so a refresh doesn't lose the message

Those are real, but they are a much smaller feature than what exists now. Decide first: keep the
queue as the primary mid-turn path, demote it to a secondary "send after this turn" affordance behind
send-and-interrupt, or remove it. Everything below assumes it survives in some form.

---

1. The queue UI is visually heavy

From the current build (screenshot in thread):

• The queued-message list renders as a full-width bordered card stacked on a bordered composer,
  producing a heavy double-border container that dominates the bottom of the thread.
• A one-line message gets a card with card-sized vertical padding. With 3-4 queued messages this
  pushes the composer far up the viewport.
• QUEUED MESSAGE · 1 sits as a caption colliding with the container's top border.
• Edit (pencil) and delete (trash) icons are pinned to the far right, visually detached from the text
  they act on, and are always visible rather than on hover/focus.
• The footer now carries three competing controls — a progress spinner, a saturated red stop
  button, and a blue "Queue" button. The red is the highest-contrast element in the composer despite
  being the secondary action.
• Nothing states the contract: that these send automatically when the turn finishes.
• No reordering. removeThreadOutboxMessage exists but there is no move-up/move-down or drag.

Suggested direction: collapse each queued item to a single dense row (one line, truncated, hover-
revealed actions), drop the nested border so the queue reads as part of the composer chrome rather
than a second panel, and add a short "Sends when this turn finishes" hint.

2. Images can't be queued

Reproducer: attach an image while a turn is running, add text, press Queue. The text queues, the image
is dropped, and you get a warning toast:

Images aren't queued — Queued messages are text-only; attached images were not added to the
queued message.

Image-only (no text) is refused outright with a similar toast.

The current behaviour is deliberate and correctly implemented — the code comments in
ChatView.tsx explain the reasoning, and the toast fires only after a successful enqueue so a failed
enqueue never misreports. The limitation is the storage layer:

// apps/web/src/outbox/threadOutboxStorage.ts
// localStorage-backed persistence for the thread outbox ...

localStorage is string-only with a ~5MB quota, so blob-backed image previews cannot survive a
reload. Queuing images needs the outbox moved to IndexedDB (stores Blobs natively, far larger
quota), with the queued item holding a blob reference and the drain rehydrating it at send time.
Needs a migration path for messages already in localStorage, and a quota/eviction story.

Note this also affects the mobile outbox, which mirrors the same design.

3. Send-and-interrupt

Add a way to stop the running turn and immediately send the composed message. Requires a contract
change — either a new RPC or an optional message payload on the interrupt input, since the current
one carries none. Should be explicit rather than the default Enter behaviour, so nobody discards a
long-running turn by muscle memory.

---

Suggested order

1. Settle §0 — it determines whether §1 is polish or removal.
2. §3 send-and-interrupt (contract change, highest user value).
3. §1 UI polish, scoped by the §0 outcome.
4. §2 images — largest change (storage migration), lowest urgency given the toast is honest today.

[radroid]

Decisions and status

§0 — the queue stays, and send-and-interrupt is not being built. The existing Stop button is
good enough for the "stop this and do my thing instead" need, so the queue keeps its current role
rather than being demoted or removed. Nothing merged in #26 is being deleted.

Worth recording why Stop covers it, because it is not obvious from the issue text: reading the
code, Stop already behaves as send-and-interrupt when something is queued. thread.turn.interrupt
leaves the turn interrupted with a completedAt and the session interrupted/stopped
(ProjectionPipeline.ts:1299-1332, :1103-1112), and canSettle accepts any session status that is
not starting/running (threadSettled.ts:78-91). So resolveThreadOutboxDeliveryAction returns
send and the drain dispatches the head within a tick of the Stop. Queue a message, press Stop, and
it starts immediately — which is exactly the §3 interaction, with no contract change.

Two caveats on that. It is a code-reading result, not a runtime one — I could not produce a real
running turn in a sandbox (the local provider's OAuth is stale). And the flip side is that Stop
does not stop the queue: with three messages queued, Stop fires the next one rather than stopping
everything. There is no pause or clear-all affordance. If that turns out to be the wrong default, the
seam is a new input to resolveThreadOutboxDeliveryAction (threadOutbox.logic.ts:146), which is a
pure function and already fully unit-tested.

§1 has landed on t3x/issue-35-outbox-interrupt-and-polish: dense single-line rows, the nested
card border removed so the queue reads as the top section of the composer surface, the caption moved
inside the padded block and now carrying the contract ("Sends automatically when the chat is ready"),
hover/focus-revealed row actions, a scroll cap so a long queue stops pushing the composer up, and
move up/down reordering. A four-message queue now occupies ~130px against ~230px before. Stop also
drops to a quiet outline when it sits beside Queue, so the red circle is no longer the
highest-contrast element in a composer whose primary action is Queue.

One correction to the §1 list: the "progress spinner" in the footer is upstream's context-window
meter (ContextWindowMeter.tsx), an SVG ring that renders whenever a context window is known, not
a progress indicator for the running turn. There is no spinner in the running-turn footer. I left it
alone — it is upstream's and it is doing its job.

---

§2 (queued images) — deferring, and this is why

Closing this out as not worth the effort right now. Recommend leaving it parked rather than
scheduling it.

The one-line version of the issue text — "move the outbox to IndexedDB" — undersells it, and the
premise is also slightly off. Mobile does queue images today, and it does not use a blob store to
do it: QueuedThreadMessageSchema carries a required attachments array persisted as inline
base64 data URLs (apps/mobile/src/state/thread-outbox-model.ts:46). So the web port did not
simply skip a feature; base64 inflates payloads ~33%, and localStorage's ~5MB quota is per-origin and
shared with every other thing the app stores there. Two screenshots would plausibly exhaust it, and
the failure mode is a QuotaExceededError that rejects the enqueue. Copying mobile's approach is not
an option on web, which is why IndexedDB comes up at all.

The port itself is genuinely cheap. ThreadOutboxStorage is a clean three-method,
already-Promise-returning seam (threadOutboxStorage.ts:35-39), injected in exactly one place
(threadOutbox.ts:16-19), and no call site reaches into localStorage directly. An IDB
implementation is one new module plus one changed line.

Everything around it is where the cost is:

1. A data migration with a silent-data-loss trap. Existing t3code:thread-outbox:v1:* records
   have to be read, upserted into IDB and deleted, including the case where both stores hold the same
   messageId. Adding attachments also means a schema change, and schemaVersion is a
   Schema.Literals([1]) (threadOutbox.logic.ts:34) while storage swallows decode failures as
   console.warn "skip invalid" (threadOutboxStorage.ts:82-94). Bump it without accepting the old
   value and every user's queued messages are silently deleted on upgrade, with no error anywhere.
2. Blob rehydration at send time. The drain currently sends attachments: []
   (useThreadOutboxDrain.ts:210-226). Queued images mean holding a blob reference, rehydrating it at
   dispatch, and deciding what happens when the blob is gone but the text is not.
3. A quota and eviction story that does not exist today. IDB quota errors are async and
   per-transaction; the manager's durable-write-first invariant depends on storage rejections
   rejecting (threadOutboxManager.ts:104-112). Someone has to decide what gets evicted, when, and
   what the user is told.
4. Invariants the new backend must preserve or quietly break things. load must return every
   message across all environments — clearEnvironment depends on it surfacing persisted-only
   "zombies" so a re-added server cannot resurrect and silently deliver old messages
   (threadOutboxManager.ts:173-188, covered by test). Per-record fault isolation must survive. And
   the no-window/blocked-storage fallback needs handling (today write silently no-ops with no
   window, so an enqueue "succeeds" non-durably — a pre-existing hole worth fixing regardless).
5. More delta on the repo's worst seam. Removing the two toasts and the image-only refusal means
   editing ChatView.tsx (:4571-4589, :4619-4631), already the highest-risk file in the fork
   ledger at risk 9540.
6. Mobile. Web-on-IDB and mobile-on-base64 diverge further, so either the divergence is recorded
   or mobile converges too — a second, unrelated migration.

Against all that, the current behaviour is honest rather than broken. The toast fires only after a
successful enqueue, so a failed enqueue never misreports; an image-only submit is refused outright
and the draft is left intact so the image is never destroyed; and the user is told plainly that they
can wait for the chat to idle and send with the image. The gap is disclosed, not silent — which is
what makes it safe to leave.

Happy to pick this up if it starts biting in practice; the storage seam means the work will not have
gotten harder in the meantime.

[radroid]

Revising §0: steering already existed, and the outbox was suppressing it

My previous comment concluded the queue should keep its role and §3 wasn't worth building. That was
right about the conclusion and wrong about the reason, and the correction matters enough to record.

I said Stop doubles as send-and-interrupt. It does. But I missed the more important thing: t3code
already supports sending into a running turn, and the fork's outbox was the only thing preventing
it on web.

• Upstream's onSend has no phase === "running" guard (ChatView.tsx:4663). isSendBusy is
  activeLocalDispatch !== null, not "a turn is running".
• The decider has no running-turn invariant (decider.ts:751), and ProviderService.sendTurn has no
  busy check.
• Four of five adapters fold a mid-turn sendTurn into the live turn — same turn id, no second
  turn.started. ClaudeAdapter.ts:3729 offers the message into the one long-lived query() whose
  prompt is a stream, i.e. the same stdin the Claude Code CLI uses (--input-format stream-json,
  stdin held open). Upstream has a test for it: ClaudeAdapter.test.ts:976.
• Upstream even has client-side handling to acknowledge a steering message so the composer doesn't
  stick in "Sending" (ChatView.logic.ts:537).

So before #26, typing during a running turn on web steered. Afterwards, resolveComposerSendLabel
returned "Queue" whenever the thread was busy, onSend's queue branch ran ahead of the immediate-send
path, and the message waited out the whole turn — sometimes longer, since canSettle also refuses
while an approval is pending, which means a queued message sits there while the agent is blocked
asking you something.

This is a worked example of the "parallel paths" hazard in docs/t3x/SEAMS.md: the fork added a
second way to do something upstream already did, and it silently won.

What changed

Queue now means "cannot go out now" rather than "the thread is busy":

Situation	Before	Now
Not connected	Queue	Queue
Outbox already has messages	Queue	Queue (a new message must not jump the line)
Running turn, steer-capable driver	Queue	Send — folded into the work in progress

The running-turn footer pairs Stop with whichever primary action applies. That is not just
discoverability: Enter doesn't submit on a mobile viewport, so the button is the only mid-turn send
affordance on a phone.

The Codex caveat

Steering support is an allowlist, because there is no capability flag anywhere — the contracts
have no supportsSteering, so it has to be asserted per driver against each adapter's sendTurn.
Claude, Cursor, Grok and OpenCode steer (three with tests). Codex does not:
CodexSessionRuntime.ts:1305 issues turn/start unconditionally and t3code never calls the
protocol's turn/steer RPC, which does exist. Codex therefore keeps queuing, as does any driver
added later.

Failing closed matters because a refused steer is invisible: providerService.sendTurn is
Effect.forkScoped (ProviderCommandReactor.ts:1110), so the client's command has already succeeded
by the time an adapter refuses — the message is persisted, the composer is cleared, the draft-restore
path never runs, and the only trace is a provider.turn.start.failed activity. Failing closed costs a
queued message; failing open loses one. That silent-failure hole is upstream's and still there; it was
just unreachable while the queue never sent mid-turn.

Still open

• Codex steering. The turn/steer RPC is right there in the generated schema and unused. Wiring
  it (and handling activeTurnNotSteerable) would move Codex onto the allowlist.
• Surfacing provider.turn.start.failed. Worth its own issue; it touches upstream-owned
  orchestration and UI.
• The queue while blocked on an approval. Still holds, which probably reads as broken.

[radroid]

Review results, and issues worth filing

I could not drive a live Claude turn in a sandbox (no Claude provider instance there, stale Codex
OAuth), so instead I ran an adversarial review of all three commits: five independent reviewers,
then one refutation pass per finding. 20 candidates, 18 refuted, 2 confirmed. Both confirmed
defects were mine, both were reproduced in Chromium, and both are now fixed on the branch.

Fixed (were real)

1. Tapping Edit could delete the message. Every Button carries a
pointer-coarse:after:min-w-11 invisible 44px hit area that is not pointer-events-none, so the
four adjacent icon buttons overlapped on touch. Measured against the shipped stylesheet: Edit's
visible box spans x=[52,76] but only [42,68) hit-tests to Edit, and a probe 3px inside its right
edge returns "Remove queued message" — the right third of Edit deletes instead. Fixed with
*:pointer-coarse:after:min-w-auto, the same antidote Group applies to adjacent buttons.

2. Every reorder click destroyed keyboard focus. busy flips synchronously (React commits the
sync lane in a microtask queued before the mutation's), so disabled={busy || !canMoveUp} disabled
the very button just activated, and a disabled element loses focus to <body>. Worse than it sounds:
the action cluster is only revealed on :focus-within, so it also vanished, and the next move needed
a Tab from the top of the document. busy is now guarded inside the handler — matching upstream's own
reorder buttons at ProviderModelsSection.tsx:311 — with focus explicitly restored after the move.

Neither is unit-testable: both live in DOM focus and hit-testing that jsdom does not model.

Filing candidates — fork side

3. The queue holds while the agent is blocked on an approval. phase is still running so a
   submit enqueues, and canSettle refuses to drain because hasPendingApprovals
   (threadSettled.ts:85). The message sits there while the agent waits on you. Most likely to be
   read as "the queue is broken".
4. An edit started after dispatch is discarded silently. The editing hold is only consulted at
   head-selection time (useThreadOutboxDrain.ts:272). Edit after beginDispatchingQueuedMessage
   and the send proceeds, the row unmounts, and updateThreadOutboxMessage returns false — which
   ThreadOutboxQueueList ignores.
5. Stale createdAt defeats the anti-double-send gate. startTurn ships the enqueue-time
   createdAt (useThreadOutboxDrain.ts:224), which the server stores verbatim
   (decider.ts:780-798). Once that becomes latestUserMessageAt, hasQueuedTurnStart's ±2 minute
   window (threadSettled.ts:63) no longer applies, so a message queued offline for longer can be
   dispatched before the previous turn is adopted.
6. Web and mobile now diverge on steering. Mobile still queues mid-turn
   (apps/mobile/src/features/threads/composerSendLabel.ts). Recorded in SEAMS.md, not fixed.

Filing candidates — upstream side

7. isConnecting is permanently false — every guard using it is dead code.
   ChatView.tsx:1283 is const [isConnecting, _setIsConnecting] = useState(false); and the setter
   is never called anywhere in apps/web/src. Verified identical in
   git show upstream/main:apps/web/src/components/ChatView.tsx:1278. It gates the send button's
   disabled state, its spinner, its aria-label, and onSend's guard at :4689 — none of which can
   ever fire. Worth reporting upstream; it is the clearest real bug found in this whole pass and it
   is not the fork's.
8. A refused steer is invisible to the client. providerService.sendTurn is Effect.forkScoped
   (ProviderCommandReactor.ts:1110), so the command has already succeeded when the adapter declines.
   provider.turn.start.failed does exist as an activity but renders as an anonymous entry in the
   timeline. (The reviewer's stronger claim — "the user never sees it" — was refuted: the same
   failure also raises a top-of-chat banner. So this is a polish issue, not a black hole.)
9. Codex's turn/steer RPC is generated and never called. V2TurnSteerParams is right there in
   packages/effect-codex-app-server/src/_generated/schema.gen.ts; grep -rn "turn/steer" over
   apps/server, apps/web and packages/contracts returns zero hits outside the schema. Wiring it
   (and handling activeTurnNotSteerable) would move Codex onto the steer allowlist.
10. No adapter logs distinguish a steer from a new turn. ClaudeAdapter/Cursor/Grok/OpenCode all
    branch on it and none of them log it, so server logs cannot tell you which happened.

Items 3–6 and 8–10 are code-reading results, not runtime-reproduced. 7 is verified by grep.

What to grep when something goes wrong

All client-side outbox logging now shares one prefix, so a single console filter catches everything:

[thread-outbox]

• [thread-outbox] composer dispatch: steer|send|queue — one line per submit, carrying the turn
  phase, connection phase, queue depth, provider and thread id that produced the decision. If a
  message "vanished mid-turn", this says whether it was steered or queued, and why.
• [thread-outbox] reorder failed — a reorder that never reached storage. Previously this rejected
  unhandled and the only symptom was a click that appeared to do nothing.
• [thread-outbox] queued message delivery failed / failed to remove delivered queued message —
  pre-existing drain logging.

Server side, the dev runner logs to stdout; a failed turn start surfaces as a
provider.turn.start.failed activity on the thread and a thread.session.error. There is currently
no server log line that distinguishes a steer from a new turn — that is item 10.

[radroid]

Closing: §0 is answered — steering won, the queue is no longer the primary mid-turn path

Decision on §0: the queue does not survive as the primary way to send into a running turn.
Steering took that role in b9d94d96c. The outbox stays as the fallback for the cases where a
message genuinely cannot go out now — not connected, a non-empty queue, or a driver that cannot
steer — but it is no longer the thing that happens when you type while the agent is working.

Nothing is being reverted, and no commits are being dropped.

• §1 (UI polish) — shipped in 52329956a and 7e7f91ac6. Done.
• §2 (queue images / IndexedDB) — won't do. The storage-migration cost was already judged
  not worth it, and with the queue demoted to a fallback the case is weaker still.
• §3 (send-and-interrupt) — won't do, for the reason found in the second comment above:
  upstream already steers a running turn. Upstream's onSend guard list carries no
  phase === "running" and isSendBusy is activeLocalDispatch !== null, i.e. "a dispatch is
  in flight", not "a turn is running". The outbox was the only thing suppressing it on web, and
  b9d94d96c removed that suppression. There is no separate feature left to build.

Scoping fact recorded here, because it is easy to get wrong

The mobile thread outbox is upstream's, not this fork's:

git ls-tree -r --name-only upstream/main -- apps/mobile/src/state/ | grep -i outbox
# -> all seven thread-outbox*.ts files exist upstream

Upstream's Stack.tsx, NewTaskDraftScreen.tsx, usePendingTaskListActions.ts,
ShowcaseCaptureCoordinator.tsx and new-task-flow-provider.tsx build the offline
pending-task flow on it, and c49b68c7c's own message says "Mobile queueing already worked
end-to-end … the only gap was the keyboard." apps/web/src/outbox/ by contrast does not exist
upstream at all. So anything phrased as "change the queue" is a web-only statement, and the
web/mobile steering divergence cannot be closed by simply porting web's behaviour.

Follow-up

The residue this transition left — four confirmed defects, four open behaviour questions, and
the SEAMS "Parallel paths" row the steering path still needs — is tracked in #40.