TUI Full Access permission picker selects rejected :danger-no-sandbox profile

Resolved 💬 3 comments Opened Jun 17, 2026 by slighter12 Closed Jul 8, 2026

What version of Codex CLI is running?

codex-cli 0.140.0

What subscription do you have?

ChatGPT subscription. This appears to be a local TUI/config regression rather than an account-specific issue.

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Warp v0.2026.06.10.09.27.stable_01

Codex doctor report

codex doctor --json is available, but I am omitting the full report because the current local report includes unrelated state database warnings and local absolute paths. The relevant config checks are included below.

What issue are you seeing?

In the TUI, selecting Full Access from the permissions menu fails with:

Failed to set permission profile `:danger-no-sandbox`: Failed to rebuild config for permission profile :danger-no-sandbox

This does not appear to be a local config problem. The current CLI rejects :danger-no-sandbox, while accepting the canonical :danger-full-access.

Local repro:

codex --strict-config -c 'default_permissions=":danger-no-sandbox"' doctor --summary
# fails: config could not be loaded

codex --strict-config -c 'default_permissions=":danger-full-access"' doctor --summary
# succeeds: unrestricted fs + enabled network

Upstream source also appears inconsistent on current main (a5229e06867b83b2cf331c852cebfcc74828bd24):

codex-rs/tui/src/chatwidget/permissions_menu.rs still uses :danger-no-sandbox for the Full Access item.
codex-rs/protocol/src/models.rs defines the canonical full-access built-in profile as :danger-full-access.
codex-rs/core/src/config/config_tests.rs explicitly rejects the legacy :danger-no-sandbox id.
codex-rs/tui/src/chatwidget/tests/permissions.rs still expects the legacy id for the Full Access selection.

What steps can reproduce the bug?

Start Codex CLI TUI.
Open the permissions menu.
Select Full Access.
Observe the error:

Failed to set permission profile `:danger-no-sandbox`: Failed to rebuild config for permission profile :danger-no-sandbox

A command-line equivalent of the rejected profile is:

codex --strict-config -c 'default_permissions=":danger-no-sandbox"' doctor --summary

What is the expected behavior?

Selecting Full Access in the TUI should select the canonical built-in profile :danger-full-access and rebuild config successfully.

Additional information

This looks like a missed TUI call site after PR #22624 renamed the built-in full-access permission profile from :danger-no-sandbox to :danger-full-access.

Likely minimal fix: update the Full Access selection item in codex-rs/tui/src/chatwidget/permissions_menu.rs to use :danger-full-access, preferably via the shared built-in profile constant or the existing full-access preset metadata, and update the corresponding TUI test expectation.

View original on GitHub ↗

3 Comments

bisma-nawaz · 2 months ago

Here is my analysis on the issue:

Root cause

The TUI's "Full Access" permission menu item still references the legacy built-in profile ID :danger-no-sandbox. That ID was renamed to the canonical :danger-full-access in #22624 ("permissions: canonicalize workspace_roots and danger-full-access names"). Since the CLI now explicitly rejects the old ID, selecting Full Access in the TUI fails with:

Failed to set permission profile :danger-no-sandbox: Failed to rebuild config for permission profile :danger-no-sandbox

So this seems like a missed site in the TUI rather than a config/account problem and the menu was simply not updated when the profile was renamed.

Expected behavior

Selecting Full Access should apply the canonical :danger-full-access profile and should rebuild the config without error.

Here is my propsosed solution:

Proposed fix outline

Update the Full Access selection in codex-rs/tui/src/chatwidget/permissions_menu.rs to use :danger-full-access instead of the hard-coded :danger-no-sandbox.
Prefer referencing the shared built-in profile constant / preset metadata rather than a string literal, so future renames don't reintroduce drift.
Update the corresponding TUI test expectation so it asserts the canonical ID.

Nicolas0315 · 2 months ago

I rechecked this against current origin/main (ab80d4d48460) and it looks fixed there now.

Evidence:

codex-rs/tui/src/chatwidget/permissions_menu.rs imports BUILT_IN_PERMISSION_PROFILE_DANGER_FULL_ACCESS and uses it for the Full Access menu item.
codex-rs/tui/src/chatwidget/tests/permissions.rs has profile_permissions_full_access_opens_confirmation, which asserts the emitted profile id equals BUILT_IN_PERMISSION_PROFILE_DANGER_FULL_ACCESS.
Focused validation passed locally on Windows:

just test -p codex-tui profile_permissions_full_access_opens_confirmation
Summary: 1 test run: 1 passed, 2946 skipped

So unless someone can still reproduce this on a build from current main, this issue can probably be closed as fixed by the later permission-profile follow-up changes.

slighter12 · 1 month ago

I rechecked this against current releases. The TUI Full Access item now uses the canonical :danger-full-access path via BUILT_IN_PERMISSION_PROFILE_DANGER_FULL_ACCESS, and this appears fixed in 0.142.5+.

Closing as fixed. Please reopen if this still reproduces on a current build.