Codex CLI /permissions omits Read-only in WSL2 but shows it in Windows PowerShell

Open 💬 2 comments Opened May 20, 2026 by RE-codes

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.toml sets sandbox_mode = "read-only"
  • codex --help documents --sandbox read-only
  • codex sandbox linux --permissions-profile :read-only ... enforces read-only correctly
  • OpenAI docs say /permissions should 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?

  1. In WSL2, configure Codex with:
approval_policy = "on-request"
sandbox_mode = "read-only"
approvals_reviewer = "user"
  1. Start Codex:
codex
  1. Open the permissions menu:
/permissions
  1. Observe that the menu only shows:
Default
Auto-review
Full Access
  1. Compare with native Windows PowerShell on the same machine and same Codex version, where /permissions includes 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:

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.

View original on GitHub ↗

2 Comments

RE-codes · 3 months ago

Additional observation: in native Windows PowerShell, /permissions shows Read 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 /permissions menu does not include the preset corresponding to the active state, so it cannot mark any option as current.

Keesan12 · 3 months ago

This feels like a control-plane truthfulness bug more than a missing menu row.

If the effective profile is read-only, /permissions should 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 profile vs available transitions.