Windows: nested-quote corruption in pwsh -Command exec_command (200+ failures across 0.148/0.150) + file-read tool rejects workspace files

Environment

Windows 11; codex CLI 0.148.0 and 0.150.1 (both affected); PowerShell 7 as default shell; project AGENTS.md asks for UTF-8 console encoding, so many commands start with [Console]::OutputEncoding=... preambles.

Issue A: pwsh -Command nested-quote corruption in exec_command

Across three days of session rollouts we counted 26 / 15 / 209 occurrences of exec_command failed, all with the same corruption shape — quotes inside the command body get mangled so PowerShell sees interleaved broken quoting:

Intended (model-generated):

pwsh -Command "$env:FORCE_COLOR='0'; ..."

As executed (from session log, verbatim):

pwsh.exe -Command '$env:FORCE_COLOR='"'0'; ...

Typical patterns: '"'0', foreach("'$p, '"'{0}"' -f ...`` — single/double quotes interleaved in ways that can never parse. Failures cluster during heavy multi-file review turns where many long one-liner PowerShell text-processing commands are issued; they occur on both 0.148.0 and 0.150.1 and with multiple model tiers, so it does not look like a single model or single version regression. When the same work is expressed as a script file or simpler commands, it succeeds.

Questions / asks:

• Where is the boundary where these commands get re-serialized (model tool output → shell invocation)? Is there a double-escaping layer on Windows when the command string contains both quote styles?
• Would writing the command to a temp .ps1 and invoking pwsh -File for long commands avoid the corruption?

Issue B: file-read tool reports file "not exposed" for workspace files

The built-in file reading tool intermittently rejects files inside the open working directory with an error to the effect of the file interface does not expose this file (reported through the agent; the exact source string is not from the Claude Code plugin — we verified the plugin never generates that text). Retrying with different sandbox modes did not help. Falling back to Get-Content via shell always works, so the files are present and readable; the tool-level allowlist/path resolution appears to be the problem.

Ask: guidance on what paths the read tool exposes vs. the shell (UNC? long paths? files added after session start?), or a fix if workspace-relative reads are supposed to work.

Notes

• The Claude Code plugin (codex-plugin-cc) only forwards and records item.command events; we verified it does not construct or rewrite these commands, so the corruption source appears to be inside the codex tool-execution chain or the model/tool-call boundary.
• Happy to provide sanitized rollout excerpts with the exact command strings and exit codes if useful.

Start by tracing item.command from codex-plugin-cc into the Windows shell invocation path, then reproduce the nested-quote corruption with a long PowerShell command. Separately, reproduce the workspace file-read rejection and compare its path handling with Get-Content. Done means identifying the responsible boundary and either fixing both behaviors or documenting the supported read paths and a reliable command-execution workaround.