Codex subscriptions: when to use steering vs queuing?

[lionello]

[defangdevs]

I checked the code and the live codex CLI. Here is what I found.

Only queuing exists today. The codex delivery peer sends every event with codex queue --thread <id> --message <text> (local-channels local-webhook/webhook.py, added in 0.26.0). This command has one behavior: an idle session gets the message at once. A session that is mid-turn gets the message only when that turn ends.

Steering has no CLI path yet. A code comment above codex_queue() says the app-server protocol has a mid-turn injection method (turn/steer), but codex CLI does not expose it as a command. That note was written against codex-cli 0.149.0. I checked it again today against codex-cli 0.154.0 on this box: codex --help still lists no steer command, and codex queue --help has no flag for it.

So the question has no real choice to make yet. Steering is not reachable from local-webhook at all right now, so there is nothing to pick "steering" over "queuing" for. I filed the mechanism gap upstream: defangdevs/local-channels#58.

Once steering exists, the trade-off will be:

• Queuing is safe. It never interrupts a running turn. A mid-turn event can wait a long time if the turn is long.
• Steering is fast. It reaches the session at once, but it can interrupt work already in progress (a long shell command, an in-flight edit).

I suggest this repo (agent-box) sets the POLICY once local-channels ships the mechanism — for example, steer only for a claimed object's own terminal CI failure, queue for everything else, or make it per-subscription. That policy call needs your input, so I am leaving this open rather than deciding it myself.