Wait for a Terminal to Finish
Queue a prompt that sends itself when another agent's turn ends — chain several dependencies, watch the queue in Mission Control, and cancel without losing what you wrote.
Running two agents usually means being the message bus between them. You write the follow-up, then sit watching a spinner so you can paste it the moment the first agent stops.
A passive wait removes you from that loop. You state the dependency in front of your prompt, and 1DevTool holds the prompt until that terminal's turn has really ended — then sends it.
Turn orchestration on
Passive waits live behind orchestration. With it enabled, Agent Input reads a dependency written in front of your prompt instead of sending straight away.
Write the dependency, then the work
wait for terminal 3 to finish, then implement the findings
The prompt is armed as a pending wait rather than delivered. Nothing is sent upstream while it waits — the agent you are waiting on is never nudged, never asked whether it is done, never has its context disturbed by a check-in. 1DevTool listens to the completion signal the agent itself emits and does nothing until it fires.
That is the difference between a passive wait and a polling script. A script has to touch the thing it is measuring; this does not.
Chain several dependencies
A follow-up can wait on more than one terminal, which is what you want when two agents are working different halves of the same change:
wait for terminal a and terminal b to finish, then run the integration checks
The prompt goes out once every dependency has finished, not on the first one home.
You can also address a dependency by its Codex or Claude session id, when exactly one open terminal owns that session — useful when you are thinking in terms of the conversation rather than the pane.
Watch the queue in Mission Control
Pending waits are visible, not implied. Mission Control lists each one with:
- what it is waiting on
- a Cancel wait button
- Copy original prompt, so cancelling does not throw away the text you wrote
What a wait refuses
Waits refuse the cases that cannot mean anything, so you get told rather than getting a queue that silently never drains:
- a terminal waiting on itself
- a duplicate of a wait you already armed
- cycles, where two prompts each wait on the other
Lifetime
Waits are bounded and held in memory by the main process:
- They survive pane remounts and project switches — moving around the app does not drop the queue you built.
- They do not survive a restart. That is deliberate: a stale prompt firing into a session that has moved on is worse than no prompt at all.
- An uncertain delivery is never retried.