danger-full-access still advertises no-op require_escalated capability

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:

{
  "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:

{
  "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:

019f27b6-f5f7-7143-938e-5d6cb07350e2

Observed first call:

{
  "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:

error: invalid HTTP response: NameServerFailure

Observed retry:

{
  "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"
``

1. Inspect the model-facing schema for exec_command or another shell-like tool.
2. Observe that sandbox_permissions still includes require_escalated, with justification and prefix_rule fields describing an unsandboxed retry.
3. Cause or encounter a command failure that resembles sandbox denial, such as a transient DNS failure.
4. 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.

1. Apply the same capability filtering to all shell-like tool variants so shell, unified exec, and any generated compatibility surface remain consistent.
2. 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.
3. 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.