Codex CLI /permissions omits Read-only in WSL2 but shows it in Windows PowerShell
What version of Codex CLI is running?
codex-cli 0.132.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.5, high reasoning effort
What platform is your computer?
WSL2 on Windows, running Linux:
Linux <HOSTNAME> 6.6.87.2-microsoft-standard-WSL2 x86_64 GNU/Linux
Terminal: Windows Terminal
Shell: bash in WSL2; Windows PowerShell for comparison
Codex install: npm
What issue are you seeing?
In the Codex CLI TUI running inside WSL2, /permissions does not show a Read-only option. In native Windows PowerShell on the same machine, also running codex-cli 0.132.0, the /permissions menu does include a Read-only option.
The WSL2 menu only shows:
Update Model Permissions
> 1. Default Codex can read and edit files in the current workspace, and
run commands. Approval is required to access the internet or
edit other files.
2. Auto-review Same workspace-write permissions as Default, but eligible
`on-request` approvals are routed through the auto-reviewer
subagent.
3. Full Access Codex can edit files outside this workspace and access the
internet without asking for approval. Exercise caution when
using.
There is no Read-only entry, even though:
~/.codex/config.tomlsetssandbox_mode = "read-only"codex --helpdocuments--sandbox read-onlycodex sandbox linux --permissions-profile :read-only ...enforces read-only correctly- OpenAI docs say
/permissionsshould support switching to Read-only mode
This makes it impossible to switch into read-only mode from the WSL2 TUI without restarting Codex with CLI flags.
What steps can reproduce the bug?
- In WSL2, configure Codex with:
approval_policy = "on-request"
sandbox_mode = "read-only"
approvals_reviewer = "user"
- Start Codex:
codex
- Open the permissions menu:
/permissions
- Observe that the menu only shows:
Default
Auto-review
Full Access
- Compare with native Windows PowerShell on the same machine and same Codex version, where
/permissionsincludes Read-only.
What is the expected behavior?
The WSL2 /permissions menu should include a Read-only option, matching native Windows PowerShell and the documented CLI behavior.
Docs:
- https://developers.openai.com/codex/cli/features#approval-modes
- https://developers.openai.com/codex/agent-approvals-security
- https://developers.openai.com/codex/permissions
Additional information
Relevant WSL2 config:
model = "gpt-5.5"
model_reasoning_effort = "high"
personality = "pragmatic"
approvals_reviewer = "user"
approval_policy = "on-request"
sandbox_mode = "read-only"
[projects."/home/<user>"]
trust_level = "trusted"
[projects."/home/<user>/projects"]
trust_level = "trusted"
[projects."/mnt/c/Users/<user>"]
trust_level = "trusted"
[projects."/mnt/c/Users/<user>/projects"]
trust_level = "trusted"
Native Windows config is equivalent for the relevant permission settings:
approval_policy = "on-request"
sandbox_mode = "read-only"
[windows]
sandbox = "elevated"
codex doctor --summary in WSL2 reports:
Codex Doctor v0.132.0 · linux-x86_64
✓ config loaded
✓ sandbox restricted fs + restricted network · approval OnRequest
The lower-level sandbox profile does enforce read-only correctly:
codex sandbox linux --permissions-profile :read-only -C /home/<user>/projects/<repo> touch /tmp/codex-readonly-probe
Result:
touch: cannot touch '/tmp/codex-readonly-probe': Read-only file system
For comparison, :workspace allows a harmless write probe:
codex sandbox linux --permissions-profile :workspace -C /home/<user>/projects/<repo> touch /tmp/codex-workspace-probe
Result: command exits successfully.
This appears to be a WSL2/Linux TUI menu issue rather than a sandbox enforcement issue, because read-only enforcement works when selected explicitly via CLI/profile.
2 Comments
Additional observation: in native Windows PowerShell,
/permissionsshowsRead Only (current). In WSL2, none of the displayed options are marked(current).This suggests the WSL2 TUI is running with an effective read-only configuration, but the
/permissionsmenu does not include the preset corresponding to the active state, so it cannot mark any option as current.This feels like a control-plane truthfulness bug more than a missing menu row.
If the effective profile is read-only,
/permissionsshould always be able to render that exact active state, even if the platform cannot transition to every option from that screen. Otherwise users can't audit whether they're currently constrained, merely configurable, or silently on a fallback profile.A clean split would be
current effective profilevsavailable transitions.