Desktop task API: ephemeral read-only fork through an exact completed turn

What variant of Codex are you using?

App (Codex Desktop on macOS), with Codex CLI/app-server 0.146.0 used for an isolated synthetic acceptance harness.

What feature would you like to see?

Expose one supported Codex Desktop task-interface operation for consulting a read-only snapshot of a busy task's completed context.

The operation should atomically:

• require a source task ID and an exact completed turn ID;
• reject an in-progress turn ID and never infer the current turn;
• create a confirmed ephemeral fork that is excluded from stored task listings;
• enforce read-only execution with deny-by-default MCP and dynamic tools;
• return source-task and completed-turn attribution separately from the answer;
• never message, resume, steer, interrupt, acknowledge, or otherwise mutate the source task;
• make the fork unloadable after the consultation or host restart; and
• prevent the fork from becoming a competing mutation-capable writer.

The intended use is context-only consultation. If the original task must receive, act, decide, or acknowledge, the caller should use normal messaging instead.

Additional information

The raw app-server protocol already exposes the underlying primitives (thread/fork.lastTurnId, ephemeral: true, and read-only turns), but the existing Desktop task interface does not expose that complete control set as one safe operation.

Body-free synthetic evidence from an isolated temporary profile:

• 20/20 consecutive authenticated fresh-process happy-path trials passed with zero invariant violations.
• The source had one exact completed snapshot turn and one separate in-progress turn.
• Forking the in-progress turn was rejected; forking the selected completed turn succeeded.
• The fork returned the synthetic marker with source-task, completed-turn, and non-impersonation attribution.
• The source retained the same active turn and received no consultation message.
• Ephemeral forks were absent from listings and unloadable after app-server restart.
• Two concurrent consultations left the source unchanged.
• Timeout and app-server termination left no retained fork and did not interrupt the source.
• A direct app-server read-only sandbox probe denied a harness-owned sentinel write and left the sentinel unchanged.
• MCP inventory remained zero, and all disposable task, state, and authentication profiles were removed.

This proves the protocol workflow only when one isolated app-server owns both the synthetic source and fork. It does not prove safe consultation of arbitrary Desktop-owned tasks, and no real Desktop task was used in the test.

Non-goals: delegation, delivery, acknowledgement, agent impersonation, moderator automation, or adoption of arbitrary already-running sessions through a second mutation-capable control plane.