Automation and Agents

Codex 0.160.0: Check Permission Before an Agent Handoff

Codex 0.160.0 adds two optional Guardian context features. Here is how to reason about a changed permission, a worker handoff and interrupted work.

By Demetri Panici

October 3, 2026

13 min read

A delegated package pauses at a review gate where a later stop instruction supersedes an older approval.

On this page

Two optional ways to supply review context
Follow the instruction through the handoff
What history retrieval checks
What the handoff feature selects
Decide what the available evidence permits
Recovery changes affect the same work differently
A bounded evaluation for a team
Related reading

Imagine an operator asks Codex to prepare a client file and permits a specific send. Before the work reaches another agent, the operator withdraws that permission. The worker later proposes sending the file anyway. Which instruction will the review see?

That sequence is hypothetical. It illustrates a problem described in the merged implementation notes for Codex 0.160.0: a Guardian review may receive a transcript that omits earlier user instructions, restrictions or revoked permissions. OpenAI’s release notes say the version adds optional Guardian capabilities for retrieving earlier user instructions and including context from agent handoffs. The linked changes describe how each capability selects evidence for review. They do not demonstrate what Guardian would decide in this example.

The operator’s decision remains concrete. Before a consequential action proceeds, establish what the user currently permits and what the current parent policy allows. Earlier messages and handoff context can help a review understand how the work arrived there. They cannot turn a withdrawn permission into a current one, and access to history does not itself grant approval.

Follow permission through the handoff. First: a user permits one send. Then: the user withdraws permission. At review: check the proposed send.

Two optional ways to supply review context

The release groups the Guardian additions in one bullet, but the merged changes describe two separate features. The conversation history change describes optional Guardian conversation history tools. The handoff context change describes optional Guardian handoff context. Both are described as disabled by default. A team cannot infer from the release announcement that either flag is enabled in its own Codex setup.

History retrieval addresses an omission in the review transcript. With Apps enabled, it can expose tools for searching and reading earlier user messages through the parent agent’s live Apps connection and conversation identity. That gives a review a way to look beyond the slice of conversation initially supplied to it. It is still a search and read capability with limits, rather than a complete copy of everything the user has ever said.

Handoff context has a different job. It selects root conversation messages around recorded handoffs to a particular worker or its ancestors. The implementation includes messages immediately before those handoffs and recent root messages, which can make a later cancellation visible alongside the worker’s assignment. It is a selection rule for review context, with a shared message cap and fallbacks. It does not claim to reconstruct every message in perfect order.

These mechanisms work at different points in the same question. Handoff selection can put relevant messages in front of a review. History tools can let the review seek earlier user instructions when permitted. Neither makes an old instruction authoritative simply because it was found. The sources describe the implementation and its tests; they do not provide a measured rate at which real reviews catch withdrawn permissions.

Two optional paths to context. History tools can seek earlier messages. Handoff context selects nearby messages. Both features are disabled by default.

Follow the instruction through the handoff

Consider a synthetic sequence with four events. A user first authorizes a narrow action: send a draft file to one named recipient. The user later withdraws that authorization. A worker receives the task through an agent handoff. The worker proposes sending the file. There is no real client, file, send or observed Guardian result in this example.

A review that sees only the first message could mistake the earlier grant for the instruction that governs the proposed send. A review that sees the withdrawal has different evidence. It can recognize that the user changed the permission before the proposed action. Even then, the captured sources do not tell us the exact verdict Guardian would return in this synthetic case. The sources tell us what context may be made available and what policy checks apply to retrieval.

The timeline matters more than a single permission sentence. An operator needs to know what action was authorized, to whom it applied, whether that permission was later changed and which action the worker is now asking to take. A change in any of those details can change the decision. Permission to prepare a draft is not automatically permission to send it. Permission to send one file does not automatically cover another file or recipient. Those are principles for reading the example, not claims about a new Codex interface.

It helps to separate three records that might otherwise blur together. The user’s messages express the instruction and any later withdrawal. The review context determines which of those messages Guardian receives or retrieves. Current parent policy controls whether a history tool call is allowed at the time it is made. Finding an old grant in the second record cannot override a later withdrawal in the first or a current block in the third.

For an agency owner, the practical question is whether a delegated step has enough current authority to proceed with the specific side effect. The answer requires the action and its recipient, along with the applicable instruction, to be clear. A history feature can improve the evidence available to a review. It does not remove the operator’s responsibility to set and maintain the authority boundary.

