Expose non-interrupt queued delivery for cross-thread send_message_to_thread
Feature request
Codex Desktop/App already has user-facing Queue vs Steer concepts, but the app/tool surface exposed to agents for cross-thread orchestration appears to only provide send_message_to_thread without an explicit delivery mode.
For parent/worker thread orchestration, we need a way for a worker thread to send a completion notice back to a parent thread without interrupting the parent thread's current turn. The desired behavior is:
delivery: "queued"orinterrupt: falseforsend_message_to_thread/ equivalent cross-thread send- the message is accepted immediately as pending input for the target thread
- it is processed only after the target thread's current active turn completes
- it should not be treated as
turn/steeror an urgent interruption - it should be durable/visible enough that the parent does not need to poll child threads with
read_thread - optionally expose status such as queued, delivered, canceled, failed
Why this matters
A common Codex workflow is a durable parent/router thread with multiple worker threads. Worker completion notices currently have two bad options:
- Use direct
send_message_to_thread, which can interrupt or interleave with the parent thread's active reasoning and muddy decision-making. - Do not send a notice and require the parent to poll/read worker threads, which is easy to miss and makes the workflow stall.
A non-interrupt queued cross-thread send would let workers report completion reliably while preserving the parent thread's current reasoning turn.
Related/adjacent issues found
- #23615 Queue / Steer / Stash UX concepts
- #23100 queued messages not processing until project focus
- #14923 cross-thread orchestration over existing thread/turn primitives
Those are related, but the specific request here is an explicit non-interrupt delivery mode for cross-thread programmatic sends, suitable for agent/worker completion notices.
Suggested API shape
send_message_to_thread({
threadId,
prompt,
delivery: "queued" // or interrupt: false
})
or app-server equivalent:
{
"method": "thread/message/send",
"params": {
"threadId": "...",
"input": [{"type":"text","text":"WORKER_NOTICE ..."}],
"delivery": "queued"
}
}
If an active turn exists, this should enqueue. If no active turn exists, it can start normally or remain queued depending on product semantics, but the delivery mode should be explicit and observable.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