Windows: /codex:review and /codex:rescue silently return empty results because plugin forces broken sandbox modes

Summary

On Windows with Codex CLI 0.133.0, /codex:review and /codex:rescue (default read-only mode) consistently return useless output — "I could not inspect the working tree because read-only shell commands... failed with sandbox policy/setup errors" — because the plugin's runtime hard-codes sandbox modes the underlying Codex CLI cannot honor on Windows.

Root cause

Codex CLI 0.133.0 on Windows fails immediately with windows sandbox: spawn setup refresh (exit -1 in 0ms) under both --sandbox read-only and --sandbox workspace-write. Only --sandbox danger-full-access actually works. Tracked upstream as openai/codex#24259.

The plugin currently forces one of those broken modes in every thread/start / thread/resume request:

• runAppServerReview → sandbox: "read-only" (hardcoded)
• executeTaskRun → sandbox: request.write ? "workspace-write" : "read-only"

So every PowerShell command Codex tries dies in 0 ms, and the model returns a final answer of "I couldn't inspect anything." The user sees a clean-looking review/rescue that says nothing.

Worse: even users who work around the CLI bug by setting sandbox_mode = "danger-full-access" in ~/.codex/config.toml are still broken, because the plugin overrides that config by passing an explicit sandbox in the app-server request.

Reproduction

1. Windows 10/11 x86_64
2. npm install -g @openai/codex (0.133.0)
3. codex login
4. Install this plugin in Claude Code
5. In a git repo with any uncommitted change, run /codex:review
6. Observe the empty review

Proposed workaround

Coerce the sandbox to danger-full-access on Windows only — both broken modes redirect to the only mode the CLI can actually run. No effect on macOS/Linux.

In plugins/codex/scripts/lib/codex.mjs:

function coerceWindowsSandbox(sandbox) {
  if (process.platform !== "win32") return sandbox;
  if (sandbox === "read-only" || sandbox === "workspace-write") {
    return "danger-full-access";
  }
  return sandbox;
}

Wrap the sandbox: field in both buildThreadParams and buildResumeParams:

sandbox: coerceWindowsSandbox(options.sandbox ?? "read-only"),

Verified locally:

• /codex:review now produces a real finding on a real diff
• /codex:rescue (via the codex-rescue subagent, background dispatch) returns in ~45s; Codex itself reports Sandbox mode: danger-full-access
• Plugin test suite (node --test tests/*.test.mjs): identical 77 pass / 9 fail before and after the patch (the 9 are pre-existing Windows-only failures — taskkill /PID arg munging under Git Bash, Unix-socket tests, state-dir resolution — none related to thread params)

Alternative

Less invasive: on Windows, omit the sandbox field entirely from buildThreadParams/buildResumeParams so the user's ~/.codex/config.toml setting wins. Cleaner semantically, but doesn't help users who haven't set the workaround in config.

Environment

• OS: Windows 11 Pro x86_64
• Node: 24.13.0
• npm: 11.6.2
• Codex CLI: 0.133.0
• Plugin: openai-codex@1.0.4

Related: openai/codex#24259

Start in plugins/codex/scripts/lib/codex.mjs by tracing buildThreadParams and buildResumeParams, then check how their sandbox values reach thread/start and thread/resume. Verify the Windows handling against the reported Codex CLI behavior, preserve non-Windows behavior, and run node --test tests/*.test.mjs; done means review and rescue no longer return empty results on Windows.