Keep three records separate. User messages express permission. Review context supplies evidence. Current policy controls tool access.

What history retrieval checks

The history implementation says that, when Apps is enabled, Guardian can use user_message.search_messages and user_message.read_messages through the parent’s live Apps connection and conversation identity. The distinction between search and read matters. A search may identify a relevant earlier instruction; reading can supply its content. A useful review must still interpret the instruction in its sequence, including later changes.

Each call rechecks the parent’s current app and tool policy. Calls to disabled tools and calls that would require approval are rejected. This check applies when the history call happens, including on a reused reviewer whose parent policy has changed. In the synthetic file example, a past grant cannot be used to make a history tool available after current policy has disabled it. The policy check concerns access to the tool. It is not a finding that the proposed file send is approved.

The implementation also describes an estimated default limit of 4,000 tokens for a history response. That setting can be configured, while stricter parent and reviewer limits remain in force. A bounded response is useful for fitting relevant evidence into a review, but it creates an important reading rule: an incomplete result cannot prove that no later instruction exists. A search that does not surface the withdrawal would leave a gap in the evidence available to that review.

Suppose a search finds both the grant and the withdrawal. The operator can see why quoting the grant alone would be misleading. Suppose instead that the result contains only the grant, or the relevant history is unavailable. The absence of the withdrawal from that result is not evidence that the user never withdrew permission. The next responsible step depends on the consequence of the proposed action and what can be checked through the current conversation or the user. The captured sources do not establish a universal Guardian fallback or a guaranteed stop in that situation.

This distinction prevents a subtle error. Retrieval can add evidence to a review; it cannot create a new instruction from the user. The implementation explicitly directs reviews to distinguish user authorization from assistant context, to account for later revocations and to treat incomplete results carefully. Those instructions support a more informed review, while leaving actual authorization with the user’s applicable instruction and current policy.

Check policy at retrieval time. Search and read use the live connection. Each call rechecks parent policy. An incomplete result can miss a change.

What the handoff feature selects

The separate handoff implementation uses recorded spawn_agent, send_message and followup_task calls that target a worker or its ancestors. For each relevant handoff, it selects the three preceding root messages. It also includes the three latest root messages. In a sequence where the user cancels permission late, those recent messages can put the cancellation near the worker’s proposed action.

That is a thoughtful selection rule, but its boundaries matter. The feature retains an existing shared message cap. It also falls back to existing root context when no usable handoff window remains or when the latest authorization message is a heartbeat. The implementation preserves verified tool answers and evidence without known ordering. These details show why the feature is more precise than simply attaching a generic conversation excerpt, while stopping short of a claim that it always supplies the entire authorization history.

Return to the synthetic example. If a recorded handoff follows the withdrawal, the selected messages may make the new instruction visible. If the withdrawal falls outside the selected windows or the cap, the review may need other evidence. If the relevant handoff record is no longer usable, fallback context applies. These are possibilities drawn from the selection rules, not observed outcomes from a product test.

The useful comparison is by job, rather than by which feature sounds broader. Handoff context chooses messages likely to explain why this worker has this work. History tools provide a route to seek earlier user messages when the current connection and policy permit it. A team evaluating the release should ask whether the context for its own handoffs contains the instruction changes that matter for the actions it delegates. The captured PRs do not establish that a particular account exposes those review details for inspection.

The selected window is bounded. Three root messages before a handoff. Three latest root messages as well. The existing shared cap still applies.

Decide what the available evidence permits

An operator can reason through three possible evidence states without pretending to know Guardian’s verdict. First, the later withdrawal is visible. The earlier grant must then be read in light of the later message. Before a send, the operator should establish whether any subsequent instruction restored permission for that specific action. The captured sources provide no such later instruction in our hypothetical example.

Second, the relevant history is unavailable or incomplete. Here the evidence does not settle whether the earlier grant remains current. For a consequential send, a fresh check with the user or a narrower action such as preparing an unsent draft may be appropriate. This is Rise’s proposed operating judgment, not a documented Codex rule. The important point is to avoid treating a search gap as renewed authorization.

Third, current parent policy blocks a history call. The implementation says that call is rejected. The operator cannot reason from the fact that the tool existed earlier to a right to use it now. The remaining review must work with the context it has, seek an allowed way to resolve the instruction or stop before the consequential action. Again, the captured sources do not specify the verdict Guardian will reach for this example.

