### What version of Codex CLI is running? `codex-cli 0.145.0` Current upstream `main` at `5615447ea941e4c8ddd392bf543cc67ab6f86323` still builds the shell-like tool schema with `require_escalated` unconditionally. ### What subscription do you have? Pro. This does not appear subscription-specific. ### Which model were you using? GPT-5.6 Sol, medium reasoning. The underlying issue is model-independent schema capability mismatch, although model behavior determines whether the redundant option is selected. ### What platform is your computer? Linux x86_64. ### What terminal emulator and version are you using (if applicable)? Ghostty. The issue is not terminal-specific. ### Codex doctor report Not applicable. The affected turn and rollout record the intended effective permissions: ```json { "approval_policy": "on-request", "sandbox_policy": { "type": "danger-full-access" }, "permission_profile": { "type": "disabled" } } ``` ### What issue are you seeing? Shell-like tool schemas continue to expose: ```json { "sandbox_permissions": "require_escalated", "justification": "...", "prefix_rule": ["..."] } ``` when the effective permission profile is already `danger-full-access` / `PermissionProfile::Disabled`. In that state, `require_escalated` cannot grant broader filesystem or network access: - the filesystem policy is already unrestricted; - the network policy is already enabled; - no platform sandbox is required; - no managed network proxy is exposed to the turn. Advertising `require_escalated` anyway gives the model a nonexistent capability distinction. In an observed session, an unsandboxed `nix ... zig build` encountered a transient Zig `NameServerFailure`. The model inferred that the first attempt had used a restricted network sandbox, told the user it would retry with "unrestricted network access", and issued the identical command with `sandbox_permissions: "require_escalated"`. The approved retry succeeded, which made the model's incorrect causal explanation look plausible. Rollout and source inspection showed that the original attempt was already danger-full-access with enabled network; escalation could not have enabled additional DNS or network access in that turn. This produces: - unnecessary approval prompts; - misleading claims that the original command was sandboxed; - false attribution of transient failures to Codex permissions; - reusable approval rules created for an escalation that had no effective permission to grant. Approval policy and sandbox capability should remain separate. `on-request` may still require approval for intrinsically risky commands under danger-full-access, but that policy approval should not be represented to the model as "run outside the sandbox" when no sandbox exists. Affected thread: ```text 019f27b6-f5f7-7143-938e-5d6cb07350e2 ``` Observed first call: ```json { "cmd": "nix --extra-experimental-features 'nix-command flakes' develop -c zig build", "workdir": "/home/user/code/ghostty", "yield_time_ms": 1000, "max_output_tokens": 12000 } ``` Observed failure: ```text error: invalid HTTP response: NameServerFailure ``` Observed retry: ```json { "cmd": "nix --extra-experimental-features 'nix-command flakes' develop -c zig build", "workdir": "/home/user/code/ghostty", "yield_time_ms": 1000, "max_output_tokens": 12000, "sandbox_permissions": "require_escalated", "justification": "Allow the full Ghostty build to download the newly pinned Zig dependencies from GitHub after the sandboxed DNS failure?", "prefix_rule": [ "nix", "--extra-experimental-features", "nix-command flakes", "develop", "-c", "zig", "build" ] } ``` ### What steps can reproduce the bug? 1. Start an interactive Codex CLI session with: ```toml sandbox_mode = "danger-full-access" approval_policy = "on-request" ``` 2. Inspect the model-facing schema for `exec_command` or another shell-like tool. 3. Observe that `sandbox_permissions` still includes `require_escalated`, with `justification` and `prefix_rule` fields describing an unsandboxed retry. 4. Cause or encounter a command failure that resembles sandbox denial, such as a transient DNS failure. 5. The model can request `require_escalated` even though the command is already running without filesystem or network restrictions. The schema mismatch itself is deterministic; reproducing the model's decision to use the redundant option depends on the model and failure text. ### What is the expected behavior? When the effective permission profile is already `PermissionProfile::Disabled` / danger-full-access, shell-like tool schemas should not advertise `require_escalated`. Concretely: - omit `require_escalated` from the `sandbox_permissions` enum; - omit `justification` and `prefix_rule` when they have no remaining use; - ideally omit `sandbox_permissions` entirely if no other per-command permission mode is available; - continue to enforce ordinary execution-policy approvals for risky commands independently of sandbox escalation. The model-facing tool surface should describe capabilities that can materially change execution. A no-op sandbox override should not be available. ### Additional information No existing open or closed issue matching this exact schema/capability mismatch was found before filing. Related but distinct: - #17660 discusses danger-full-access combined with on-request as a host-faithful workflow. - #29503 reports full-access selection incorrectly starting with workspace-write. - #15309 reports approved escalation retaining restricted network policy under default permissions. This report is not claiming that danger-full-access was ignored. The opposite is true: danger-full-access was already effective, making the advertised escalation redundant and the resulting explanation misleading. ### Source analysis The shell-like tool schema appends `require_escalated` unconditionally, based only on whether additional-permission approvals are enabled: https://github.com/openai/codex/blob/5615447ea941e4c8ddd392bf543cc67ab6f86323/codex-rs/core/src/tools/handlers/shell_spec.rs#L298-L343 The built-in danger-full-access profile resolves to `PermissionProfile::Disabled`: https://github.com/openai/codex/blob/5615447ea941e4c8ddd392bf543cc67ab6f86323/codex-rs/core/src/config/permissions.rs#L70-L96 `PermissionProfile::Disabled` resolves to unrestricted filesystem access and enabled network: https://github.com/openai/codex/blob/5615447ea941e4c8ddd392bf543cc67ab6f86323/codex-rs/protocol/src/models.rs#L499-L519 The sandbox manager selects `SandboxType::None` when the effective policies do not require a platform sandbox: https://github.com/openai/codex/blob/5615447ea941e4c8ddd392bf543cc67ab6f86323/codex-rs/sandboxing/src/manager.rs#L280-L318 `CODEX_SANDBOX_NETWORK_DISABLED` is inserted only when the effective network policy is restricted: https://github.com/openai/codex/blob/5615447ea941e4c8ddd392bf543cc67ab6f86323/codex-rs/core/src/sandboxing/mod.rs#L132-L148 The escalation path requests bypassing the sandbox, but danger-full-access has already selected no sandbox: https://github.com/openai/codex/blob/5615447ea941e4c8ddd392bf543cc67ab6f86323/codex-rs/core/src/tools/sandboxing.rs#L236-L270 ### Implementation / fix considerations 1. Make shell-like tool schema generation aware of the effective permission profile for the turn. 2. Expose `require_escalated` only when it can widen the active filesystem or network execution permissions. 3. Keep execution-policy approval behavior independent: - a dangerous command may still require user approval under `on-request`; - approval should not require the model to claim that it needs an unavailable sandbox bypass. 4. Apply the same capability filtering to all shell-like tool variants so `shell`, unified exec, and any generated compatibility surface remain consistent. 5. Consider rejecting `require_escalated` at the handler boundary when the effective profile is already disabled, so stale clients or resumed model context cannot invoke a meaningless override. 6. Preserve `with_additional_permissions` independently when a profile/runtime can make meaningful use of it. ### Acceptance criteria - Under danger-full-access / `PermissionProfile::Disabled`, model-facing shell-like schemas do not include `require_escalated`. - `justification` and `prefix_rule` are absent when sandbox escalation is unavailable. - Commands under danger-full-access continue to run with unrestricted filesystem and enabled network without requesting escalation. - Intrinsically risky commands can still trigger normal execution-policy approval under `on-request`. - Read-only, workspace-write, external-sandbox, and managed permission profiles continue to expose escalation only where it can materially widen execution. - Handler validation rejects or safely normalizes a stale `require_escalated` request when the active profile is already disabled. - Regression tests cover schema generation and runtime handling for both danger-full-access and a restricted profile.