feat: add Steer and Queue follow-up modes alongside Chat/Plan

[Fanzzzd]

Right now T3 Code appears to only model default and plan interaction modes. I’d like to request support for Steer and Queue style follow-up behavior while a run is already active.

Why

When the agent is already working, users often want two different behaviors:

• Steer: inject immediate guidance into the active run
• Queue: save the follow-up so it runs after the current work settles

This is a meaningful UX distinction and avoids forcing users into interrupt-or-wait behavior only.

Settings ask

It would be even better if this can be configured in Settings, for example:

• default follow-up behavior while a run is active
• whether the composer shows Steer / Queue explicitly
• an optional shortcut for sending the non-default behavior once

Suggested acceptance criteria

• The composer exposes both follow-up modes when a run is active.
• The selected mode is visible and predictable.
• Users can configure the default active-run follow-up behavior in Settings.
• Queued follow-ups survive reconnects/reloads.
• Steering a run does not silently discard already queued follow-ups.

Relevant code context

• packages/contracts/src/orchestration.ts
• apps/web/src/components/ChatView.tsx
• apps/server/src/orchestration/Layers/ProviderCommandReactor.ts

Reference implementation ideas

• CodexMonitor already exposes configurable follow-up behavior with Queue vs Steer while a run is active.

[MatejSkarka]

+1 for this, for sure for "Steer". This is very usefull function in Codex.

[CanRau]

@MatejSkarka You can already steer by just adding messages, so basically only queueing is missing with clear UI, from my understanding

[juliusmarminge]

yes it's all steer now. we'll add queinig!

[aashishsingla567]

+1 Queue is very important

[FleetAdmiralJakob]

This is a big one and super important for me

[SOUMITRO-SAHA]

PRD: Steer & Queue Interaction Model

1. Objective

To transition the interaction model from a synchronous "wait-and-reply" system to an asynchronous "task-pipeline" system. This allows users to stack instructions while a run is active and selectively "promote" urgent guidance to the active run (Steering).

2. Current State Analysis

2.1 Existing Flow (Synchronous)

The current implementation follows a strict synchronous message flow:

[User sends message]
       ↓
ThreadTurnStartCommand dispatched
       ↓
┌─────────────────────────────────────┐
│  thread.message-sent event          │  ← User message stored
│  thread.turn-start-requested event  │  ← AI turn starts immediately
└─────────────────────────────────────┘
       ↓
Provider session activated (Codex app-server)
       ↓
[AI processes and responds]
       ↓
thread.turn-diff-complete event
       ↓
[Session returns to idle state]

Key Characteristics:

• No buffering: Messages dispatch immediately, triggering a new turn.
• Blocking behavior: While session.status === "running", users must wait or interrupt.
• Destructive interrupt: ThreadTurnInterruptCommand stops the current turn entirely.

2.2 Current Schemas (Relevant Excerpts)

// OrchestrationThread - current structure
const OrchestrationThread = Schema.Struct({
  id: Schema.String,
  projectId: Schema.String,
  title: Schema.String.pipe(Schema.optional),
  model: Schema.String.pipe(Schema.optional),
  runtimeMode: RuntimeMode,
  interactionMode: ProviderInteractionMode,
  branch: Schema.String.pipe(Schema.optional),
  worktreePath: Schema.String.pipe(Schema.optional),
  latestTurn: OrchestrationLatestTurn.pipe(Schema.optional),
  messages: Schema.Array(OrchestrationMessage),
  proposedPlans: Schema.Array(OrchestrationProposedPlan),
  activities: Schema.Array(OrchestrationThreadActivity),
  checkpoints: Schema.Array(OrchestrationCheckpointSummary),
  session: OrchestrationSession.pipe(Schema.optional),
  // ... timestamps
});

// OrchestrationSession - tracks active provider state
const OrchestrationSession = Schema.Struct({
  threadId: Schema.String,
  status: OrchestrationSessionStatus, // "idle" | "running" | "error"
  providerName: Schema.String.pipe(Schema.optional),
  runtimeMode: RuntimeMode,
  activeTurnId: Schema.String.pipe(Schema.optional),
  lastError: Schema.String.pipe(Schema.optional),
  updatedAt: Schema.String,
});

// OrchestrationLatestTurn - turn lifecycle state
const OrchestrationLatestTurn = Schema.Struct({
  turnId: Schema.String,
  state: OrchestrationLatestTurnState, // "requested" | "running" | "completed"
  requestedAt: Schema.String,
  startedAt: Schema.String.pipe(Schema.optional),
  completedAt: Schema.String.pipe(Schema.optional),
  assistantMessageId: Schema.String.pipe(Schema.optional),
});

