Apply access-control changes to the currently running turn #32612

What variant of Codex are you using?

App

What feature would you like to see?

When the access-control or permissions setting is changed while an agent turn is already running, Codex should apply the new setting to that active turn rather than waiting until the next user turn.

At the moment, the UI allows the user to change the access-control mode during an active run, but the running agent continues using the permission context with which the turn originally started. The new setting only becomes effective when another user message starts the next turn.

Additional information

Current behavior

1. Start an agent turn with a restricted access mode, such as read-only or workspace access.
2. While the agent is still running, change the access-control setting to Full Access.
3. The UI immediately shows the newly selected mode.
4. The active agent nevertheless continues using the old access restrictions.
5. The new setting only takes effect after the current turn finishes and the user sends another message.

The reverse direction appears to behave similarly: lowering access during an active turn does not immediately restrict the permissions already assigned to that turn.

Expected behavior

Changing the access-control setting during an active turn should update the effective permissions of that running turn.

For example:

• Changing from read-only or workspace access to Full Access should allow subsequent tool calls in the same turn to use Full Access.
• Changing from Full Access to a more restrictive mode should prevent subsequent tool calls in the same turn from using the previously granted permissions.
• The permission mode displayed in the UI should match the permission mode currently enforced by the runtime.

If applying the change immediately is not technically or safely possible, the UI should make this explicit, for example by displaying:

Applies starting with the next turn

Currently, the control looks like an immediate runtime setting even though it behaves as a next-turn setting.

Why this matters

Long-running Codex turns can last for several minutes or considerably longer. During such a run, the agent may discover that it needs permissions which were not granted when the turn started.

The user can already change the setting in the UI, so it is natural to expect that this unblocks the running agent. Instead, the user must currently:

1. interrupt or wait for the active turn,
2. send another message,
3. ask the agent to resume the same work.

This interrupts the workflow, may lose execution continuity, and is especially inconvenient for long-running agent, Goal, orchestration, or background-command workflows.

It is also a security and trust issue in the opposite direction. If the user lowers permissions while an agent is running, the UI suggests that access has been reduced even though the active turn may retain its original permissions.

Suggested semantics

It may make sense to distinguish between permission reductions and permission increases.

Permission reduction

A reduction in access should ideally take effect immediately for all subsequent tool calls in the active turn.

Examples:

• Full Access → workspace access
• workspace access → read-only

Already-running processes may need separate handling, but no new privileged operation should begin after the restriction is applied.

Permission increase

An increase in access could either:

1. update the active turn’s runtime permission context immediately, or
2. pause the active turn at the next permission boundary and resume it with the new permission context.

Examples:

• read-only → workspace access
• workspace access → Full Access

The model may also need updated permission guidance so that it knows the newly available operations are permitted.

Possible implementation direction

The active turn appears to retain a permission or sandbox snapshot created when the turn starts, while settings changed through the UI are applied as next-turn thread settings.

A possible implementation could:

• update the active thread settings,
• propagate the new approval policy, reviewer, sandbox policy, and permission profile to the active turn,
• refresh the model-visible permission guidance where necessary,
• ensure that subsequent tool executions use the updated permission snapshot,
• emit a runtime event confirming that the active turn has adopted the new mode.

If active-turn mutation would introduce consistency problems, Codex could instead perform an internal pause-and-resume operation without requiring a new user message.

Acceptance criteria

• Changing access control during an active turn affects subsequent tool calls in that same turn.
• The effective runtime mode always matches what the UI displays.
• Reducing permissions prevents new operations that would violate the new setting.
• Increasing permissions allows the agent to continue without requiring a new user turn.
• Resumed, delegated, Goal, and compacted turns preserve the updated permission context.
• If active-turn updates are unsupported, the UI clearly states that changes apply only to the next turn.

Additional context

This is different from existing reports about stale or incorrect permission propagation across resumed turns or Goal continuations. In this case, the next turn receives the newly selected permissions correctly. The requested feature is specifically for applying a permissions change to a turn that is already running.