The prompt queue

Open the Queue tab in the utility drawer while a session is mid-turn and write your next message. It sits there. Nothing is sent until either you send it or an automatic-delivery rule you turned on decides to.

Head-of-line means the queue delivers in order and one at a time: the second message does not overtake the first because the first is waiting on something.

This is the single most important default on this page. A queued message waits for you. If you queue three messages and expect them to flow, nothing will happen, and that is the design rather than a fault.

When you do turn it on, it is per conversation, and it does not wait for a binary done signal, because no such signal exists that is reliable across vendors. It waits for a readiness gate and then a stability window: the session has to be ready, and it has to have stayed ready. A state that just changed and a state that has settled are different facts, and only the second is safe to act on.

• Per-conversation default and overrideAutomatic delivery is decided per conversation, so one long-running worker can flow while everything else waits.
• Quiet hoursA window where nothing is delivered automatically, for the case where you want the agent to have work waiting when you wake up rather than to have burned through it at 3am.
• Emergency pauseOne switch that stops all automatic delivery immediately, across every conversation.
• Per-item expiryA message can be given a deadline after which it is dropped rather than delivered late into a context it no longer fits.
• Consecutive-send capA limit on how many messages can be delivered in a row without evidence that the agent replied to any of them, so a wedged session cannot be fed the whole queue.

All of these are in Settings, Prompt queue, under Auto-delivery. The shipped defaults are the conservative ones.

One session can put a message into another session's queue. The floor is stated in one sentence: a non-human sender's write ends at a human. An unsolicited message from an agent is staged for you to approve, not delivered.

There are exactly two ways past that floor, and both are the receiver's authorization rather than the sender's claim. The receiving session can hold a standing grant to accept agent messages, or the message can answer a request that receiving session itself made. Answering a question somebody asked is narrower than the floor rather than an erosion of it, and the narrowing stays exactly as wide as the request: the requester alone, a fixed template, the run that asked, a cap, and it ends with the authority that accepted the request.

Arming is still not delivery. A message that is allowed to be armed still goes through the same readiness gate and stability window as one you armed yourself.

The application-wide view of who wrote what to whom: every staged message, its sender, and its state. It is a modal rather than a drawer tab, because it has no send button - it is where you watch, and the Queue tab is where you act.

A message can be staged against a session that does not exist yet. Spawning binds it on the first run, which is how a scheduled run or a spawn request arrives with its instructions already attached rather than needing a second act to deliver them.

Cron, interval, or one-off. A schedule is a deferred press of a button you could have pressed yourself, so it goes through the ordinary spawn path, the ordinary resume path, and the ordinary prompt queue, and grows no second authority anywhere.

Definitions stay on the machine rather than in the repository, because a schedule committed to a repository would arm itself in every clone and every worktree. The Schedule drawer tab is where they live.