2.3 Existing Commands

Command	Purpose	Behavior
ThreadTurnStartCommand	Send message + start turn	Creates message-sent and turn-start-requested events synchronously
ThreadTurnInterruptCommand	Stop active turn	Emits turn-interrupt-requested, terminates provider session
ThreadSessionStopCommand	Stop session	Emits session-stop-requested

3. User Problems

• Context Loss: Users think of a fix while the AI is mid-generation but have to wait to type it, often forgetting the nuance.
• Interruption Friction: "Interrupting" a run feels destructive. "Queuing" feels constructive.
• Visibility: Current systems don't show the user what is "pending," leading to duplicate prompts.
• Workflow Disruption: Users lose momentum when forced to wait for completion.

4. Proposed Features & Logic

4.1 The Follow-Up Queue

• Any message sent while session.status === "running" is automatically pushed to a Follow-Up Queue.
• Queue Limit: Maximum of 10 queued items per thread. Attempts to add beyond this limit are rejected with a user-friendly error.
• The AI finishes Turn A, then automatically pops the next item from the queue and starts Turn B.

                    ┌─────────────────────────────────┐
                    │   session.status === "running"  │
                    └─────────────────────────────────┘
                                   │
                    ┌──────────────┴──────────────┐
                    ▼                             ▼
           [User sends message]          [Turn completes]
                    │                             │
                    ▼                             ▼
        ┌───────────────────────┐      ┌─────────────────────┐
        │ queuedFollowUps.push()│      │ Check queue length  │
        │ (if < 10 items)       │      │                     │
        └───────────────────────┘      └──────────┬──────────┘
                                                  │
                                   ┌──────────────┴──────────────┐
                                   ▼                             ▼
                          [Queue empty]                  [Queue has items]
                                   │                             │
                                   ▼                             ▼
                          [Session → idle]             [Dequeue first item]
                                                                 │
                                                                 ▼
                                                       [Auto-start next turn]

4.2 The "Steer" Promotion

• Each item in the queue has a "Promote to Steer" action.
• Action: Injects the message directly into the current turn context without stopping file-writing.
• Implementation: Uses ThreadTurnSteerCommand (new) to send mid-turn guidance.
• Note: Steer is only available when provider supports mid-turn injection (Codex supports this via send_turn with a running session).

4.3 Queue Operations

Operation	Command	Event Emitted	Behavior
Queue item	ThreadFollowUpQueueCommand	thread.follow-up-queued	Appends to queuedFollowUps if < 10 items
Dequeue item	ThreadFollowUpDequeueCommand	thread.follow-up-dequeued	Removes from queue (FIFO or by index)
Steer item	ThreadTurnSteerCommand	thread.turn-steered	Injects into active turn, removes from queue

4.4 Settings Integration

// New settings schema
const FollowUpModeSettings = Schema.Struct({
  followUpMode: Schema.Literal("queue", "steer"), // Default: "queue"
  showFollowUpModeInComposer: Schema.Boolean, // Default: true
});

• followUpMode: Determines default behavior when sending during active turn.
  • "queue": Add to queue (default)
  • "steer": Immediately inject into active turn
• showFollowUpModeInComposer: Toggle UI indicator in composer footer.

---

5. UI/UX Design

The UI sits directly above the Composer to indicate "input-ready" but "pending-execution."

5.1 UI Layout Example

----------------------------------------------------------------------
[ QUEUE ]  3 pending                            ( ⚡ Steer All ) [⌘⇧↵]
----------------------------------------------------------------------
[ 1 ] Refactor the CSS to use Tailwind vars...       [⚡]  [⌘⇧1] [ x ]
[ 2 ] Also check the types in orchestration.ts...    [⚡]  [⌘⇧2] [ x ]
[ 3 ] Add unit tests for the decider...              [⚡]  [⌘⇧3] [ x ]
----------------------------------------------------------------------
[ Queue limit: 3/10 ]                                                ]
----------------------------------------------------------------------
[ ⌨️ Type a follow-up or instruction...                              ]
----------------------------------------------------------------------

5.2 Composer Footer States

┌────────────────────────────────────────────────────────────────────┐
│  [Queue: 3 pending] [Mode: Queue ▾]      │  ⚡ Steer All (⌘⇧↵)     │
└───────────────────────────────────────────────────────────────────-┘

