Desktop app: explicit cross-thread orchestration over existing thread/* and turn/* primitives

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #13641

Powered by Codex Action

like claude channels

I want to add a concrete Windows Desktop use case that strongly matches this feature request.

I am trying to use Codex Desktop as a project-level orchestration environment:

• one persistent project thread acts as an orchestrator;
• the orchestrator breaks a larger task into smaller worker tasks;
• worker chats are durable project threads, not just temporary subagents;
• the orchestrator should be able to create or reuse worker threads, send them assignments, observe completion, and continue with the next step;
• the user should not have to manually copy/paste prompts between the orchestrator and worker chats.

Right now I am prototyping this through a local external watcher/queue around codex app-server primitives (thread/list, thread/resume, turn/start, thread/turns/list, etc.). It works well enough to prove the concept, but it is a workaround. The user has to build a local watcher, assignment files, lifecycle markers, a Rainmeter status widget, and manual handoff conventions just to make durable project-thread orchestration possible.

What I would like to see natively in Codex Desktop is an explicit project-level orchestration mode, for example:

• mark one thread as a project orchestrator;
• let it create/reuse worker threads inside the same project;
• let it assign tasks to up to N worker threads with clear permissions and audit trail;
• show assignments, active workers, completed workers, and blocked/attention states in the UI;
• allow the orchestrator to continue automatically after workers finish, without the human acting as a relay;
• keep all cross-thread actions explicit, visible, and permission-gated.

For my current workflow this would remove the need for a fragile external queue/watcher layer and make long-running project automation much more natural.

Related issue from this same experiment: Desktop currently appears to refresh app-server-updated worker threads only when the Windows Desktop window receives focus: #21177. That refresh issue is separate, but it becomes more visible when trying to build cross-thread orchestration on top of the existing app-server primitives.

Adding a concrete use case in support of this feature request: the important distinction is not just “more subagents,” but main-agent-to-main-agent communication across persistent sessions.

In active multi-repo or multi-workstream setups, users often keep separate long-lived Codex threads as durable “main agents” for different domains, repos, or authority lanes. Those threads accumulate context, local decisions, tool history, and their own operating posture. A spawned subagent is useful for bounded delegation, but it is not equivalent to asking another already-running main agent for a cross-check or handoff because the other main agent has persistent session context and may be the actual owner of that lane.

Desired capability:

• Let one main Codex thread message another existing main thread/session by explicit thread/session id or UI selection.
• Preserve both threads as durable peer sessions, rather than converting one into a subordinate subagent.
• Require explicit user-visible permission/gating before cross-thread reads or writes.
• Record an audit trail in both source and target threads: who asked, what was sent, what was returned, and whether the target thread acted or only advised.
• Support request/response patterns such as “ask thread B to review this plan,” “ask thread C for current repo state,” or “send this approved prompt to the repo-local head agent thread.”
• Allow target threads to decline, report blockers, or answer read-only without mutating their workspace.

Why it matters:

Persistent peer-thread feedback loops are a strong safety and quality pattern. They let one main agent check another main agent’s assumptions without flattening everything into a single overloaded thread or losing continuity by spawning a fresh subagent. This is especially useful when each main thread owns a different repo, worktree, policy lane, or long-running execution context.

A good mental model might be:

• Subagents = bounded child delegation inside one parent thread.
• Cross-thread messaging = explicit, auditable peer coordination between durable main-agent sessions.

I would strongly prefer this to remain opt-in and permissioned, but first-class once enabled.

Adding one more concrete workflow detail from the motivating use case:

Right now, multi-thread orchestration is possible only through a manual copy/paste loop:

1. A persistent head-agent thread finishes a repo/domain lane and emits a closeout summary.
2. The user manually pastes that summary into an orchestrator/main-agent thread.
3. The orchestrator interprets the state and writes the next prompt.
4. The user manually pastes that prompt back into the head-agent thread.
5. The pattern repeats, often across several persistent head-agent threads.

The requested feature would replace that with explicit cross-thread main-agent messaging:

1. A head-agent thread can message the orchestrator thread directly when it reaches a blocker, closeout, or handoff point.
2. The orchestrator thread can reply directly with the next approved prompt, a blocker, or a request for more evidence.
3. The orchestrator can coordinate multiple durable head-agent threads in parallel.
4. Each participating thread keeps its own persistent history, workspace context, authority lane, and audit trail.

This is materially different from subagents. Subagents are bounded child delegations created by a parent. The desired workflow is peer coordination between durable main-agent sessions that already exist and may each own a long-running domain/repo context.

Possible feature name: Cross-Thread Main Agent Messaging.

Important requirements:

• Message another persistent Codex thread/session by thread id or user-selected thread reference.
• Preserve both threads’ histories and authority boundaries.
• Require explicit user permission, allowlisting, or per-message confirmation.
• Record auditable sent/received message entries in both source and target threads.
• Support request/response handoff, status reporting, prompt delivery, review requests, blocker escalation, and completion callbacks.
• Allow one orchestrator/main-agent thread to coordinate multiple persistent head-agent threads.
• Keep this separate from ephemeral subagent spawning so peer sessions do not lose their durable identity or accumulated context.

The main goal is to remove the user from being the manual clipboard transport between persistent main-agent sessions while keeping the coordination explicit, permissioned, and inspectable.

Request: add a low-payload read mode for cross-thread orchestration.

Current read_thread can be much heavier than manual copy/paste when the caller only needs the target thread's final answer. In one Desktop case, a last-turn read with outputs disabled returned ~10k visible tokens, while the useful final assistant response was ~650 tokens.

Suggested shape:

• read_thread(threadId, turnLimit=1, view=latest_final)
• or read_thread_latest_response(threadId)
• exclude progress events, duplicated prompt/delegation input, file changes, tool calls, and metadata by default
• return only: thread id, turn id, status, timestamp, final assistant text

Priority: high. Cross-thread orchestration is much less useful if agent-side reads cost 10x-20x more context than manual copy/paste.

_Footnote: drafted by ChatGPT/Codex, directed and reviewed by Miguel before posting._

Request: expose explicit delivery semantics for send_message_to_thread.

I see app-server/TUI queue work in issues/PRs such as #23620 and #25258. The missing piece here is the model-callable cross-thread tool surface: an orchestrator agent needs to know whether it is queuing, steering, interrupting, or being rejected because the target thread is busy.

Suggested shape:

• deliveryMode: queue | steer | interrupt | fail_if_busy
• safe default: queue or fail_if_busy
• response reports: queued, started, steered, interrupted, or rejected
• include target thread id, busy/idle state, and created turn id when applicable

Priority: high. Durable peer-thread workflows need predictable delivery, not ambiguous message injection.

_Footnote: drafted by ChatGPT/Codex, directed and reviewed by Miguel before posting._

the main-agent-to-main-agent distinction @winnal draws is the one that matters. subagents-inside-a-thread is a different problem from two long-lived peers coordinating, and the user-as-manual-relay loop is the thing that actually eats the time.

for the CLI side of this i built repowire, where each session gets a mesh address and they ask/ack/notify/broadcast to each other. @migsferro's point about delivery semantics is spot on, the asks carry explicit outcomes (delivered, queued, blocked) rather than fire-and-forget, because did-the-other-agent-actually-get-this turns out to be the whole game.

honest caveat: repowire is daemon/mesh-centric across CLI sessions, not native to codex desktops thread/* primitives. so for your desktop case a built-in send_message_to_thread with real delivery semantics would be strictly better. but if anyone lands here needing main-to-main across CLI sessions today, the pattern works.

the main-agent-to-main-agent distinction @winnal draws is the one that matters. subagents-inside-a-thread is a different problem from two long-lived peers coordinating, and the user-as-manual-relay loop is the thing that actually eats the time. for the CLI side of this i built repowire, where each session gets a mesh address and they ask/ack/notify/broadcast to each other. @migsferro's point about delivery semantics is spot on, the asks carry explicit outcomes (delivered, queued, blocked) rather than fire-and-forget, because did-the-other-agent-actually-get-this turns out to be the whole game. honest caveat: repowire is daemon/mesh-centric across CLI sessions, not native to codex desktops thread/* primitives. so for your desktop case a built-in send_message_to_thread with real delivery semantics would be strictly better. but if anyone lands here needing main-to-main across CLI sessions today, the pattern works.

dude, Codex ALREADY implemented the idea. there is thread management on Codex now, you can send messages from one thread to another now. stop trying to promote your own repo when Codex already implemented the feature.

@winnal damn. thanks i didnt know. it simplifies repowires architecture then.

@winnal wait, do threads work in an active TUI controlled session? or are they for programmatic delegation?

@winnal wait, do threads work in an active TUI controlled session? or are they for programmatic delegation?

yes. it's pretty much exactly what i asked for. it's one of the best features they've added for agentic workflows tbh. you can easily find the docs on it how it works to answer your question. but it basically directly addresses what i spoke about. i posted a separate issue about it and marked it as complete since they released the feature: https://github.com/openai/codex/issues/22768

This proposal maps closely to LS work on trajectory continuity, verified shared state, and governed multi-agent coordination.

A useful distinction may be:

message delivered
≠ statement verified
≠ state accepted
≠ action authorized

Cross-thread orchestration needs more than a messaging API. The receiving thread should be able to determine:

• which thread and agent produced the message;
• which task trajectory it belongs to;
• whether it is a proposal, observation, verified result, or command;
• which evidence supports it;
• whether it supersedes earlier state;
• whether the sender is allowed to request the proposed action.

A possible event envelope:

{
"schema_version": "cross-thread-event/v0.1",
"event_id": "evt-2026-001",
"trajectory_id": "project:migration",
"continuation_id": "thread-infra-04",
"source": {
"thread_id": "thread-infra",
"agent_id": "agent-infra",
"role": "infrastructure"
},
"target": {
"thread_id": "thread-application"
},
"event_type": "STATE_UPDATE",
"subject": "deployment.endpoint",
"payload": {
"value": "https://new-endpoint.example"
},
"evidence_refs": [
"tool-event:health-check-883",
"artifact:deployment-report"
],
"verification_status": "VERIFIED",
"authority": {
"may_inform": true,
"may_request_action": true,
"may_authorize_execution": false
}
}

The receiving thread should process it through explicit stages:

receive
→ authenticate source
→ validate trajectory and scope
→ inspect evidence
→ detect stale or conflicting state
→ accept / reject / defer
→ propose local action
→ normal approval and execution path

The core invariant would be:

«Cross-thread communication may inform reasoning, but it must not silently bypass the receiving thread’s approval, sandbox, or execution policy.»

A second invariant:

«Durable peer threads should exchange typed events, not only unstructured prose that can be mistaken for verified state.»

This could support the requested operations safely:

• "list_threads"
• "read_thread"
• "send_message_to_thread"
• "fork_thread"
• "create_thread"
• "archive_thread"

with per-operation capability checks.

For example:

{
"capability": "send_message_to_thread",
"source_thread": "thread-A",
"target_thread": "thread-B",
"allowed_event_types": [
"QUESTION",
"STATE_UPDATE",
"RESULT"
],
"requires_target_consent": true,
"expires_at": "2026-06-25T00:00:00Z"
}

A deterministic conformance suite could test:

1. orchestration disabled by default;
2. thread A cannot read thread B without granted capability;
3. a message appears in both source and target audit trails;
4. unverified state update does not release a dependent task;
5. stale event cannot overwrite a newer verified value;
6. replayed duplicate event is idempotent;
7. sender may request an action but cannot authorize execution;
8. model, reasoning, sandbox, and approval overrides remain visible and attributable;
9. archived or revoked thread cannot continue sending events;
10. resumed thread preserves trajectory identity and event history.

Related LS work:

• recovered-evidence continuation:

https://github.com/safal207/LS/pull/651

• causal audit:

https://github.com/safal207/LS/issues/594

• evidence gates:

https://github.com/safal207/LS/issues/595

• deterministic replay:

https://github.com/safal207/LS/issues/597

Would a small vendor-neutral "CrossThreadEvent" conformance fixture help separate messaging, verified shared state, capability checks, and execution authorization?

Strong support for this request. This would solve one of the biggest friction points in my current Codex workflow.

For larger projects, I intentionally create a new Codex thread for each implementation task. This keeps every worker thread focused, prevents unrelated context from accumulating, reduces compaction pressure, and avoids the reliability problems that often appear when one conversation becomes extremely large.

At the same time, I keep one separate thread dedicated to project architecture, planning, and coordination.

My current workflow looks like this:

1. The architecture thread defines and scopes the next task.
2. I manually copy the implementation prompt into a new worker thread.
3. I wait for the worker thread to finish.
4. I copy its final report back into the architecture thread.
5. The architecture thread reviews the reported work and decides whether the task is complete or whether another follow-up prompt is required.
6. I manually return to the worker thread and send the next instruction.

This manual relay breaks the flow and makes me the communication layer between agents.

A handoff file does not fully solve the problem. Handoffs are useful, but they usually contain only a compressed representation of the previous work. Keeping every task in one giant thread is also not a good alternative, because the context becomes increasingly noisy, heavily compacted, and less reliable.

What I would like is an opt-in “Project Supervisor” or “Architect Thread” capability.

The supervisor thread should be able to:

• View the existing threads associated with the current project.
• See whether each thread is running, waiting, blocked, or completed.
• Read a worker thread’s latest result and completion report.
• Send a new instruction to an existing thread.
• Wait for that thread to finish without requiring the user to manually switch chats.
• Review the result, tests, diff, and reported limitations.
• Send corrective follow-up instructions when the task is incomplete.
• Mark the task as accepted or completed.
• Detach or archive the worker thread when it is no longer needed.

Each worker thread should still preserve its own isolated context, working directory, worktree, instructions, permissions, and conversation history.

Cross-thread activity should also be clearly visible and auditable. Both chats should show when the supervisor sent an instruction, when the worker responded, and whether the action was initiated by the user or by another Codex thread.

This is not only about parallel agents. It is about durable project coordination while preserving clean and focused contexts.

Codex already works well when individual tasks are carefully scoped. A persistent architect thread that can coordinate those independent task threads would make the entire workflow much smoother and would significantly reduce manual context switching.

Contention-safe coordination contract and acceptance cases

I can add evidence from a fail-closed multi-thread Git ownership workflow. In one bounded pre-instrumentation sample, 54 legacy reservation-wait observations were measurable, but those events could not reliably distinguish retries from distinct waits, identify the exact holder acquisition, separate blocked time from post-release handoff time, or prove whether the changed paths actually overlapped.

A minimal synthetic reproduction is:

1. Thread A holds resource scope S under acquisition A.
2. Thread B requires S, records one wait episode W, and sends an advisory request to A.
3. B retries while A is active; retries must update W, not create new waits.
4. A releases A; B later acquires S under acquisition B.
5. Audit must correlate the advisory delivery, authoritative release of A, and authoritative acquisition B, while measuring blocked time only through availability and handoff time separately.

A compact packet could look like:

{
  "schema": "codex-thread-coordination-v1",
  "packet_id": "opaque-id",
  "kind": "contention_request",
  "source_thread_id": "opaque-thread-id",
  "target_thread_id": "opaque-thread-id",
  "wait_id": "opaque-wait-id",
  "resource_key": "opaque-resource-key",
  "holder_acquisition_id": "opaque-acquisition-id",
  "originating_event_id": "opaque-event-id",
  "requested_action": "checkpoint_and_release_when_safe",
  "delivery_status": "pending|delivered|unavailable|archived",
  "authoritative_release_event_id": null,
  "authoritative_acquisition_event_id": null
}

The authority boundary matters: cross-thread packets should be advisory only. Delivery must never grant write authority or imply release; the external/local resource coordinator remains authoritative. An unavailable or archived target should produce a terminal delivery result with durable guidance so the source thread cannot wait indefinitely.

Suggested acceptance scenarios:

• Redelivering the same packet_id is idempotent.
• Retries update one wait episode rather than inflating contention counts.
• An unavailable or archived target returns a terminal, auditable result.
• Release and later acquisition can be linked to the exact holder acquisition and wait episode.
• Delivery is visible to both source and target threads with explicit permission gating.
• A delivered packet cannot bypass or weaken an external ownership lock.
• The contract need not retain prompt or task body content; opaque identifiers and lifecycle events are sufficient.

This would make native cross-thread orchestration useful for contention management without turning Codex itself into an implicit lock authority.

Persistent list/read/send/fork/archive primitives and cross-thread messaging have shipped.