codex - 💡(How to fix) Fix Simple cross-thread messaging by thread ID

Feature request

Add a minimal way for one persistent Codex thread/session to send a plain message to another persistent Codex thread/session by thread ID.

This is intentionally much simpler than a full cross-thread orchestration framework. The core request is basically: let Codex threads text each other, with user-visible permission and auditability.

Motivating workflow

Some users run multiple long-lived Codex main-agent threads at the same time, for example:

• one orchestrator/meta thread;
• one persistent head-agent thread per repo or domain;
• separate threads that each preserve their own context, history, authority lane, and local working state.

Right now coordination requires a manual copy/paste loop:

1. A head-agent thread finishes work and emits a status/closeout summary.
2. The user manually copies that summary into the orchestrator thread.
3. The orchestrator thread writes the next prompt or handoff.
4. The user manually copies that prompt back into the head-agent thread.
5. This repeats across multiple long-running threads.

This is tedious, error-prone, and makes the user act as clipboard transport between agents.

Real-world usage pattern

This is not hypothetical. I am currently coordinating several persistent Codex head-agent threads plus one orchestrator thread.

Example shape:

• Head thread A owns repo/domain A.
• Head thread B owns repo/domain B.
• Head thread C owns repo/domain C.
• Orchestrator thread owns roadmap sequencing, checkpoint review, and next-prompt generation.

Today I manually copy/paste closeouts from each head thread into the orchestrator, then copy/paste the orchestrator's next prompt back to each head thread. This works extremely well as a coordination pattern, but the user becomes the message bus.

The desired primitive would preserve the exact same turn structure while removing manual clipboard transport.

Evented turn model

The desired behavior should not require long-lived turns, wait loops, or autonomous continue behavior.

A safer model is evented cross-thread prompting:

1. A head-agent thread finishes its work and sends its closeout both to the user and to an orchestrator thread.
2. The head-agent turn ends normally.
3. The orchestrator thread receives that closeout as a normal incoming prompt, evaluates the checkpoint, sends back a bounded next prompt, and ends its turn.
4. The head-agent thread receives that reply as a normal incoming prompt, starts a fresh turn, and continues.

So the primitive is not "an agent keeps running and waits for another agent." It is "one stopped persistent thread can receive a message from another persistent thread, exactly like a user prompt."

This enables safer feedback loops than blind continue automation: each step is visible, auditable, bounded, interruptible, and separately permissioned. It also allows one orchestrator thread to coordinate multiple persistent head-agent threads without collapsing them into subagents or background jobs.

Proposed MVP

Expose a simple capability along the lines of:

message_thread(thread_id, body)

Expected behavior:

• The user provides or approves a target thread/session ID.
• The current thread sends a plain text message to that target thread.
• The target thread receives it as a normal incoming message, clearly labeled as coming from another Codex thread.
• Both source and target threads show an auditable record of the sent/received message.
• The target thread can answer normally, ignore it, or ask the user for confirmation before acting.

Optional MVP-plus behavior:

• Let the user authorize the agent to list/search currently active Codex threads and select one.
• Provide stable thread labels/names so users do not need to manage opaque IDs manually.

MVP acceptance criteria

A minimal successful version would allow:

• Thread A sends a message to Thread B by ID.
• Thread B receives it as a normal visible incoming prompt.
• Thread A's turn can end immediately after sending.
• Thread B's next turn starts only when it receives the message, same as a user prompt.
• Both threads show the message in their logs.
• The user can see who sent what to whom.
• No workspace mutation or hidden execution permission is implied.
• One orchestrator thread can receive messages from multiple head threads and reply to each independently.

Non-goals for the MVP

This request is not asking for:

• a full orchestration engine;
• automatic control over another thread;
• hidden autonomous messaging;
• automatic context merging;
• shared memory across threads;
• replacing subagents;
• changing another thread's workspace or execution state by default;
• long-lived background turns that wait for another thread;
• blind autonomous continue loops.

Receiving a message should not imply permission to mutate files, run commands, or continue a plan. It is just an incoming user-visible message from another persistent thread.

Why subagents do not solve this

Subagents are useful for bounded delegation from a parent. This workflow is different: the target is another durable main-agent session that already exists and has its own accumulated context, state, and authority boundary.

The desired primitive is peer messaging between persistent main-agent sessions, not spawning a temporary child worker.

Safety / permission model

A minimal safe model could be:

• The user must provide the target thread ID, or explicitly authorize thread search/selection.
• Messages are visible in both threads.
• The receiving thread treats the message like an external incoming message, not as hidden control input.
• The receiving thread still follows its own current permissions, workspace state, and user approvals.
• Cross-thread messages can be disabled, allowlisted, or confirmed per send.

Summary

Please add a simple, explicit, auditable cross-thread message primitive so persistent Codex main-agent threads can communicate directly when the user wants them to, without requiring manual copy/paste between sessions. The user should not have to be the message bus.