execpolicy allow rules fail when a quoted argument contains a literal newline

[adamalix]

What version of Codex is running?

0.87.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.2-codex (reasoning high)

What platform is your computer?

Darwin 25.2.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Ghostty 1.2.3

What issue are you seeing?

When a command includes a literal newline inside a double‑quoted string, the command extraction step fails, so execpolicy cannot extract the inner command.

Attempting to debug this with codex-cli yielded the following insights:

tree-sitter-bash produces a valid string node with multiple string_content children when a double‑quoted string contains a literal newline. parse_plain_command_from_node currently only accepts a string with exactly one string_content, so parse_shell_lc_plain_commands returns None in this case.

That means allow rules like ["git","commit"] do not match when a newline is included in an argument to the command and create_exec_approval_requirement_for_command does not set bypass_sandbox. In workspace-write this causes git commit to fail with:

fatal: Unable to create '.../.git/index.lock': Operation not permitted

The same commit succeeds if the body is split into multiple -m flags without a literal newline.

Depending on approval policy and user interaction, Codex may then prompt/escalate to run outside the sandbox, even though a rule allowing git commit exists.

What steps can reproduce the bug?

1. Create a rule file in ~/.codex/rules/ that allows git commit:

prefix_rule(pattern=["git", "commit"], decision="allow")

2. Run Codex with workspace-write sandbox (default, or --sandbox workspace-write).

3. Attempt a commit with a literal newline inside a quoted -m argument:

git commit -m "title" -m "line1
line2"

4. Observe failure:

fatal: Unable to create '.../.git/index.lock': Operation not permitted

5. Compare with:

git commit -m "title" -m "line1" -m "line2"
(This succeeds because the allow rule matches and bypasses the sandbox.)

Example rules and config that successfully replicate this behavior.

What is the expected behavior?

Allow rules like ["git","commit"] should apply even when a quoted argument contains a literal newline, so git commit runs with the same sandbox bypass behavior regardless of newline formatting in the message.

Additional information

This appears to be caused by parse_shell_lc_plain_commands rejecting scripts with literal newlines inside quoted strings, so create_exec_approval_requirement_for_command falls back to the outer zsh -lc argv and cannot match allow rules.

Potentially related issues (context):

#7071

Some tests that are primarily codex-driven which confirm the behavior described above: main...adamalix:codex:execpolicy-multiline-newline-tests