[ENHANCEMENT] use a true shell parser to preprocess terminal commands

[drzraf]

Problem (one or two sentences)

The shell parser is in charge of identifying command executions (commands, pipeline, shellscripts), evaluate their safety by extracting and comparing individual commands with known, user-defined, allow/deny lists.

It's only one level of sandboxing around the LLM but a very important one since it condition safety and automation.

It's currently regexp-based (split/trim/replace/...)

and consequently doesn't handle advanced shell constructs (some loops and a variety of built-in semantics). ENV=var cmd is just one such example (ENV=var is suggested as the command to allow/deny). A regexp-based validator will never fulfill its mandate (which implies understanding the underlying language at 100%)

.ts shell parsers actually exist:

• https://github.com/webpro-nl/unbash
• https://github.com/tree-sitter/tree-sitter-bash
• We even saw a proprietary/vibe-coded one inadvertently published today

The trade off at stake is code simplicity and readability for enhanced command analysis/review & sandboxing.
But I tend to think such a crucial component deserves it (many people don't use any VM/container/LSM layer that would "contain" what their LLM-enabled code-editor is able to execute).

A shell parser alone won't make the LLM safe to use: many evasions [planned or not] are still possible

But it :

1. Drastically reduces the possibility of weaknesses due to parsing errors/inaccuracies.
2. Increases the abilities to preemptively analyze complex terminal pipelines
3. Bring allow/deny lists at the syntactic level: more detailed (specific arguments combinations), more powerful, more organized and more importantly, make allow/deny list actually 100% reliable.

Context (who is affected and when)

Users of the terminal who allow/deny specific commands issued by the model

Desired behavior (conceptual, not technical)

• Ensure that allowed commands stay allowed within complex shell command-line, independently from specific environment
• Ensuring that denied commands are identified even in complex shell constructs
• Providing more powerful command/argument check-list without relying upon unreliable & inconvenient regexp
• Possible positive outcome regarding environment variable protection/filtering (somehow limiting the impact of an untrusted or malicious LLM or MCP)

Constraints / preferences (optional)

The parser must:

• be fast (parser's latency could be tested against the current, regexp-based, implementation)
• have been previously battle-tested on an existing bash testsuite (including quoting/encoding/...)
• not break on a specific shell (sh/zsh/csh) or at least gently fallback.
• be maintainable (not spreading across Roo codebase, not over engineered, ideally relying upon an existing and reliable implementation)

It should allow user to setup powerful security policy (for efficient & safe command auto-execution) covering:

• commands
• arguments (to some degree)
• environment (could be about using, displaying or setting certain variables) [nice to have]
  with user-configured preferences
• handle PATH tricks and alias (that would lead to execute a denied command or denying an allowed command)

It could also represent an appreciable fence over sudo usage: If bridged with well-known lists, it could even let users whitelisting specific sudo-enabled commands.

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

Use a shell parser

Trade-offs / risks (optional)

• code simplicity and readability vs enhanced command analysis (user preference regarding dangerous/safe commands, overall sandboxing)
• specific shell features (sh vs bash sv zsh)
• environment inheritance (environment variable, aliases handling, custom functions, init/rc files)

[roomote-v0]

I have analyzed this issue and here is my proposed implementation plan:

Current State

The shell command parsing lives in two main files:

• src/shared/parse-command.ts -- Uses the shell-quote npm package with extensive regex pre/post-processing (placeholder substitution for redirections, arithmetic expressions, parameter expansions, subshells, variables, quotes). It splits compound commands into sub-commands by chain operators (&&, ||, ;, |, &).
• src/core/auto-approval/commands.ts -- Consumes parseCommand() to split command chains, then applies allow/deny list logic via longest-prefix matching. Also has a purely regex-based containsDangerousSubstitution() for detecting dangerous parameter expansions, here-strings, zsh glob qualifiers, etc.

The core weakness, as the issue describes, is that the regex+placeholder approach cannot reliably handle all shell grammar constructs (e.g., ENV=var cmd, complex quoting, nested subshells, here-docs, process substitution nesting).

Proposed Approach: Integrate tree-sitter-bash

I propose replacing the regex-based parsing in parse-command.ts with tree-sitter-bash (via the web-tree-sitter WASM runtime, which works in Node.js without native compilation). This gives us a proper AST for bash/sh commands.

Why tree-sitter-bash over alternatives

• unbash: Minimal project, limited shell coverage, not battle-tested against a full bash test suite.
• shell-quote (current): Not a real parser -- it tokenizes but does not understand shell grammar.
• tree-sitter-bash: Mature, widely used (powers GitHub syntax highlighting), has comprehensive grammar coverage for bash/sh constructs including loops, conditionals, here-docs, process substitution, compound commands, and variable assignments. It meets the issue's requirement of being "battle-tested on an existing bash testsuite."

Implementation Plan

1. Add dependencies

• Add web-tree-sitter and tree-sitter-bash (WASM) to src/package.json.
• The WASM approach avoids native compilation issues and works cross-platform.

2. Create src/shared/shell-parser.ts (new module)

• Initialize tree-sitter with the bash grammar WASM.
• Expose a parseShellCommand(input: string) function that returns a structured representation:
  • List of simple commands (each with: command name, arguments, env prefix assignments)
  • Pipeline and chain operator relationships (&&, ||, ;, |)
  • Subshell/command-substitution contents (recursively parsed)
  • Redirections associated with each command
• Provide a extractCommandNames(input: string): string[] helper that flattens the AST to just the executable command names (what the allow/deny logic needs).
• Graceful fallback: if tree-sitter parsing fails (e.g., non-bash syntax from zsh/csh/PowerShell), fall back to the current shell-quote-based logic so we never break existing behavior.

3. Refactor src/shared/parse-command.ts

• Replace the internal parseCommandLine() function (with all its regex placeholder logic) with calls to the new shell-parser.ts.
• Keep the same public API (parseCommand(command: string): string[]) so downstream consumers (commands.ts) are unaffected.
• The regex placeholder approach and direct shell-quote usage can be removed.

4. Enhance src/core/auto-approval/commands.ts

• Update getCommandDecision() to use the richer AST data from the new parser:
  • Properly identify the actual command name even with ENV=var cmd prefix assignments.
  • Detect subshell commands for recursive allow/deny checking.
  • Improve containsDangerousSubstitution() by checking AST node types instead of regexes (e.g., process_substitution, command_substitution nodes).
• Allow/deny matching can optionally support argument-level patterns (future enhancement, not required for initial implementation).

5. Tests

• Add unit tests in src/shared/__tests__/shell-parser.spec.ts covering:
  • Simple commands, pipelines, chains
  • ENV=var cmd patterns
  • Nested subshells and command substitutions
  • Complex quoting (single, double, escaped)
  • Here-docs and here-strings
  • Fallback behavior for unparseable input
• Update existing tests in src/core/auto-approval/__tests__/commands.spec.ts to cover the new parsing behavior.
• Ensure all existing tests continue to pass (backward compatibility).

Scope / Non-Goals for Initial PR

• In scope: Replace regex-based command splitting with tree-sitter AST, handle ENV=var cmd, improve subshell detection, maintain backward compatibility.
• Out of scope for initial PR (but enabled by this work): argument-level allow/deny rules, PATH/alias resolution, sudo-aware policies, GTFOBins integration. These can be follow-up enhancements once the parser foundation is in place.

Risk Mitigation

• Performance: tree-sitter WASM parsing is fast (sub-millisecond for typical command strings). We can benchmark against the current implementation.
• Bundle size: The bash WASM grammar is ~200KB. This is a one-time cost for significantly improved correctness.
• Fallback: Unparseable input gracefully falls back to the current approach, so no regression for edge cases.

Please mention @roomote in a comment saying that you approve this plan, and I will proceed with the implementation.