When session idle:
┌─────────────────────────────────────────────────────────────────────┐
│  [Ready] [Mode: Queue ▾]                                            │
└─────────────────────────────────────────────────────────────────────┘

When queue full (10 items):
┌─────────────────────────────────────────────────────────────────────┐
│  [Queue Full: 10/10] [Mode: Queue ▾]                                │
└─────────────────────────────────────────────────────────────────────┘

5.3 Component Breakdown

Element	Function	Shortcut
Queue Item	Displays truncated preview of pending prompt	N/A
Steer Button (⚡)	Injects that specific prompt into the active run	Cmd + Shift + [Index]
Steer All	Merges all queue items and sends as a single steer update	Cmd + Shift + Enter
Cancel (x)	Removes item from queue	N/A
Mode Selector	Switches between Queue and Steer modes	N/A

---

6. Technical Requirements

6.1 Schema Changes (packages/contracts/src/orchestration.ts)

// Add to OrchestrationThread
const OrchestrationQueuedFollowUp = Schema.Struct({
  id: Schema.String,
  message: Schema.Struct({
    text: Schema.String,
    attachments: Schema.Array(ChatAttachment).pipe(Schema.optional),
  }),
  queuedAt: Schema.String,
  mode: Schema.Literal("queue", "steer"),
});

// Updated OrchestrationThread
const OrchestrationThread = Schema.Struct({
  // ... existing fields ...
  queuedFollowUps: Schema.Array(OrchestrationQueuedFollowUp), // NEW
});

// New Commands
const ThreadFollowUpQueueCommand = Schema.Struct({
  type: Schema.Literal("thread.follow-up.queue"),
  commandId: Schema.String,
  threadId: Schema.String,
  message: Schema.Struct({
    text: Schema.String,
    attachments: Schema.Array(ChatAttachment).pipe(Schema.optional),
  }),
  mode: Schema.Literal("queue", "steer").pipe(Schema.optional),
  createdAt: Schema.String,
});

const ThreadFollowUpDequeueCommand = Schema.Struct({
  type: Schema.Literal("thread.follow-up.dequeue"),
  commandId: Schema.String,
  threadId: Schema.String,
  followUpId: Schema.String.pipe(Schema.optional), // If omitted, dequeues first (FIFO)
  createdAt: Schema.String,
});

const ThreadTurnSteerCommand = Schema.Struct({
  type: Schema.Literal("thread.turn.steer"),
  commandId: Schema.String,
  threadId: Schema.String,
  turnId: Schema.String,
  message: Schema.Struct({
    text: Schema.String,
    attachments: Schema.Array(ChatAttachment).pipe(Schema.optional),
  }),
  createdAt: Schema.String,
});

// New Events
const ThreadFollowUpQueuedPayload = Schema.Struct({
  threadId: Schema.String,
  followUp: OrchestrationQueuedFollowUp,
});

const ThreadFollowUpDequeuedPayload = Schema.Struct({
  threadId: Schema.String,
  followUpId: Schema.String,
});

const ThreadTurnSteeredPayload = Schema.Struct({
  threadId: Schema.String,
  turnId: Schema.String,
  followUpId: Schema.String.pipe(Schema.optional),
  messageText: Schema.String,
});

6.2 Queue Limits (Constants)

// packages/contracts/src/orchestration.ts
export const MAX_QUEUED_FOLLOW_UPS = 10;

6.3 Server-Side Implementation (apps/server/src/orchestration/decider.ts)

New command handlers in decideOrchestrationCommand:

1. thread.follow-up.queue

   • Validate queuedFollowUps.length < MAX_QUEUED_FOLLOW_UPS
   • If limit reached, return error event
   • Otherwise, emit thread.follow-up-queued event

2. thread.follow-up.dequeue

   • Validate follow-up exists
   • Emit thread.follow-up-dequeued event

3. thread.turn.steer

   • Validate session is running
   • Emit thread.turn-steered event
   • Remove from queue if followUpId provided

6.4 Reactor Logic (apps/server/src/orchestration/Layers/ProviderCommandReactor.ts)

On thread.turn-diff-complete event:

// After turn completion, check for queued follow-ups
if (readModel.threads.find((t) => t.id === threadId)?.queuedFollowUps.length > 0) {
  // Dequeue first item
  const nextFollowUp = thread.queuedFollowUps[0];

  // Dispatch ThreadTurnStartCommand with the queued message
  await dispatchCommand({
    type: "thread.turn-start",
    threadId,
    message: {
      messageId: generateId(),
      role: "user",
      text: nextFollowUp.message.text,
      attachments: nextFollowUp.message.attachments,
    },
    // ... other fields
  });
}

