Upgrading /Permissions to Full Access does not take effect during an active task

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #32239
• #32237

Powered by Codex Action

I can reproduce the same active-turn boundary on macOS:

• Codex CLI: 0.144.4
• Platform: Darwin 25.5.0 arm64 arm
• Terminal: iTerm2 3.6.11

After selecting and confirming Full Access during an active turn, the TUI displays Permissions updated to Full Access, but later tool calls in that same turn continue to request approval. The next user turn in the same thread uses Full Access correctly.

I traced the current main implementation (2e1607ee2fa8099a233df7437adee5f16a741905) and found the following:

1. The TUI immediately inserts the success message and sends an OverrideTurnContext action:

https://github.com/openai/codex/blob/2e1607ee2fa8099a233df7437adee5f16a741905/codex-rs/tui/src/chatwidget/permission_popups.rs#L248-L273

1. The action is translated into thread/settings/update:

https://github.com/openai/codex/blob/2e1607ee2fa8099a233df7437adee5f16a741905/codex-rs/tui/src/app/thread_settings.rs#L94-L134

1. Session::update_settings updates the stored SessionConfiguration, but it does not update the already-created TurnContext:

https://github.com/openai/codex/blob/2e1607ee2fa8099a233df7437adee5f16a741905/codex-rs/core/src/session/mod.rs#L1440-L1477

1. Approval calculation and shell execution continue reading the active turn's frozen approval policy and permission profile:

https://github.com/openai/codex/blob/2e1607ee2fa8099a233df7437adee5f16a741905/codex-rs/core/src/tools/handlers/shell.rs#L168-L219
https://github.com/openai/codex/blob/2e1607ee2fa8099a233df7437adee5f16a741905/codex-rs/core/src/tools/orchestrator.rs#L137-L168

The built-in Full Access preset is unambiguous: AskForApproval::Never plus PermissionProfile::Disabled:
https://github.com/openai/codex/blob/2e1607ee2fa8099a233df7437adee5f16a741905/codex-rs/utils/approval-presets/src/lib.rs#L50-L59

Suggested approval-boundary behavior

Before emitting a user approval request for ExecApprovalRequirement::NeedsApproval, re-read the thread's latest effective settings (for example through Session::thread_config_snapshot) rather than relying only on the turn-frozen values.

If the latest acknowledged settings are Full Access (approval_policy == Never and the effective permission profile is PermissionProfile::Disabled):

• do not emit another approval prompt;
• recompute the requirement as Skip;
• execute the call using the refreshed Full Access profile, not the stale restricted sandbox profile; and
• invalidate or auto-resolve an already-pending stale approval request after the Full Access update is acknowledged.

This check could happen immediately before resolve_tool_apporval in the NeedsApproval path. It is important to refresh both the approval decision and the execution/sandbox permissions; merely hiding the prompt would otherwise leave the command running under the stale restricted profile.

This would provide a natural synchronization boundary without requiring every part of TurnContext to become mutable: a tool call that reaches an approval boundary can observe the user's explicit Full Access upgrade and continue without interrupting the active task. If active-turn adoption is intentionally unsupported, the TUI message should instead say that the change applies starting with the next turn.

I can reproduce the same active-turn failure in a Linux/WSL environment with Codex CLI 0.144.4.

After the TUI says Permissions updated to Full Access, the active task still asks for approval for repository-local commands, e.g.:

npm run pipeline:docs:refresh
npm run pipeline:docs:check

The stated reason is that the local TypeScript tool needs a temporary local IPC socket. I approved and allowlisted npm run pipeline:docs:refresh, which then completed, but the following npm run pipeline:docs:check immediately prompted again for the same reason.

This is disruptive for unattended/YOLO workflows: Full Access is visibly acknowledged, yet each new command prefix can still interrupt the already-running task. The failure is not specific to network access; these are repository-local documentation commands using a temporary local IPC socket.

Update: I rebuilt this as a clean commit from current main and corrected test-compilation issues found in my initial draft.

Patch: https://github.com/simfor99/codex/commit/26e1b05
Compare: https://github.com/openai/codex/compare/main...simfor99:codex:fix/active-turn-permissions-clean?expand=1

The change keeps the active turn’s approval_policy and permission_profile behind shared locks, so Session::update_settings updates the values used by subsequent tool calls in the already-running turn. It also refreshes the MCP manager.

Regression coverage:

• update_settings_applies_permissions_to_an_active_turn (core)
• thread_settings_update_applies_full_access_to_an_active_turn (app server)

Validated:

• just fmt
• just test -p codex-core update_settings_applies_permissions_to_an_active_turn (1 passed, 2972 skipped)
• just test -p codex-app-server thread_settings_update_applies_full_access_to_an_active_turn (1 passed, 982 skipped)
• just fix -p codex-core

The previous commit linked here is superseded by this one. I could not open an upstream PR because this repository restricts PR creation to collaborators, but this branch and commit are available to cherry-pick.

I can reproduce this behavior as well.

Environment:

• Codex CLI: codex-cli 0.145.0
• Platform: Linux / Ubuntu
• Terminal: SSH Terminal
• Uploaded thread: 019fc4df-715d-7e52-b466-f70a94eee9aa

During an active, long-running task, I changed /permissions from the middle/workspace permission tier to Full Access. Codex confirmed that Full Access was selected, but subsequent commands in the same active task continued requesting approval under the previous permission level.

Changing permissions during a session should update the effective permission state for subsequent tool calls without requiring the current task to be cancelled or restarted.

Ideally, after Full Access is confirmed:

• future tool calls in the active task should use Full Access immediately;
• stale approval requests created under the previous permission level should be invalidated;
• the UI should clearly display the effective permission level used by the current tool call.

Restarting a long-running task is disruptive because it can repeat work, lose execution progress, or cause the agent to abandon the original workflow.

Corroborating this on Windows 11 with Codex Desktop 26.803.10989.0 (ChatGPT Desktop 1.2026.190.0).

Observed sequence:

1. A parent task was running with Full Access / approvals disabled.
2. A separate user-owned task created through the app's create_thread route began with recorded effective settings workspace-write / approval_policy: on-request / restricted filesystem. The creation route exposed no permission parameter and did not inherit the parent's mode. This part overlaps #25810.
3. The created task was opened and Full Access was selected in the UI.
4. The bottom bar then showed the orange Full Access label, but the already-active turn continued enforcing the older restricted approval state and requested approval for nearly every command.

The misleading part is therefore not only that the new task starts restricted: after the UI switch, the visible label says Full Access while the active turn still behaves as restricted. A worker can reasonably trust the displayed mode and misdiagnose the resulting prompts as its own orchestration error.

No repository-specific behavior was involved. The safe operational workaround is to treat the label as requested state only: stop the active turn, start a new turn after selecting the mode, and verify the new turn's recorded effective permission tuple before substantive commands. A mid-turn UI change did not repair the running turn in this reproduction.