›_ Codex Issues
Codex Issues / #23958

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

Open 💬 3 comments Opened May 21, 2026 by Kenchan1111
💡 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.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:

  • #23875
  • #23105

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

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23105

Powered by Codex Action

jshaofa-ui · 3 months ago

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

etraut-openai contributor · 3 months ago

[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.