codex - 💡(How to fix) Fix Session permission profile changed from full access to on-request in one repo without visible /permissions command

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.