The same criteria should be used in all three cases: identify the proposed action, identify the relevant current user instruction, check current policy and state what evidence is missing. A review can be informed by more context and still lack enough context for a particular decision. Treating that limit plainly is more useful than an unconditional claim that the new features make agent work safe.

This is also where the human decision has practical value. Client work can involve a recipient, a document version or a commitment that changes after a task starts. An agent may be good at carrying work forward while those conditions change. The operator needs a way to keep the permission attached to the actual action being proposed. The release provides additional review mechanisms for that problem; it does not establish a substitute for the user’s current approval.

Three evidence states, three checks. Withdrawal visible: read later changes. History incomplete: resolve the gap. Policy blocks access: respect the block.

Recovery changes affect the same work differently

The Codex 0.160.0 release notes also describe session changes. They say sessions can start outside a project with workspace defaults when policy permits, and saved permissions are restored when a session resumes. They also say unsent queued messages resume after reconnection once uncertain submissions are resolved, with avoiding duplicate sends given as the reason. These are OpenAI’s release statements. No resumed session or queued message was tested for this article.

Imagine a separate synthetic interruption. An operator queues a request to revise a draft, then loses the connection. On return, the operator does not know whether that request was submitted. Blindly entering it again could create duplicate work or a second consequential instruction. The release says its queue handling waits for uncertain submissions to be resolved before unsent input resumes. That is relevant to the operator’s uncertainty, though the captured note does not show what a specific screen displays after reconnecting.

The restored-permissions statement raises a related question: which permissions are present in the resumed session? The release supports the fact of restoration as described, but the captured text does not explain its full scope or a user-facing inspection path. A team should verify those details in its own permitted environment before relying on them for consequential work. Starting a session outside a project is likewise conditional on policy and workspace defaults, not a universal promise that any setup can do so.

Recovery and Guardian context solve different parts of a long-running task. Recovery concerns continuity after an interruption. Guardian history and handoff context concern what evidence reaches a review when work is delegated. An operator may need to inspect both before repeating a request or allowing a later action. Neither release note proves that a client-facing workflow has completed correctly.

Resolve submission before retrying. Reconnection can leave uncertainty. An unsent request is not a known send. Resolve state before issuing it again.

A bounded evaluation for a team

A team considering the update can start with configuration and access questions. Is Codex 0.160.0 the version in the environment being evaluated? Are the two Guardian flags available and enabled there? Is Apps enabled for history retrieval, and does current parent policy allow the relevant tools? The captured release and PRs describe capabilities and conditions, but they do not answer those questions for a particular account.

Next, define one synthetic action whose permission can change. For example, allow a worker to prepare a sample file, then withdraw permission to send it before a handoff. Stop before any real send. If the environment exposes review context, inspect whether the grant, withdrawal and handoff are visible to the review. Record which messages can actually be seen. If review context is not inspectable, record that limit rather than announcing a successful authorization check.

A separate recovery exercise could interrupt a harmless queued request and inspect what appears after reconnection. Record whether the session shows the expected permissions and whether the request is pending, submitted or unresolved. The captured release supplies a reason to ask these questions, but it does not supply the interface steps or expected observations for this team. Any exercise remains proposed until someone performs it and records what happened.

For real delegated work, the team can carry forward a simple decision rule: make the action and permission specific, preserve later changes to the instruction and check current authority before the side effect. If the review has incomplete history, describe exactly what it lacks. If a policy check blocks access, respect that result. If reconnection leaves submission state uncertain, resolve that uncertainty before issuing the same instruction again. These are operating choices based on the documented mechanisms, not measured claims about time saved or errors prevented.

When permission changes before a handoff, establish the user’s applicable instruction for the proposed action, then use available Guardian context as evidence for that review. Keep the record specific enough that another person can distinguish preparing the sample file from sending it. The first step may still be allowed even when the second has been withdrawn. If a reviewer can see only the preparation request, that record is incomplete for deciding whether to send.

The useful result of a proposed evaluation is a clear account of what was visible, what remained missing and what the team decided to do next. A blocked history request should be recorded as blocked, not as an empty conversation. An unavailable handoff view should be recorded as unavailable, not as proof that no restriction existed. Keep a separate note of current permission before repeating an uncertain request or allowing a consequential action. These are proposed recordkeeping practices. Account-specific access and actual review outcomes still need to be established in the environment being used.