›_ Codex Issues
Codex Issues / #19256

`/permissions` changes do not propagate to the active session in `codex-cli 0.124.0`

Resolved 💬 12 comments Opened Apr 24, 2026 by wypong Closed Apr 24, 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?

GPT-EDU

Which model were you using?

gpt-5.4

What platform is your computer?

Linux

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

st

What issue are you seeing?

Changes made through /permissions are saved in the UI/config flow, but they do not take effect in the current session. The active session continues using the old permission state.

In practice, changing permissions such as approval mode or sandbox behavior via /permissions appears to update the setting surface, but the running thread still behaves as if the previous session permissions are still active.

What steps can reproduce the bug?

  1. Start a Codex session.
  2. Run /status and note the current permission state.
  3. Run /permissions.
  4. Change the permission setting to a different mode, for example switching to Full Access.
  5. Return to the same session.
  6. Ask codex to report sandox, approval status shows that nothing has changed.

What is the expected behavior?

After granting 'Full Access' from \permissions, it should be
Filesystem sandbox: danger-full-access
Approval policy: never
Network access: enabled

Additional information

_No response_

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 2 months ago

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

  • #18854
  • #17653
  • #19196
  • #18113

Powered by Codex Action

etraut-openai contributor · 2 months ago

You specifically mentioned 0.124.0 in the title. Do you have reason to believe this worked in previous versions? I'm trying to determine if this is a regression in 0.124.0.

christiandoxa · 2 months ago

I can confirm I’m seeing the same behavior. I usually run Codex with full access, but in codex-cli 0.124.0 the /permissions changes don’t seem to take effect in the active session for me either.

As a temporary workaround, I downgraded to 0.123.0, where the behavior works as expected for my workflow. That said, I would really prefer to stay on the newer version because I want to use GPT-5.5.

mahmoud1973 · 2 months ago
You specifically mentioned 0.124.0 in the title. Do you have reason to believe this worked in previous versions? I'm trying to determine if this is a regression in 0.124.0.

Same issue here, full access is working fine on 0.123.0 and totally broken on 0.124.0. I downgraded to 0.123.0 to fix the issue. CLI - Ubuntu 24.04.4

sjtianwen · 2 months ago

You can use codex -s danger-full-access -a never to solve this problem.
I suspect the problem lies in the internal control permissions code.

You specifically mentioned 0.124.0 in the title. Do you have reason to believe this worked in previous versions? I'm trying to determine if this is a regression in 0.124.0.
etraut-openai contributor · 2 months ago

Thanks for the bug report. This will be addressed in the next release.

decentralizedblack-maker · 2 months ago

I reproduced a related session/config boundary issue while investigating this.

In codex-cli 0.124.0, selecting:

/permissions -> Full Access -> Yes, continue anyway

is described as session-scoped, but it can still persist:

approvals_reviewer = "user"

to ~/.codex/config.toml.

I prepared a minimal patch in my fork, but I cannot open a PR because this repository currently limits PR creation to collaborators:

The patch adds a session-only UpdateApprovalsReviewerForSession event and uses it for /permissions preset selection, while keeping the existing persistent UpdateApprovalsReviewer event for flows that intentionally write approvals_reviewer to config.toml.

Local verification:

  • git diff --check passed

I could not run cargo fmt / cargo test locally because this shell does not currently have Rust tooling available.

danlannan777 · 2 months ago

Also seeing this. I'm trying to have Codex hit AWS to read some logs and it can't get outside the network sandbox with 'Full Permissions' on

Fanduzi · 2 months ago

same issue

jdavidhoward · 2 months ago

Same issue

decentralizedblack-maker · 2 months ago

Update on local verification for the fork patch:

  • Installed Rust via rustup.
  • Ran cargo fmt from codex-rs/; it completed. I pushed the formatting follow-up to the same fork branch.
  • Re-ran the targeted test command:
cargo test -p codex-tui permissions_full_access_history_cell_emitted_only_after_confirmation

The test did not reach execution locally because the first local build was blocked by native dependency setup:

  • v8 failed while preparing librusty_v8 (Decompression error Err(Buf), then missing rusty_v8 after clearing the bad output)
  • a retry also hit webrtc-sys native artifact download failure due to TLS EOF

The compare branch is updated here:

https://github.com/decentralizedblack-maker/codex-cli-fork/compare/main...fix/full-access-session-only-permission

So the current local verification is:

  • git diff --check passed
  • cargo fmt completed
  • targeted codex-tui test attempted, but blocked by native dependency download/link setup before tests ran
decentralizedblack-maker · 2 months ago

Update after fixing my local Rust/native dependency setup and tightening the fork patch:

I also removed the now-unused persistent UpdateApprovalsReviewer event/handler after the compiler surfaced it as dead code. The fork patch now keeps the Full Access confirmation path session-scoped via UpdateApprovalsReviewerForSession and avoids writing approvals_reviewer to config.toml.

Full upstream CI is still unavailable from my side because PR creation against this repository is restricted to collaborators.