Agents API adds auto review: Migrate running sessions safely

OpenAI's October 31, 2026 SDK update adds support for Agents API session review settings and tool replacement. The current API exposes review: "auto_review", letting the managed harness review eligible actions automatically. Teams adopting it need to account for work already running.

A successful settings update leaves earlier turns on their existing review mode. Functions and MCP servers can change sooner than that mode does. Treat rollout as a change to running workloads, with an owner responsible for old turns and pending actions. The examples below use the documented beta API contract; we have not exercised the feature in a live integration.

Check when each change takes effect#

The session update reference defines separate boundaries:

The tools array is a replacement. Omit it to preserve the current tools; null or an empty array clears it. When changing the list, send the complete reviewed set you intend to retain.

The broader configuration guide still says tools cannot be updated through this endpoint. That conflicts with the newer endpoint reference and SDK change. Follow the specific reference for the request shape, and verify tool replacement in your pilot before depending on it.

Consider a hypothetical support session investigating a billing issue. Its first turn started without automatic review. While it works, an administrator enables review and adds an account-write function. At the next model call, the function can become available while that turn retains its earlier review mode. Our recommendation is to avoid adding authority during this transition: finish or stop the earlier work, verify the configuration, then admit a new root turn.

Enable review without accidentally replacing tools#

The create-session reference says omitted review defaults to none. It describes auto_review as reviewing eligible actions and denying manual approval fallbacks. Do not build a workflow that assumes every rejected action will pause for a person to approve it.

For an existing pilot session, the following example changes only review and reads the session back. Supply its identifier and API key through your approved environment setup. Run this after coordinating the migration described below. It is an adapted request example, not a tested rollout script; it neither stops active work nor proves which actions the reviewer covers.

Code source: OpenAI session update reference and session retrieval guidance.

Expect the final check to print true and exit successfully. An HTTP failure, missing field, wrong session ID, or different review value leaves the check failed. Keep the response files in a restricted evidence directory: session configuration can contain sensitive instructions and tool details. Use a fresh directory for each attempt so a later run cannot overwrite earlier evidence.

A matching response establishes the stored setting. It does not attest to the policy of each earlier turn or show that a particular command received review.

Move existing sessions through a controlled transition#

Use one application owner to coordinate admission and configuration for each session. The following is our recommended migration procedure, derived from the timing contract above:

1. Pause new application input and queued job dispatch for the session. Save the intended policy revision, session ID, current configuration, and outstanding work in your application store.
2. Identify existing root turns, delegated work, and pending function calls. Let authorized work finish, or request cancellation when continuing under the old policy is unacceptable. Reconcile external effects separately.
3. Apply the review update and any deliberately prepared tool replacement. Retrieve the session and compare the result with the intended configuration. Keep admission paused on an error or mismatch.
4. Start new work only after the earlier execution has been accounted for. Record the new root turn's identity with the configuration revision, then inspect its actual tool outcomes.

Sending another message is insufficient to establish that boundary. OpenAI's session guide says input steers the current turn while the agent is working; it starts a new turn when idle. A message saying "use the new policy" can therefore continue the older turn.

The same guide documents active-turn cancellation through agent.session.input.cancel. Save the terminal outcome and investigate anything already dispatched. A cancellation request cannot establish that an external account write was undone. For compute ownership, reconnection, and separate provider cleanup, use the Agents API sandbox lifecycle guide.

Reauthorize delayed function calls where they execute#

An account-write request may already be waiting in an application queue when the session's tools change. OpenAI's function-tool documentation puts execution in your handler and identifies pending calls with a session, turn_id, and call_id. Attaching a sandbox does not move that handler into it.

At dispatch, have the handler check the current application policy, authenticated account scope, exact arguments, and any required human approval. In the billing example, removing the function from the model's next tool list must not be the only control preventing a queued account change. Reject obsolete authority at the service that would perform the write.

Keep this check independent of conversational claims about permission. If your policy requires a named person to approve an account change, retain that approval outside the model's judgment. The broader coding-agent security baseline covers restricting credentials and reachable resources around these decisions.

For recovery, the function guide recommends storing results durably and returning an already completed call's saved result. If execution may have succeeded but no result was retained, inspect the destination before running it again. Use current required_actions to identify pending calls; a historical call record alone does not establish that execution is still requested.

Require evidence of useful work after a denial#

Before rollout, define what a completed application job must produce. A billing investigation might require a report for the intended account and a successful read from its approved data source. If review blocks that read, a plausible summary is insufficient.

OpenAI's turn-outcome guidance warns that a completed turn does not mean every tool succeeded. Retain the required operation's result alongside the final response. Recover saved turns and items through the events documentation after a stream disconnect rather than inferring success from the last text received.

Use synthetic records and harmless tools in a pilot. These are proposed acceptance checks, not results we measured:

• Verify explicit review on a newly created session, and verify that an omitted setting is detected by your admission check.
• Change a pilot session while an earlier turn exists. Confirm that your controller accounts for that turn before releasing new work.
• Queue a dummy function call, revoke its application permission, and confirm that its handler refuses the effect even if the request remains queued.
• Make a required operation fail or be denied. Confirm that your application records incomplete work rather than accepting an unsupported success message.

The reviewed API references do not enumerate every eligible action or promise a per-action review receipt. Record the surfaces your pilot actually establishes and keep unknown coverage explicit. Enable unattended work only when the operator can connect the intended policy, the relevant turn, and the downstream result.