Give reviewer subagents access to work they are reviewing

Summary

Codex already preserves enough native parent/child metadata and persisted thread history for a spawned reviewer to inspect the exact turn that created it. What appears to be missing is a deliberately narrow way to expose that evidence to the reviewer without also granting broad history access or relying on the parent to identify what should be reviewed.

I prototyped and live-tested a native tool called parent_turn_evidence. The tool is available only to the reviewer role and accepts no thread ID, turn ID, or other locator. Instead, it derives parent_thread_id and parent_turn_id from Codex's own runtime metadata, reads the existing normalized ThreadItem persistence through ThreadStore::list_items, restricts the read to that exact parent turn, and returns a bounded response. It introduces no MCP layer, separate evidence store, or audit ledger.

The prototype passed an end-to-end live test against upstream Codex commit 8d32abcd017d06511b46050cff9dbba8738fc2fa. Upstream main has moved since that test, so I am not claiming live verification against the current head.

Problem

A reviewer subagent is most useful when it can inspect what actually happened rather than relying on an account produced by the agent whose work it is reviewing. Codex has several ways this evidence could be made available, but the obvious approaches all weaken the review boundary in different ways.

The parent could summarize its work or tell the reviewer which thread or turn to inspect, but then the actor being reviewed is also selecting or describing the evidence. A reviewer could instead receive general thread-listing or history-browsing tools, but that gives it substantially more authority than the review requires, including potential access to unrelated threads, sibling agents, previous turns, or broader user history. A third option would be to copy execution evidence into a separate audit store, but that duplicates information Codex already persists and creates another source of truth with its own synchronization and lifecycle problems.

The narrower requirement is therefore:

Give a normally spawned reviewer read-only access to the persisted evidence from exactly the parent turn that spawned it, without allowing either the reviewer or the parent to choose the evidence boundary.

Prototype

The implementation is small. Against the tested upstream revision, it consists of approximately 177 lines for the native handler, 8 lines of reviewer-role registration, 2 lines of handler wiring, and 5 lines of tool-plan registration.

Conceptually, the path is:

parent turn
    |
    | native spawn
    v
reviewer child
    |
    | Codex already knows:
    | parent_thread_id
    | parent_turn_id
    |
    | parent_turn_evidence({})
    v
ThreadStore::list_items(
    parent_thread_id,
    parent_turn_id
)
    |
    v
bounded normalized ThreadItems
from exactly that parent turn

The tool has an empty input schema:

{}

That absence of caller-controlled location data is intentional. There is no supported call such as:

parent_turn_evidence(thread_id=..., turn_id=...)

The reviewer therefore cannot redirect the capability toward another thread or turn; Codex itself determines the evidence boundary from the native parent-child relationship.

Why use the existing ThreadStore

Codex already persists the execution evidence needed for this purpose, so the prototype reads from that existing source rather than introducing another persistence path. It adds no audit database, copied command log, rollout representation, MCP layer, or caller-provided evidence reference.

The intended evidence path remains:

work
  -> normal Codex persistence
  -> constrained reviewer read

rather than:

work
  -> normal Codex persistence
  -> separate audit persistence
  -> synchronization and reconciliation

Besides keeping the implementation smaller, this avoids creating a second record that could eventually disagree with the history Codex already treats as authoritative.

Bounds

The capability is also deliberately bounded. The prototype limits a response to 64 items and 256 KiB of output, so it behaves as a narrow evidentiary aperture rather than a general-purpose history browser.

The decisive current-main live test returned only:

items: 4
output bytes: 1,260

Those limits were not reached, but they establish an explicit ceiling on what the reviewer can retrieve through this capability.

End-to-end result

I exercised one normally spawned reviewer child under an isolated patched build of 8d32abcd017d06511b46050cff9dbba8738fc2fa. The test independently recorded the spawning parent thread and parent turn, executed a known marker command in that turn, and then spawned the reviewer. The reviewer automatically received parent_turn_evidence and invoked it with an empty argument object:

parent_turn_evidence({})

The call returned four normalized items totaling 1,260 bytes. Its threadId exactly matched the actual spawning parent thread, its turnId exactly matched the actual spawning parent turn, and every returned item carried that same parent turn ID. The known PARENT_EVIDENCE_MARKER was recovered from the successful commandExecution, while no item outside the spawning parent turn appeared in the response.

The same implementation path also passed cargo check -p codex-core as well as a focused empty-schema handler test. The experiment used an isolated source checkout; the installed Codex binary and normal user configuration were not modified.

Intended use

This primitive is aimed at reviewer, verifier, or auditor-style subagents whose conclusions should rest on original execution evidence rather than a parent-authored summary. It does not perform the review itself and does not decide whether the parent acted correctly.

Its responsibility is narrower:

trusted runtime binding
        +
existing persisted evidence
        +
exact-turn restriction
        =
bounded factual input

The reviewer model remains responsible for interpreting those facts, applying whatever review criteria govern the task, and returning its judgment to the parent.

Security and authority boundary

The narrow authority is the main reason for proposing a dedicated primitive rather than reusing a general history browser. A reviewer receiving this capability can inspect its direct parent's exact spawning turn, but it cannot use the tool to request another user's thread, an unrelated Codex thread, a sibling agent, an arbitrary historical turn, or even a previous turn from the same parent.

There are simply no locator parameters with which to express those requests. The evidence boundary is established by Codex's own parent-thread and parent-turn metadata rather than by model-supplied identifiers, which makes the restriction structural rather than merely instructional.

Related work

This appears related to #40037, which discusses evidence-driven behavior in dynamic multi-agent graphs, but the proposal here is much narrower. It does not introduce semantic escalation, a supervisor, a fixed review pipeline, or any new orchestration layer.

The proposed change is only a constrained evidence primitive that a reviewer or other verification role can use when the surrounding workflow chooses to perform independent review.

Questions for maintainers

1. Does a reviewer-only, exact-parent-turn evidence primitive fit the intended Multi-Agent V2 architecture?
2. Is there already an intended native surface for exposing exact spawning-turn evidence that I have missed?
3. Should this remain reviewer-role-specific, or is there a more general capability or permission abstraction that would preserve the same narrow authority boundary?
4. Is ThreadStore::list_items combined with native parent_thread_id and parent_turn_id the appropriate source of truth, or is another persisted representation preferred?
5. If this direction is useful, I can provide the small tested patch and the isolated end-to-end test details for maintainer review.

Start with the reviewer-role registration, handler wiring, tool-plan registration, and ThreadStore::list_items path described in the issue. Run cargo check -p codex-core and the focused empty-schema handler test. Done means a reviewer can invoke parent_turn_evidence({}) and receive only bounded items from the exact spawning parent turn, without caller-selected locators.