›_ Codex Issues
Codex Issues / #19356

Model permission UI shows Full Access, but runtime remains restricted with no escalation path

Resolved 💬 9 comments Opened Apr 24, 2026 by inshell-art Closed Apr 26, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.124.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iTerm2

What issue are you seeing?

Title: Model permission UI shows Full Access, but runtime remains restricted with no escalation path

Observed:
The UI showed:

  1. Full Access (current) - Codex can edit files outside this workspace and access the internet without asking.

But the model/runtime context still reported:
sandbox_mode = workspace-write
network access = restricted
approval policy = never

Impact:
The agent could not bind a local Vite dev server socket or kill/restart a local process.
npm run dev failed with:
Error: listen EPERM: operation not permitted ::1:5173

The agent also could not request escalation because approval_policy was never.

After switching to:

  1. Auto-review

The runtime exposed an escalation path, and the same dev-server action succeeded via require_escalated.
Vite started at http://localhost:5174/.

Expected:
Full Access should either actually provide unrestricted execution, or the runtime context should match the UI state. It should not be less capable than Auto-review.

Actual:
Full Access appeared selected in UI, but the runtime behaved like restricted/no-approval mode.

Likely area:
Permission state propagation between UI selection and model tool runtime, possibly after model/session switch.

What steps can reproduce the bug?

Re-run the run dev

What is the expected behavior?

3 full access works.

Additional information

_No response_

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #19349
  • #19256
  • #19196
  • #19346
  • #19217

Powered by Codex Action

Asentrixx · 2 months ago

Exacct same thing happening to me, cant do shit, stck in sandbox

zyzymwmw · 2 months ago

+1 same

derspotter · 2 months ago

fix this please!
-0.1 of global gdp lol

Choimoe · 2 months ago

I encountered the same issue on Ubuntu 22.04.5 with Kernel version 5.15.0-176-generic, after the update. When using grpc and brpc, both fail to start sockets with the errors:

127.0.0.1:18080: Operation not permitted / Fail to create socket: Operation not permitted

Manually running the program works without issues.

derspotter · 2 months ago

configure the config.toml then it works again

viyatb-oai contributor · 2 months ago

Can you try 0.125.0 and see if this fixes the issue?

xukl · 2 months ago

Fixed for me in 0.125.0. Also was good in 0.123.0. Only broken in 0.124.0.

I believe it's a duplicate of #19256 ?

inshell-art · 2 months ago

Confirmed fixed for me in codex-cli 0.125.0.

Full Access now reports the expected runtime permissions:

  • sandbox_mode = danger-full-access
  • network access = enabled
  • approval_policy = never

The issue was reproducible for me in 0.124.0 and no longer reproduces after upgrading. Closing as fixed / likely duplicate of #19256.