Codex Desktop write thread cannot reliably retrieve exact output from a read-only planning thread, breaking autonomous planner→implementer loops

What version of the Codex App are you using?

Codex Desktop 26.819.11345.

What platform is your computer?

macOS.

What issue are you seeing?

A production-style multi-thread orchestration flow cannot reliably continue autonomously from a read-only Planner thread into a workspace-write implementation thread because the write-side thread cannot retrieve the exact final output of the read-only Planner thread through the supported cross-thread/thread-reader path.

In the reproduced workflow:

1. A dedicated read-only planning thread produced the final implementation plan.
2. A separate workspace-write implementation/orchestrator thread was required to retrieve that exact Planner result unchanged, validate it, persist it, and continue implementation.
3. The write-side thread could not retrieve the exact final Planner result through the supported thread reader.
4. The workflow stopped with an explicit blocker equivalent to:

INSTRUCTION400_EXACT_NONCANONICAL_PLAN_NOT_RETRIEVABLE

1. No product work could continue until the user manually copied the complete Planner output from the read-only thread into the write thread.

This is not a simple UX inconvenience. It breaks unattended / continuous engineering workflows that intentionally separate roles and permissions:

read-only Planner
      ↓ exact result handoff
workspace-write Orchestrator / Implementer
      ↓
implementation → tests → review → next loop

If the downstream write-capable thread cannot programmatically read the exact upstream read-only result, the loop requires manual copy/paste at every permission boundary. That prevents reliable 24/7 autonomous engineering even when both threads belong to the same Codex project and the user has already authorized the workflow.

Why exact retrieval matters

For governed multi-agent workflows, a summary is not sufficient. The downstream thread may need to prove that it consumed the exact upstream result unchanged.

Examples:

• validate a Planner result against a schema;
• compute and compare SHA-256;
• persist the exact plan bytes;
• preserve provenance and auditability;
• avoid reconstructing native/subagent output from prose;
• prevent the implementer from silently rewriting the Planner result before acceptance.

In this reproduction, the write-side thread correctly refused to substitute a summary or reconstruct the missing output. Manual user transfer was the only path forward.

Steps to reproduce

1. Open Codex Desktop on macOS.
2. Create two tasks/threads in the same project:

• Thread A: Read only.
• Thread B: Workspace write.

1. In Thread A, generate a substantial final planning result that Thread B must consume exactly.
2. In Thread B, use the supported cross-thread/thread-reading mechanism to retrieve Thread A's exact final result.
3. Require exact content rather than a summary, because the next step computes a hash or validates a structured contract.
4. Observe that Thread B may be unable to retrieve the exact result even though the user can open Thread A manually and see it.
5. The orchestration blocks until the user manually copy/pastes Thread A's result into Thread B.

Expected behavior

Codex should provide a first-class, permission-safe handoff/read mechanism for exact cross-thread result retrieval within an authorized project/workflow.

At minimum, a downstream authorized thread should be able to retrieve:

source_thread_id
source_turn_id
final_result_bytes_or_exact_text
content_sha256
source_permission_profile
result_status

with clear provenance and no normalization.

A workspace-write consumer does not need write access to the read-only source thread; it only needs read access to the source result.

The mechanism should preserve exact bytes/text so a downstream validator can verify integrity without requiring user copy/paste.

Actual behavior

The result is visible to the user in the read-only source thread, but the downstream workspace-write thread cannot reliably retrieve that exact result through the supported reader/handoff path.

The workflow therefore requires a human to manually bridge the threads.

Impact

This blocks or degrades:

• Planner → Implementer loops;
• Reviewer/Tester → Fixer loops;
• read-only audit → write-side remediation loops;
• role-separated security workflows;
• long-running unattended Codex orchestration;
• 24/7 autonomous engineering loops;
• exact provenance / hash-based governance;
• restart-safe continuation across permission-separated threads.

The problem becomes more severe when permission separation is deliberate. A safe architecture often wants Planner/Reviewer/Tester threads to remain read-only while a separate implementation thread owns writes. Without a reliable exact-result bridge, least-privilege multi-agent design and autonomous continuation conflict with each other.

Suggested product shape

A first-class handoff/receipt API would solve this better than exposing whole thread internals.

For example, when a role finishes, Codex could persist a terminal receipt containing:

producer_thread_id
producer_turn_id
producer_role
producer_permission_profile
result_kind
exact_result
result_sha256
completed_at

The authorized downstream thread could then consume that immutable receipt by ID.

Important properties:

• read-only source threads remain read-only;
• downstream threads get result read access, not source-thread mutation access;
• exact content is preserved byte-for-byte;
• provenance is machine-verifiable;
• restart/resume does not lose the handoff;
• no manual copy/paste is required;
• summaries remain optional convenience, not the only transport.

Relationship to existing issues

I searched for exact duplicates and did not find one.

This is adjacent to, but distinct from:

• #40549 — native Planner permission/result transport issues;
• #40037 — dynamic multi-agent graphs and the need for durable receipts/evidence delivery;
• #32547 — cross-thread messaging/lifecycle safety;
• #33398 — continuation can stop after handoff/context transitions.

This report is specifically about the missing exact, durable, permission-safe cross-thread result retrieval required for autonomous role-separated engineering loops.

Acceptance criteria

1. A read-only Planner thread can finish with a result.
2. A separate workspace-write thread in the same authorized project can fetch that result exactly without user copy/paste.
3. The fetched content is byte/text identical to the source result.
4. A stable result/turn/thread identity is returned.
5. A hash can be verified independently.
6. Reading the result does not grant mutation rights to the source thread.
7. The handoff survives Desktop restart/resume.
8. The same mechanism works for Planner, Reviewer, Tester, and generic subagent outputs.
9. If access is intentionally denied, Codex returns a clear capability/permission error explaining the supported handoff path instead of leaving the orchestrator unable to continue.

No private repository names, prompts, local paths, credentials, customer data, or thread IDs are included in this report.