I found two security issues that look worth fixing before this lands.

1. Heredoc prefix parsing still ignores shell variable assignments.

parse_heredoc_command_words currently skips variable_assignment while reducing a heredoc command to executable words. That means a script such as PATH=/tmp/evil:$PATH cat <<EOF can be represented to execpolicy as just cat. If there is an existing allow rule for cat, the policy path can treat the apparent command as explicitly allowed and bypass the sandbox, while shell execution resolves cat through the attacker controlled PATH.

Recommended fix: reject variable_assignment in the heredoc prefix parser instead of ignoring it. Keep comments allowed if needed, but return None for assignments so the command stays represented as the original shell invocation. Please add a parser regression for PATH=/tmp/evil:$PATH cat <<EOF, and ideally an exec policy regression showing that an existing cat allow rule does not make that command bypass the sandbox.

2. Requested prefix rules are still allowed for complex heredoc parsing.

This PR correctly marks heredoc and file redirect fallback parsing as complex so auto derived amendments are suppressed. But model supplied prefix_rule values still pass through derive_requested_execpolicy_amendment_from_prefix_rule even when used_complex_parsing is true. For example, a heredoc that runs an interpreter from stdin can still surface a durable allow rule for the reduced interpreter argv. If the user approves that amendment once, future different heredoc bodies with the same argv prefix can match the persisted rule.

Recommended fix: apply the same complex parsing gate to requested amendments. In practice, compute requested_amendment only when auto_amendment_allowed is true, otherwise set it to None. Please add a regression where a heredoc command with a model supplied interpreter prefix rule still returns proposed_execpolicy_amendment: None.

I think the first item is directly in the parser lines touched here. The second item is a related policy boundary issue that this PR is now depending on, so it would be best to close both while the heredoc policy behavior is being tightened.

Thanks for the Slack discussion. I agree this should not block the PR.

The risky case is a broad saved rule like cat or python. This PR prevents that.

The remaining case saves the exact shell command. That is much less reusable.

It also keeps the normal user flow where an approved command can offer a saved rule.

So I am good with this PR. If we want stricter behavior for complex shell scripts, we can handle that as follow up work.