6.5 Frontend State Management (apps/web/src)

// apps/web/src/state/threadStore.ts
interface ThreadState {
  // ... existing fields
  queuedFollowUps: OrchestrationQueuedFollowUp[];
}

// Selectors
const selectQueuedFollowUps = (threadId: string) => (state) =>
  state.threads[threadId]?.queuedFollowUps ?? [];

const selectQueueCount = (threadId: string) => (state) =>
  state.threads[threadId]?.queuedFollowUps.length ?? 0;

const selectCanQueue = (threadId: string) => (state) =>
  (state.threads[threadId]?.queuedFollowUps.length ?? 0) < 10;

6.6 WebSocket Integration

Queue operations use the existing dispatchCommand RPC method:

// Client dispatches
ws.dispatchCommand({
  type: "thread.follow-up.queue",
  threadId: "thread-123",
  message: { text: "Also fix the tests" },
});

// Server pushes domain events
ws.push("orchestration.domainEvent", {
  type: "thread.follow-up-queued",
  payload: { threadId: "thread-123", followUp: {...} },
});

---

7. Persistence & Recovery

7.1 Event Sourcing

• queuedFollowUps is derived from thread.follow-up-queued and thread.follow-up-dequeued events.
• Queue state survives:
  • Browser refresh (via WebSocket resync)
  • Server restart (via event replay)
  • Page navigation (via global state)

7.2 Thread Snapshot

• queuedFollowUps included in OrchestrationReadModel snapshot.
• On WebSocket reconnect, client receives full snapshot via getSnapshot RPC.

---

8. Acceptance Criteria

8.1 Core Functionality

• Sending a message while session.status === "running" adds it to queuedFollowUps instead of blocking.
• Queue rejects additions when at 10 items, showing user-friendly error.
• Queue indicator displays correct count (e.g., "Queue: 3/10").
• When a turn completes, the first queued item is automatically dequeued and processed.
• "Steer" button injects message into active turn without interrupting.
• "Steer All" merges all queued items into single steer command.
• Deleting a queue item removes it from both state and UI.

8.2 State Synchronization

• Queue state persists across browser refresh.
• Queue state syncs on WebSocket reconnect.
• Queue state survives server restart (via event store).

8.3 Keyboard Shortcuts

• Enter (while running): Add to queue.
• Cmd + Enter (while running): Force steer (bypass queue).
• Cmd + Shift + Enter: Steer all queued items.
• Cmd + Shift + 1-9: Steer specific queue item by index.

8.4 Error Handling

• Attempting to queue beyond 10 items shows: "Queue is full (10/10). Please wait for items to process."
• Attempting to steer when session is not running shows: "Cannot steer: no active turn."
• Network errors during queue operations show retry option.

[SOUMITRO-SAHA]

Hi @juliusmarminge @maria-rcks ,

I have written a short PRD for this task and shared my thoughts on how the feature could be implemented. Could you please review it and let me know what you think?

If the proposal looks good to you, I would be happy to take ownership of the implementation. Please feel free to assign this task to me.

[ranvier2d2]

Hi @SOUMITRO-SAHA

I'm not a maintainer, but I did implement and validate a local version of this flow, and found a few semantics that may be worth making explicit in the PRD:

1. A queued follow-up should remain only in the queue UI while pending, and should not be inserted into the chat timeline until drain dispatch actually begins.
2. queuedAt and dispatch time should be treated differently. I hit a real ordering bug where a drained queued message rendered above assistant output that had actually occurred earlier because the optimistic message reused the original enqueue timestamp.
3. Failed local drain dispatches likely need explicit rollback semantics. If the client dequeues an item, inserts an optimistic user message, and local thread.turn.start dispatch fails before server acceptance, the optimistic message should be removed and the queued item restored to the front of the queue.

I only caught this in real-browser validation, so I’m attaching a couple of short GIFs in case they help make the interaction clearer:

Queued item stays pending, then appears only after drain.

Queue default + immediate "Send now" override in the same run.

Not trying to push a different architecture, just sharing a few implementation details that turned out to matter a lot for the UI.

[cafeai]

+1 for queue support please...
i typically queue a significant amount of things up when i know i'll be away from the computer

[tiagonrodrigues]

