app-server sandbox stays read-only despite workspace-write request (Claude Code plugin, codex-cli 0.146.0)

Description

Using the Claude Code openai-codex plugin (v1.0.5), Codex tasks invoked with write access enabled (--write, which maps to sandbox: "workspace-write" and approvalPolicy: "never" over the app-server protocol) are still refused all file writes and shell commands with blocked by policy, and Codex self-reports running under a read-only sandbox despite the write-capable request.

This looks like the same underlying failure mode as #14068 (app-server sandbox bypass/config not propagating to tool child processes), but reproduced on a much newer CLI version (0.146.0 vs. 0.111.0/0.112.0 in that issue), so filing separately in case the root cause differs or a regression was reintroduced.

Environment

• codex-cli version: 0.146.0 (also reproduced on 0.142.5 before upgrading)
• OS: Windows 11 (10.0.26200)
• Invocation path: Claude Code plugin openai-codex/codex v1.0.5, via the app-server protocol (codex-companion.mjs -> runAppServerTurn), not codex exec
• Shell used by Codex for tool calls: Windows PowerShell 5.1

Steps to reproduce

1. Initialize an empty git repo, e.g. C:\Users\rushi\.claude\jobs\c1f92ba6\tmp\codex_test.
2. Start a Codex app-server task turn with sandbox: "workspace-write" (i.e. the equivalent of passing --write through the Claude Code plugin's codex-companion.mjs task --write).
3. Ask Codex to create a file, e.g.:

> Create a new file named hello.txt containing the single line "codex write test ok", then create add.py with a simple add(a, b) function. Then run git add -A && git commit -m "codex write test".

Expected behavior

With sandbox: "workspace-write" requested, Codex should be able to write files inside the workspace root and run the git commands without being blocked.

Actual behavior

Every write attempt is declined:

Running command: powershell.exe -Command "Set-Content -LiteralPath hello.txt -Value 'codex write test ok'"
Command declined: ... (exit -1)

Codex's final message:

hello.txt: failed. Evidence: the write command using Set-Content -LiteralPath hello.txt -Value 'codex write test ok' was rejected with blocked by policy. add.py: failed. Evidence: the write command using Set-Content -LiteralPath add.py ... was rejected with blocked by policy. git commit: failed. Evidence: git add -A; git commit -m "codex write test" did not run because the combined command was rejected with blocked by policy. Additional context: the repo at C:\Users\rushi\.claude\jobs\c1f92ba6\tmp\codex_test exists and git status --short --branch reported ## No commits yet on master. The current session is running under a read-only sandbox, so file creation and commit are not permitted here.

The job record on disk confirms the write-capable request was actually sent ("write": true recorded for the job), so this is not a client-side flag/wiring issue — the sandbox enforcement itself is not honoring the write-capable configuration for this turn.

This exactly mirrors an earlier real-world failure on this same machine (2026-07-11, codex-cli ~0.111–0.112 era), where a 7-task Flutter implementation plan handed to Codex failed immediately because "this session is running with a read-only filesystem sandbox and approval policy: never," blocking all edits, builds, and commits.

Related

• #14068 — same symptom (app-server sandbox/approval bypass not propagating to child tool processes), different version range.