Skip to content

Session permission profile changed from full access to on-request in one repo without visible /permissions command #23958

Open
Open
Session permission profile changed from full access to on-request in one repo without visible /permissions command#23958
Labels
CLIIssues related to the Codex CLIbugSomething isn't workingsandboxIssues related to permissions or sandboxingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@Kenchan1111
Kenchan1111
opened on May 21, 2026

What version of Codex CLI is running?

codex-cli 0.132.0

What subscription do you have?

Unknown / not relevant to the local session-state repro.

Which model were you using?

Local traces show gpt-5.5 for Gestion_Projet and gpt-5.4 for Depollution_Sols in the affected sessions.

What platform is your computer?

Linux fedora 6.19.14-200.fc43.x86_64
Fedora Linux 43 (Workstation Edition)

What issue are you seeing?

I have a local Codex session-state anomaly that looks like a permissions/session-context bug.

In the exact 2026-05-21 22:30 -> 2026-05-22 01:30 Europe/Brussels window, one repository session (Gestion_Projet) switched permission profile from:

  • approval_policy=never
  • sandbox=danger-full-access

into:

  • approval_policy=on-request
  • sandbox=workspace-write

and later back again, even though I cannot find any literal user /permissions command in the local trace for that session.

At the same time, another active Codex session in a different repository (Depollution_Sols) stayed on:

  • approval_policy=never
  • sandbox=danger-full-access

for the same time window.

This happened in a period where:

  • multiple Codex sessions were open in parallel in different repos
  • the machine resumed from sleep
  • Wi-Fi came back later than the resume event

I am not claiming compromise from this alone. I am reporting what looks like a session/runtime permission-profile change that is not explained by a visible local /permissions action.

What steps can reproduce the bug?

I do not yet have a deterministic clean repro, but I do have a concrete local pattern:

  1. Keep multiple Codex sessions open in parallel in different repositories.
  2. One session is in Gestion_Projet (roadworks / Excel quantity surveying domain).
  3. Another session is in Depollution_Sols (soil and groundwater interpretation domain).
  4. Let the machine sleep and resume, with network recovery delayed after wake.
  5. Continue using the sessions afterward.
  6. Inspect the local session JSONL traces under ~/.codex/sessions/....

Observed result in local traces:

  • Gestion_Projet changes from never / danger-full-access to on-request / workspace-write, then later back to never / danger-full-access.
  • Depollution_Sols remains never / danger-full-access in the same window.
  • No literal user /permissions command is present in either affected session trace.

What is the expected behavior?

Within an active session, the effective permission profile should not change silently.

If a permission/sandbox profile changes, I would expect one of the following:

  • an explicit user action such as /permissions
  • an explicit UI/system event explaining the transition
  • a clearly logged resume/compaction/runtime event showing why the effective profile changed

I would also expect adjacent sessions in other repos not to drift unpredictably in profile without a visible cause.

Additional information

Relevant local session ids:

  • 019e07fd-5237-76e2-92ce-2cb18ac1408c -> Gestion_Projet
  • 019d9251-ca09-73d1-92a3-33fe3d9731c3 -> Depollution_Sols

Local timeline (Europe/Brussels):

Gestion_Projet

  • 2026-05-21 22:51:10 -> approval_policy=never, sandbox=danger-full-access
  • 2026-05-22 00:43:01 -> approval_policy=on-request, sandbox=workspace-write
  • 2026-05-22 00:44:21 -> approval_policy=on-request, sandbox=workspace-write
  • 2026-05-22 01:24:04 -> approval_policy=never, sandbox=danger-full-access

Depollution_Sols

  • 2026-05-21 22:51:25 -> approval_policy=never, sandbox=danger-full-access
  • 2026-05-22 00:11:45 -> approval_policy=never, sandbox=danger-full-access
  • 2026-05-22 00:45:16 -> approval_policy=never, sandbox=danger-full-access
  • 2026-05-22 00:50:50 -> approval_policy=never, sandbox=danger-full-access

