Codex Desktop /goal requests command approvals despite full access and approval_policy=Never

What happened?

In Codex Desktop, a /goal run continues to prompt for command-prefix approvals even though the thread/session is configured for full access:

approval_policy=Never
sandbox_policy=DangerFullAccess

The Desktop UI/state also shows the local host in full-access mode, and the persisted thread permissions show approvalPolicy: "never" with sandboxPolicy: { type: "dangerFullAccess" }.

Despite that, the /goal agent emits ExecApproval requests for command-prefix amendments such as:

["uv", "run", "python"]
["uv", "run", "ruff"]
["git", "add"]
["git", "commit"]

One captured function call from the session log had:

{
  "cmd": "uv run python ...",
  "sandbox_permissions": "require_escalated",
  "justification": "Allow uv to use its cache while running the fixture e2e ground-truth benchmark.",
  "prefix_rule": ["uv", "run", "python"]
}

Immediately before/around the same resumed goal session, the log records:

model="gpt-5.5" approval_policy=Never sandbox_policy=DangerFullAccess ... features=[..., GuardianApproval, Goals, ...]

So the session appears to know approvals should never be required, but the goal runner still surfaces approval prompts when the model voluntarily requests sandbox_permissions=require_escalated / prefix_rule.

Expected behavior

When a Desktop /goal session is running with approval_policy=Never and sandbox_policy=DangerFullAccess, command-prefix approval prompts should not be shown. Either:

• the model should not be encouraged/allowed to request sandbox_permissions=require_escalated, or
• the runtime should ignore/strip escalation requests because the session already has full access and never-ask approval policy.

Actual behavior

The user still has to confirm command-prefix approvals during /goal runs, even after:

1. setting Desktop local mode to full access,
2. stopping the active goal,
3. quitting/reopening Codex Desktop,
4. starting /goal again.

Environment

• Codex Desktop client versions observed in logs: 26.519.22136 and 26.519.41501
• Host: local Desktop session
• Active mode/state: full access
• Session policy in logs: approval_policy=Never, sandbox_policy=DangerFullAccess
• Feature set includes Goals and GuardianApproval

Workaround

Adding this instruction to the /goal prompt appears to be the likely workaround:

This session already has full access. Do not request escalated permissions, do not set sandbox_permissions=require_escalated, and do not ask for command-prefix approvals. Run shell commands normally.

But this should not be necessary when the persisted/session policy is already Never + DangerFullAccess.

Why this matters

Long-running /goal tasks are specifically useful for unattended work. Requiring manual approvals under a never-ask/full-access policy defeats that use case and makes the Desktop UI confusing: it says full access is enabled, but the goal still blocks on approvals.