tui: add named permission profile picker

[viyatb-oai]

Why

Users who opt into named permission profiles through default_permissions or [permissions.*] should stay in named-profile semantics when they open /permissions. The legacy picker rewrites those users into anonymous preset state, which loses the active profile identity and hides custom configured profiles.

What changed

• Switch /permissions to a profile-aware picker when profile mode is active.
• Show friendly built-in labels instead of raw : profile syntax.
• Include configured custom profiles and their descriptions in the picker.
• Route selections through the split TUI profile-selection flow below this PR.
• Add TUI snapshots and regression coverage for built-ins, custom profiles, and conflicting legacy runtime overrides.

Stack

1. #22931: runtime/session/network propagation for active permission profiles.
2. #23708: TUI selection plumbing and guardrail flow.
3. This PR: profile-aware /permissions menu and custom profile display.

UX impact

In profile mode, /permissions shows the same human-facing built-ins users already know:

Default
Auto-review
Full Access
Read Only
locked-down
web-enabled

Selecting locked-down keeps active_permission_profile = Some("locked-down"); selecting a built-in keeps the friendly label while switching to its named built-in profile.

Screenshots

Live $test-tui smoke screenshots uploaded through GitHub attachments:

Profile mode with built-ins and custom profiles

Legacy mode remains anonymous preset picker

Validation

• git diff --cached --check before commit.
• Full test run skipped at the user request while pushing the split stack.

[fcoury-oai]

I found a potential issue with the help of Codex:

When I switch to a different named profile mid-session, the TUI updates correctly and /status shows the new profile.

But then the already-running session does not fully adopt that profile’s runtime state.

It seems like switching from a profile with no managed network proxy to one with profile-specific network policy leaves the live thread on the old proxy/network behavior.

So the UI says “profile B is active,” but the current session can still behave like profile A until a fresh session/thread is started.

Repro

This is the exact repro steps I used to replicate this issue.

Setup in ~/.codex/config.toml:

default_permissions = "locked-down"

[permissions.locked-down.filesystem]
":minimal" = "read"

[permissions.web-enabled.filesystem]
":minimal" = "read"

[permissions.web-enabled.filesystem.":project_roots"]
"." = "write"

[permissions.web-enabled.network]
enabled = true
allow_local_binding = true

[permissions.web-enabled.network.domains]
"example.com" = "allow"

Important shape of the two profiles:

• locked-down has no network stanza at all
• web-enabled enables network and adds a profile-specific allowlist for example.com

Steps

1. Start a fresh Codex TUI session with locked-down active.
2. Send one trivial prompt so there is a live session/thread.
3. Run /debug-config.

Observed after step 3:

• no Session runtime network_proxy block is shown

4. Run /permissions and switch to web-enabled.
5. Run /status.

Observed after step 5:

• /status shows Permissions: Profile web-enabled (...)

6. Run /debug-config again, in the same session.

Observed after step 6:

• still no Session runtime network_proxy block

7. In that same session, ask Codex:
   Use the shell tool to run 'curl -I https://openai.com'

Observed after step 7:

• the request goes out and reaches OpenAI
• I got a real HTTP response path, ending in a Cloudflare challenge (HTTP/2 403, cf-mitigated: challenge), which means the outbound request was not blocked by the profile-specific allowlist

Expected
After switching to web-enabled, the live session should pick up the profile’s managed network policy. Since web-enabled only allows example.com, a shell-tool request to https://openai.com should be blocked.

Actual
The UI updates to web-enabled, but the live session does not appear to gain the managed proxy/runtime state for that profile:

• /status reflects the new profile
• /debug-config still shows no session network_proxy
• shell-tool network behavior still allows openai.com

Why this looks like the bug
This matches the code path concern that mid-session /permissions updates the TUI/app config copy, but the live-session override does not carry enough data to fully apply the selected named profile’s runtime network state. It reproduces specifically when switching from a profile with no managed proxy to one that requires a managed proxy.

[viyatb-oai]

Addressed the runtime proxy gap in b140e5f.

What changed:

• /permissions profile selections now carry active_permission_profile through the TUI -> core override path.
• Core rebuilds the selected profile network proxy spec from the effective config layers when applying an active profile update.
• The running managed network proxy is replaceable: profile switches can update an existing proxy, start one if the newly selected profile enables it, or drop the old handle if the new profile has no proxy.
• Added a regression test that switches from a locked profile to a web-enabled profile and asserts the session config picks up the selected profile proxy URL.

Local checks:

• cargo test -p codex-core session_configuration_apply_active_profile_rebuilds_network_proxy_config (green before final test-name cleanup)
• cargo test -p codex-core new_turn_refreshes_managed_network_proxy_for_sandbox_change
• cargo test -p codex-core session_configuration_apply_permission_profile_preserves_supplied_active_profile
• cargo test -p codex-tui apply_permission_profile_selection_ignores_legacy_harness_overrides
• cargo test -p codex-tui profile_permissions_selection
• just fix -p codex-core
• just fix -p codex-tui
• cargo clippy -p codex-core --tests -- -D warnings
• cargo clippy -p codex-tui --tests -- -D warnings
• git diff --check
• cargo clean

[fcoury-oai]

Smoke tested the happy path locally in profile mode with a temp CODEX_HOME/config.toml using default_permissions plus custom profiles.

Verified /permissions showed the profile-aware picker with friendly built-in labels and custom profile descriptions, selecting a custom profile emitted the expected “Permissions updated to …” message and became current on reopen, and switching back to Default preserved the friendly built-in label/current state.

Code looks good as well, approved. 👍