Skip to content

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

Closed
Closed
/permissions changes do not propagate to the active session in codex-cli 0.124.0#19256
Labels
bugSomething isn't workingregressionBehaviors that worked in previous versions but were broken due to an updatesandboxIssues related to permissions or sandboxingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@wypong
wypong
opened on Apr 24, 2026

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

Activity

  1. wypong
    added
    bugSomething isn't working
    on Apr 24, 2026
  2. github-actions
    added
    CLIIssues related to the Codex CLI
    sandboxIssues related to permissions or sandboxing
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Apr 24, 2026

  3. github-actions commented on Apr 24, 2026

    @github-actions
    github-actionsBot
    on Apr 24, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. etraut-openai
    removed
    CLIIssues related to the Codex CLI
    on Apr 24, 2026

  5. etraut-openai commented on Apr 24, 2026

    @etraut-openai
    etraut-openai
    on Apr 24, 2026
    Contributor

    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.

  6. christiandoxa commented on Apr 24, 2026

    @christiandoxa
    christiandoxa
    on Apr 24, 2026

    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.

  7. mahmoud1973 commented on Apr 24, 2026

    @mahmoud1973
    mahmoud1973
    on Apr 24, 2026

    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

  8. etraut-openai
    added
    regressionBehaviors that worked in previous versions but were broken due to an update
    on Apr 24, 2026

  9. sjtianwen commented on Apr 24, 2026

    @sjtianwen
    sjtianwen
    on Apr 24, 2026

    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.

  10. etraut-openai commented on Apr 24, 2026

    @etraut-openai
    etraut-openai
    on Apr 24, 2026
    Contributor

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

  11. etraut-openai
    closed this as completedon Apr 24, 2026
  12. etraut-openai
    marked /permissions Full Access session-only confirmation persists approvals_reviewer to config.toml #19297 as a duplicate of this issue on Apr 24, 2026

  13. Joey-Lei commented on Apr 24, 2026

    @Joey-Lei
    Joey-Lei
    on Apr 24, 2026

    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.

  14. mtfelian
    marked No more writes to sibling repos using Full Access policy #19346 as a duplicate of this issue on Apr 24, 2026

  15. danlannan777 commented on Apr 24, 2026

    @danlannan777
    danlannan777
    on Apr 24, 2026

    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

  16. Fanduzi commented on Apr 24, 2026

    @Fanduzi
    Fanduzi
    on Apr 24, 2026

    same issue

  17. jdavidhoward commented on Apr 24, 2026

    @jdavidhoward
    jdavidhoward
    on Apr 24, 2026

    Same issue

  18. Joey-Lei commented on Apr 24, 2026

    @Joey-Lei
    Joey-Lei
    on Apr 24, 2026

    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:

    Joey-Lei/codex-cli-fork@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

  19. Joey-Lei commented on Apr 24, 2026

    @Joey-Lei
    Joey-Lei
    on Apr 24, 2026

    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.

  20. inshell-art
    marked Model permission UI shows Full Access, but runtime remains restricted with no escalation path #19356 as a duplicate of this issue on Apr 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingregressionBehaviors that worked in previous versions but were broken due to an updatesandboxIssues related to permissions or sandboxingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions