Instruction-State Provenance Across Agent Trees

Short answer

Current instructions and applied instructions are different state. A host may deliberately let a running descendant refresh mutable shared instructions before its next model request, but once an action has been generated, any safety review, approval decision or audit record must stay bound to the exact instruction snapshot that governed that action.

OpenAI Codex PR #46577, merged on 19 September 2026 as e24ac448b37bc6a29e6f2ce8dad61ddaaabf09dc, adds opt-in sharing of a root thread’s instruction provider with running descendants. PR #46580, merged later the same day as ed12cc75d34f7cb5e3b08c8ac0c14e6bc7f67c4f, closes the complementary review race: Guardian now reviews an action against the user/thread instructions captured for that action rather than polling a provider that may already have changed.

These are post-0.155.1 current-main Codex implementation changes. They do not revise UHP, MCP, ACP or A2A wire semantics and do not establish native UHP adoption by Codex.

Live policy and applied policy are different objects

A multi-agent host can legitimately need both live policy propagation and immutable historical provenance. Collapsing them into one mutable object creates a time-of-check/time-of-use problem.

State	Correct semantics
Host instruction provider	Mutable source of the latest host/thread policy
Applied execution snapshot	Instructions actually supplied at one model-request/action boundary
Reviewer snapshot	The same applied snapshot that governed the action being reviewed
Fork or isolated-session state	Explicit inherited snapshot unless that topology separately opts into sharing

The distinction is not merely bookkeeping. If an action is sampled under policy A, the provider advances to policy B, and a reviewer evaluates the action under B, the resulting approval evidence says nothing reliable about whether the action complied with the rules that actually produced it.

Share updates only through an explicit boundary

PR #46577 adds ThreadInstructionsProvider::share_with_subagents(), defaulting to false. When a provider opts in, descendants refresh the shared thread instructions at their next model-request boundary. They do not mutate the instruction context of an action already in progress.

That boundary gives hosts a usable consistency model:

1. the provider may advance independently;
2. a descendant observes the new value before a later model request;
3. that request receives a concrete applied snapshot; and
4. downstream review/audit uses that snapshot even if the provider changes again.

Clearing instructions is a state transition too. The upstream regression coverage exercises initial instructions, replacement instructions and removal, so a consumer cannot treat “no current instruction text” as proof that no prior policy governed an already-generated action.

Tree scope prevents policy bleed

Shared policy also needs an ownership domain. Codex scopes an opted-in provider to one root agent tree rather than making it process-global. The provider can survive a root unload so lazily reloaded descendants continue to receive the intended shared state; a resumed root can replace the provider for its surviving descendants. If the resumed root supplies a non-sharing provider, descendants preserve the last shared instruction state rather than silently acquiring unrelated root-local policy.

The default remains snapshot inheritance. Root forks and isolated sessions keep snapshot semantics, and the sharing contract does not automatically spread one root’s mutable provider into another root tree.

This yields a general invariant:

A live instruction source needs both an explicit sharing policy and an explicit ownership scope.

Without both, a host can accidentally turn local project or session policy into process-global mutable state.

Review the action that actually happened

PR #46580 addresses the second half of the problem. Guardian review previously could obtain inherited instructions from the live parent/provider while preparing the review. If the shared provider advanced after action generation but before review, the reviewer could see different rules from the worker that produced the action.

The merged implementation initializes the reviewer from the captured user and thread instructions in the review-session reuse key. In the new regression scenario, the shared provider is changed or cleared after each action is sampled. The descendant worker picks up the new policy on its next request, while Guardian continues to review each action under the snapshot that applied to that action. Changes in instruction state also create distinct reviewer sessions rather than incorrectly reusing a reviewer whose policy context belongs to another snapshot.

That establishes a broader review/audit rule: review identity should include the policy state that made the action meaningful. A reviewer cache keyed only by agent/thread identity can be unsafe when policy is mutable.

Provenance is stronger than “current configuration”

For durable safety evidence, recording only current configuration is insufficient. A defensible action record should be able to identify the policy snapshot or generation that governed it.

A robust design normally keeps these concepts separate:

• current provider state — what a future request should see;
• applied snapshot — what this request/action did see;
• policy provenance — how that snapshot can be identified later, for example by immutable content, generation or digest;
• review state — which applied snapshot the approval/rejection evaluated;
• tree ownership — which root/session hierarchy may consume the provider;
• refresh point — when a descendant is allowed to observe a newer value.

The exact storage format is implementation-specific. The important requirement is that a later mutable read must not rewrite the historical meaning of an earlier action.

Reloads and long-lived descendants make this harder

Agent trees increasingly outlive one continuously loaded parent process. Children can remain durable while ancestors unload, restart or resume. That makes “read policy from the current parent object” an unreliable ownership model.

PR #46577 explicitly tests provider replacement after root restart, lazy descendant reload, child/grandchild propagation and isolation between roots. The reusable lesson is that durable descendants need deterministic instruction ownership across reload boundaries: either they keep an immutable inherited snapshot or they remain attached to an explicitly shared root-tree provider. Falling through to whichever configuration happens to be loaded later is not a safe third option.

Protocol boundary

This instruction-state behavior is Codex host/runtime policy, not a UHP protocol primitive. UHP can run a harness whose internal agent tree implements live policy sharing without standardizing that provider, its refresh cadence or Guardian-style reviews. MCP and ACP likewise provide interoperability surfaces but do not, through these Codex merges, acquire Codex’s internal instruction-sharing semantics. A2A is unchanged as well.

HarnessRouter remains independently at v0.18.4 / efd320b313891191967871de28ff4757528ae6a7 at this verification cutoff. Nothing in Codex #46577 or #46580 changes the HarnessRouter Codex adapter or establishes new UHP conformance evidence.

Stable upstream Codex remains 0.155.1, published 18 September 2026. The two instruction-state merges are later current-main implementation evidence, not automatically release content. At this review cutoff, upstream Codex main has advanced beyond both merges to 78245b47af2a7aafcabe025828ceecca69db4df1; that later head does not change the instruction-state semantics described here.

Practical review checklist

When reviewing mutable instructions in a multi-agent runtime, verify:

1. Provider and snapshot are separate: mutable current policy cannot overwrite action history.
2. Sharing is opt-in: descendants do not inherit a live provider merely because one exists.
3. Refresh has a boundary: policy changes apply at a defined next-request/turn point, not mid-action.
4. Ownership is scoped: a shared provider belongs to one root tree or another explicit authority domain.
5. Reload behavior is deterministic: descendants preserve either their snapshot or their intended shared provider across unload/resume.
6. Fork semantics are explicit: forks and isolated sessions do not accidentally become live subscribers.
7. Action provenance is durable: the system can identify which instruction state governed an action.
8. Review uses the applied snapshot: approval does not poll mutable policy after the action is generated.
9. Reviewer reuse includes policy state: cached/reused review sessions cannot cross incompatible instruction snapshots.
10. Removal is represented: clearing instructions cannot erase evidence that older actions were governed by earlier rules.
11. Cross-root bleed is blocked: one tree’s policy provider cannot silently affect unrelated agent trees.
12. Protocol claims stay honest: internal instruction propagation is not relabeled as UHP, MCP, ACP or A2A wire behavior.

Primary sources

• OpenAI Codex PR #46577 — share thread instruction providers with subagents
• OpenAI Codex merge e24ac448 — shared instruction propagation
• OpenAI Codex PR #46580 — keep Guardian review on the applied instruction snapshot
• OpenAI Codex merge ed12cc75 — action-bound review instructions
• OpenAI Codex 0.155.1 release
• HarnessRouter v0.18.4