+1! Is this WIP?

[felixsebastian]

"/btw" would also be sickkk

[cafeai]

I ended up making my own fork here: https://github.com/cafeai/cafe-code

Not trying to compete with T3 Code at all — I just wanted something more minimal for my own use, and wanted to be able to fix the bugs I was hitting quickly.

Really appreciate all the work the T3 team has put into the project so far.

[davidvornholt]

Any plans for implementing a queue?

[ralfboltshauser]

not being able to queue is currently preventing me from moving to t3 code from codex.

also one big thing to me for queuing is how it behaves with remote hosts:

• when i have connected a remote t3 instance, and I queue a message I need this to be managed on the remote host, if it's managed on my control host it's effectively useless, because I try to queue lots of messages and then shut down my host, if the queued messages stay on my host it defeats that use case.

[ranvier2d2]

Hello Julius. I’m working on a unified implementation for queued follow-ups so the behavior works consistently across providers.

I’ve tried to reuse the existing orchestration/projection paths and keep the feature contained, though the final diff will still be non-trivial because it includes provider coverage and tests. I also reused existing UI elements where possible and kept the layout constrained to the composer width for mobile/resizing. I think the shape is in a good place now; I’m doing a bit more dogfooding across providers before opening the PR.

[juliusmarminge]

#2829 has server managed queueing (so it works on remote hosts even if u close the client connnection etc)

[ranvier2d2]

Thanks, that makes sense. I took a closer look at #2829 and noticed it already models the queue/steer UX contract: normal send can steer an active run, Cmd/Ctrl+Enter can queue, queued work is server-managed, and queued items can be reordered/promoted to steer.

Would it be useful if I opened a smaller current-main PR that backports that #2829 queue/steer behavior without depending on the full Orchestrator V2 branch?

I would align it with #2829 rather than introduce a competing UX direction. If you prefer waiting for #2829 instead, I can hold off and switch to dogfooding/reviewing that path.

[jcoulaud]

hi! any update on this pr?
would def love to have a steer/queue feature.
this is still the only blocker for me to use t3 code.

[davidvornholt]

Yes, I think this is an essential feature too. Any updates?

[DevDominic]

Definitely something I'd love to see. Sometimes I like to queue multiple follow ups for longer prompts if I know I'm going to be AFK and there is just no way of doing that currently. Would be greatly appreciated :)

[archasek]

This is the feature that's blocking me from switchign to t3 from codex

[sprintthunder-dotcom]

Mobile: allow users to review and edit queued messages

On the T3 Code mobile view, after I queue a follow-up while the agent is working, I can only see:

“1 queued message will send automatically.”

I cannot review what I queued or correct it before it is automatically sent.

Could this queue notice be tappable and open a compact queue panel or bottom sheet?

Suggested actions:

• View the full text of each queued message
• Edit a queued message before it is sent
• Delete or cancel a queued message
• Reorder multiple queued messages
• Optionally promote a message to Send now / Steer

This is especially important on mobile, where typing errors, voice-input mistakes, and accidental submissions are more common. A queued instruction can significantly change a long-running coding task, so users should have a chance to verify it before automatic dispatch.

Minimum useful version: tapping the queued-message notice shows the pending message and provides Edit and Delete actions.

This is a mobile UX follow-up to the Queue/Steer work discussed in this issue.

[karthikcsq]

Definitely need this feature!

[fionn77]

Adding a native Android use case in support of this request:

In the official T3 Code Android app on a Google Pixel 7a, a follow-up prompt sent while the model is working is currently queued. I would like an explicit way to Steer the active run immediately while keeping Queue available as the alternative.

This is especially useful when I notice that the model has misunderstood a detail or is heading in the wrong direction: I want to correct it without stopping the turn, waiting for completion, or starting over. A clearly visible Steer/Queue choice in the native composer would make the behavior predictable.

Thanks for working on this. I would be happy to test the Android implementation.

[ElliotDrel]

I would strongly prefer this to follow the native Codex Queue/Steer UX as closely as possible, with cross-platform queue state treated as a first-class requirement.

Desired interaction model

While the agent is already working, every new message should have two explicit delivery choices:

• Queue: hold the message and send it automatically after the current turn finishes.
• Steer: inject the message into the active turn immediately.

Settings should let the user choose which behavior is the default. My preferred default is Queue. The normal Send action should use that default, while a modifier key, alternate keyboard shortcut, button hold/long-press, or send-menu action should perform the opposite behavior for that one message.

