adversarial-review (and presumably other companion commands) fail with EPERM creating job-state dir under ~/.claude/plugins/data/codex-openai-codex/state/... inside a Claude Code session

Summary

codex-companion.mjs adversarial-review fails immediately with EPERM: operation not permitted, mkdir '.../state//jobs' when invoked from inside a Claude Code session — both via a normal tool-initiated Bash call and via Claude Code's !-prefixed "run in your own shell" mechanism. The identical mkdir -p for that exact path succeeds instantly when run from a completely separate Terminal window that was not spawned by Claude Code.

Environment

• OS: macOS 26.5.2 (build 25F84)
• Claude Code: 2.1.223
• codex-plugin-cc: 1.0.6 (path: ~/.claude/plugins/cache/openai-codex/codex/1.0.6/)
• Project: local git repo, nothing unusual about the path

Reproduction

/codex:adversarial-review --reasoning-effort xhigh <some-file>

and

node ~/.claude/plugins/cache/openai-codex/codex/1.0.6/scripts/codex-companion.mjs adversarial-review "--reasoning-effort xhigh <some-file>"

Run from inside a Claude Code session (either as a skill call, or tool call or via ! ):

EPERM: operation not permitted, mkdir '/Users//.claude/plugins/data/codex-openai-codex/state/-/jobs'

Run the exact same mkdir -p ~/.claude/plugins/data/codex-openai-codex/state/ from an ordinary iTerm2.app window (not launched from Claude Code): succeeds immediately.

What I ruled out

• Not a Unix permissions problem: stat shows drwxr-xr-x, owned by the current user, on every directory in the chain (~/.claude, ~/.claude/plugins, .../data, .../codex-openai-codex, .../state).
• No ACLs (ls -leO@ empty), no immutable/uchg flags (stat -f %f → 0), filesystem is the normal writable data volume (not the sealed system volume).
• Not fixable via Claude Code's own sandbox.filesystem.allowWrite project setting — adding /.claude/plugins/data/codex-openai-codex/** and **/.codex/** there does get reflected in the resolved sandbox policy (confirmed the exact path appears in the tool's write allowlist) but the mkdir still fails, implying something else in Claude Code's process-tree sandboxing still blocks it regardless of that setting.
• Confirmed it's specific to running inside/under a Claude Code-spawned process: identical command in a genuinely independent terminal works immediately with no config changes.

Impact

Any user running /codex:review or /codex:adversarial-review from inside Claude Code on an affected machine gets a hard failure before Codex even starts, with no actionable error message pointing at the real cause.

Possible directions

• Document/support relocating the job-state directory via CODEX_COMPANION_STATE_DIR (referenced in #332) to a path outside ~/.claude/plugins, since that subtree appears to fall inside whatever sandboxing Claude Code applies to its own process tree.
• Consider defaulting the companion's state directory to somewhere outside ~/.claude/plugins (e.g. ~/.codex/state or an OS temp dir) since ~/.claude/plugins is Claude Code's own plugin-management tree and apparently gets special protection in some environments.

Start with scripts/codex-companion.mjs and trace how it selects the job-state directory, including the CODEX_COMPANION_STATE_DIR reference from issue #332. Reproduce adversarial-review inside Claude Code and from an independent terminal; done means companion commands can create job state in the affected environment or the supported relocation is documented and works.