Codex Desktop full-access and approved command prefixes still trigger approval prompts
Summary
Codex Desktop appears to have a permission and escalation bug.
Even after the user enables full access in the Codex Desktop UI and approves specific command prefixes, later tool calls still trigger approval prompts or fail inside the sandbox with network errors.
This breaks unattended long-running workflows because the agent cannot reliably tell whether a command is genuinely unsafe, already approved, blocked by a network sandbox, or blocked by prefix matching.
Environment
- Product: Codex Desktop app
- OS: macOS
- Shell: zsh
- Filesystem mode reported to agent: workspace-write / restricted
- Network mode reported to agent: restricted
- User setting: full access enabled in Codex UI
- Workflow: long-running goal, GitHub Actions deploy verification, multi-agent coordination
Observed Behavior
The user explicitly granted full access and approved command categories such as git add, git commit, git push, gh run view, and gh workflow run.
Despite that:
- git add was still reported as sandbox-denied.
- gh workflow run initially failed inside the sandbox with a GitHub API connectivity error, then required escalation.
- gh run view succeeded once after approval, but a later gh run view invocation still tried to raise an approval path.
- curl to a clone host failed inside the sandbox with DNS resolution failure and retrying required another approval prompt.
- A piped command using an approved gh run view segment plus local rg filtering was not handled as an already-approved operation.
Expected Behavior
- Full-access mode should either be authoritative, or the UI should clearly state which limits remain.
- Saved prefix approvals should apply consistently to later matching commands.
- The denial reason should distinguish filesystem sandbox, network sandbox, shell segmentation, prefix mismatch, and user policy.
- Long-running Codex Desktop goals should support a non-interactive scoped allow policy so overnight work does not stop on repeated prompts.
Actual Behavior
The session enters contradictory states:
- The agent sees approved prefixes, but still has to request escalation.
- The user believes full access is enabled, but commands still fail due to sandbox or network restrictions.
- Retrying with escalation opens approval UI, which defeats unattended operation.
- Rejecting that UI because permission was already granted leaves the agent unable to proceed.
Impact
This is severe for Codex Desktop autonomous workflows.
Deploy/proof loops stop unexpectedly, the user cannot safely leave the agent unattended, and the UX makes it appear that Codex is ignoring explicit authorization.
Additional Note
During an attempted bug report, a shell command containing issue-body text with backticks caused the shell to interpret parts of the body as command substitution.
This is partly agent/tooling misuse, but it also shows why issue creation and shell escalation paths need safer structured APIs or first-class bug-report tooling.
No secrets are included in this report.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