codex - 💡(How to fix) Fix Codex Desktop /goal requests command approvals despite full access and approval_policy=Never

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

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.

Fix Action

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.

Code Example

approval_policy=Never
sandbox_policy=DangerFullAccess

---

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

---

{
  "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"]
}

---

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

---

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.
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

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.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop /goal requests command approvals despite full access and approval_policy=Never