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!

[felixwortmann]

Any news on this? Has been half a year and queinig would still be super useful.

[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.

[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

[desphixs]

Do we have queue messages yet?

[nbros]

Can't find it ; looks like it hasn't been implemented yet. We have prompt stashing which is cool, but doesn't fully replace queuing

[grpace]

+1 for adding queue as options. Given that mid-run steering is already supported, the absence of a passive prompt queue stands out. Steering is great when you want to course-correct immediately, but having to babysit a run just to drop "one more thing" without interrupting the current turn creates unnecessary friction.

Is avoiding passive queuing a deliberate product philosophy or is it simply a backlog/UI state issue?

[patroza]

We’ve been using the PR for months, works really well and I wouldn’t do without it

[tiagotheoliveira]

Any news about this?

[nbros]

Also, this is so annoying to have to wait for a compaction before I can send the next message 😠

[nbros]

Also please don't reproduce the issue from Codex where if you close your laptop after queuing messages then they don't send even though the agent is working remotely, and they unexpectedly send hours or days later when you go back to the thread in Codex 🤦🏻
Queued messages on a remote thread should be stored remotely too (but I know t3 code has the best remote implementation so I trust you on this 😉)

[patroza]

@juliusmarminge @t3dotgg @maria-rcks a client side queue is not satisfactory!

[juliusmarminge]

V2 has a server side queue, its coming!

[nbros]

Oh I see it was just merged in T3 Code in PR #11673
But it seems like what was implemented is the way Claude Code does it: queued messages are inserted after the next tool call in the middle of the current turn.
Whereas what I expect from "queuing" is what Codex does instead: the queued message is sent after the end of the whole turn.
Could this be configurable? What do you think?

[nbros]

Yes @patroza as I feared this still appears to reproduce the issue I mentioned: queued messages stay in an in-memory Zustand client store, and a React effect in ChatView dispatches them when a tool call or turn finishes.
With a damning comment from the agent:

t3code/apps/web/src/queuedMessageStore.ts

Line 70 in cc839c4

/** In-memory only: a queued message is a live intent, not a draft worth persisting. */

What do you mean our messages are not worth persisting 😠

So if we close our laptop before dispatch, the React effect won't run and the remote agent kill keep working on the remote machine, but it won't receive the queued messages. They can then send unexpectedly when I return.
Could we send messages to the remote server as soon as they’re queued, and have the server persist and dispatch them independently of the client?
And please don't let the queued messages be lost ; I hate it when I spend time writing a detailed prompt and it just disappears.

This is a separate issue from whether queued message dispatch happens after a tool call or after the turn ends but I would still prefer "after the turn ends" and this could hopefully be configurable if no consensus is reached? 🙏🏻

[nbros]

@juliusmarminge you're too fast you replied before I wrote this message 😅
Thanks for your great work on T3 Code and I'll be waiting for that V2 😉

[grpace]

I would agree I don't want it on the next tool call; I want it to when it's done with the turn.

Codex does this very well.

Steer is immediate.

Queue waits until the model is stopped and then immediately sends (admittedly, sometimes you queue and the model actually ended up already doing what you were queuing up, so it is slight token waste)

I realize there is some nuance here because t3code actually already behaves differently depending on the provider (maybe it’s model-dependent too). I notice using anti-gravity with Gemini 3.8 it just totally stops the response and sends a new one, but with other models it seems to steer. It's never quite clear what I'm going to get depending on what model/provider I'm using. Perhaps a flag or something that says this model supports queuing/steering 'mid-flight' perhaps need some sort of indicator.

Also, I would expect/hope the queued messages to work just like any other prompt does when syncing so if I'm on my phone, I can queue something up on my Linux box, and I see the queue synced between my phone and Linux box, also need ability to drag and drop to reorder what's in the queue and steer others if I can?

[juliomuhlbauer]

Codex way is way better!!!

[chimera74]

Since Queue was implemented it is no longer possible to steer the agent while a subagent is running in this thread. The message is sent only after the subagent has finished.
Bypass queue or disable queue has the same behavior.

My workflow is to ask the session to relay something to subagent mid work. Or I inject messages by a side script notifying about limit expiring so the session and the subagent pauses.
None of the above works.

It was working before.

I am using T3 Code with Claude.
Tested with standalone Claude CLI and the workflow works as intended. It is not a CC issue.