This should work consistently with mouse, keyboard, touch, and mobile interactions rather than being limited to a desktop-only hover control.

Match the Codex queue UI

When messages are queued, show every pending message clearly in the conversation/composer area, in execution order. For each queued message, provide an obvious Send now action that immediately promotes that specific message from queued to Steer, matching the behavior of sending it immediately in Codex.

The user should always be able to tell:

• which messages are queued;
• their execution order;
• which message will run next;
• whether a message was queued or steered;
• whether an action is still pending, currently being sent, failed, or completed.

Queued messages should not disappear into an opaque count or work log.

Cross-platform synchronization

The queue must belong to the thread/session on the T3 server, not to the client where the message was composed.

For example, I should be able to:

1. Queue messages from the Windows desktop app.
2. Open the same thread on my phone or another computer.
3. Immediately see the same queued messages in the same order.
4. Send one immediately, add another, or remove one from that other client.
5. See those changes reflected on every open client as close to real time as possible.

Queue mutations should be authoritative and ordered so simultaneous clients cannot duplicate, lose, or reorder messages. Closing or refreshing the originating client must not remove queued messages or prevent them from executing.

Additional acceptance criteria

• The default Queue/Steer preference is synced across the user's T3 clients, or its sync scope is made explicit.
• One-off overrides are available through both a discoverable UI control and a configurable keyboard shortcut.
• A queued item's Send now action atomically removes it from the queue and sends it as a Steer, without creating a duplicate later.
• Queue additions, removals, promotions, execution, and failures propagate live across desktop, web, and mobile.
• Reconnects receive the authoritative current queue and reconcile any locally stale state.

The existing technical direction in this issue is strong; the key product requirement for me is that the result feels like the Codex implementation rather than merely exposing two backend commands.

[lumberman]

Status check for anyone landing here from search: as of main @ 5d76653 none of this is implemented, and the one platform that did queue no longer does.

Mobile's queue-while-busy behavior was removed. PR #6543 ("fix(mobile): steer active turns by default", merged 2026-08-14) dropped the busy guard from the outbox delivery resolver:

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

It also deleted the post-await re-check that deferred delivery when the thread had gone busy. threadBusy is still computed by the caller (apps/mobile/src/state/use-thread-outbox-drain.ts:317) and passed into resolveThreadOutboxDeliveryAction, where nothing reads it — a dead parameter is all that's left of the queue semantics. So the "{n} queued messages will send…" notice in ThreadComposer.tsx is now an offline outbox: while connected, a mid-turn send goes out immediately and the server treats it as a steer.

That directly answers @fionn77's and @sprintthunder-dotcom's reports above — the Android behavior they described as "queued" was real, and it was removed two weeks later in favor of desktop parity (#7234). The net effect is that Queue now exists on zero platforms, which is the opposite of the "cross-platform queue state as a first-class requirement" @ElliotDrel asked for.

Desktop has only ever steered. apps/web/src/components/ChatView.logic.ts:645-651:

if (input.phase === "running") {
  // Steering adds a user message to the current running turn without
  // necessarily changing any of the turn timestamps.

And the surrounding contract surface is empty: no followUp/steer/queue key in packages/contracts/src/settings.ts (so no "default follow-up behavior" setting), and packages/contracts/src/keybindings.ts exposes composer.stash with nothing queue-related (so no "send the non-default behavior once" shortcut). I also grepped the renderer bundle out of app.asar on the 0.0.33 release — no Steer/Queue UI strings at all.

The prompt stash isn't a substitute. It's genuinely useful and it's what I'm using today, but it's manual hold-and-resend from a drawer — nothing drains it when the turn settles, which is the whole point of Queue. It's also localStorage-backed with a per-image base64 budget, so it isn't a durable place to park work.

Why steer-only hurts in practice. Mid-turn the only choices are interrupt or steer, and neither is right for a strictly sequential follow-up ("then run the tests") — steering makes the agent context-switch mid-task instead of finishing. Steering also still has live sharp edges: #2573 (opencode: steering breaks session tracking and Stop stops working afterwards).

The acceptance criteria in the original post still read exactly right, and #6885 is the same ask with 11 upvotes. Is this on the roadmap, or is steer-only the intended long-term model? If it's the latter, saying so would at least stop people rediscovering the mobile regression and filing it as a bug.

[Wilsman]

can we queue messages yet?

[xibn]

Nope, but Julius seems to be actively working on it, the last commit was around 5 hours ago: 9ebcbee