Network-related context from local system logs:

  • sleep resume at 2026-05-21 22:48:36 Europe/Brussels
  • network back to CONNECTED_GLOBAL at 2026-05-21 22:56:12 Europe/Brussels

Additional local observation:

  • searching the affected session traces does not show a literal user-issued /permissions command

This may be related to other session-context / compaction / permissions drift issues such as:

If useful, I can provide a more compact sanitized timeline focused only on the session metadata transitions.

Activity

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

  2. github-actions commented on May 21, 2026

    @github-actions
    github-actionsBot
    on May 21, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. jshaofa-ui commented on May 22, 2026

    @jshaofa-ui
    jshaofa-ui
    on May 22, 2026

    Solution: Session Permission Profile Silent Change

    Root Cause

    The permission profile change is likely triggered by session resume/reconnection logic. When the machine resumes from sleep, Codex reconnects to the app-server and may reload session state from a persisted file with stale/different permission settings. No logging or notification occurs for non-user-initiated changes.

    Proposed Fix

    Fix 1 — Log all permission profile changes with cause:

    function setPermissionProfile(sessionId, profile, cause) {
  logger.info('Permission profile changed', {
    sessionId, previousProfile: getCurrentProfile(sessionId), newProfile: profile,
    cause, // 'user-command', 'resume', 'sync', 'default', 'unknown'
    stackTrace: new Error().stack
  });
  if (cause !== 'user-command') {
    session.notifyUser({ type: 'permission-profile-changed', from: getCurrentProfile(sessionId), to: profile, reason: cause });
  }
}

    Fix 2 — Verify permission profile on resume:

    async function resumeSession(sessionId) {
  const persisted = await loadSessionState(sessionId);
  const current = getCurrentPermissionProfile(sessionId);
  if (!profilesMatch(persisted.permissionProfile, current)) {
    setPermissionProfile(sessionId, persisted.permissionProfile, 'resume-restore');
    session.notifyUser({ type: 'permission-profile-restored', profile: persisted.permissionProfile });
  }
}

    Fix 3 — Ensure session isolation:
    Each session must have its own permission state with no shared mutable state between sessions.

    Code locations

    • src/session/state-manager.ts — Session state persistence
    • src/session/permission-manager.ts — Permission profile management
    • src/session/resume.ts — Session resume logic

    Full solution: solutions/codex-23958-session-permission-profile-silent-change-fix.md

  4. etraut-openai commented on May 26, 2026

    @etraut-openai
    etraut-openai
    on May 26, 2026
    Contributor

    [From Codex]

    I don’t think this proves a Codex bug yet.

    A missing literal /permissions entry in the JSONL is not enough evidence, because resume/turn startup can apply the current CLI/config permission settings without a /permissions command being present. In particular, thread/resume and turn/start both carry approval/sandbox/permission settings from the active config, and each turn persists those values in TurnContextItem.

    So this could be explained by one of:

    • the session being resumed with different CLI flags or config
    • config/profile changing between turns
    • a runtime permission override being present for one turn and absent later
    • a cached/running thread ignoring or applying resume overrides depending on state

    To investigate this as a real bug, we’d need the raw surrounding JSONL records around these timestamps, plus the exact launch/resume commands and relevant config at each point:

    • 2026-05-21 22:51:10
    • 2026-05-22 00:43:01
    • 2026-05-22 00:44:21
    • 2026-05-22 01:24:04

    Specifically, please include nearby session_meta, turn_context, resume/start/settings events, and any thread/settings or config-related records.

    If those show the same live process changing permission profile without a resume, settings update, CLI/config override, or /permissions, then this gets interesting. As reported, though, it looks more like expected resume/config behavior than silent permission drift.

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

    CLIIssues related to the Codex CLIbugSomething isn't workingsandboxIssues 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