[ENHANCEMENT] Provide auto-execute for EXACT commands (prefix is inherently unsafe)

[nh2]

Problem (one or two sentences)

Provide a way to make auto-execute approvals require exact matches of the commands.

With the current way (command prefix) thi auto-execute feature is very unsafe.

For example, if you have approved git show, Roocode also permits

git show > ~/.ssh/my_id_rsa

thus easily wiping your SSH private key.

This could be easily prompt-injected. For example, a website the user tells the model to read (whose contents are under somebody else's control), could prompt-inject Roocode to compel the model to run the above.

Beyond just destroying files like in my example, it can also lead to easy prompt-injected code execution, because it could > .git/hooks/pre-commit to write to a file that gets executed automatically, such as a git pre-commit hook.

So it is already very unsafe to use any benign command like git show with prefix approval, because shell redirection can destroy any file, including outside of the vscode workspace.

So auto-execution things like git or other benign commands is impossible for security-conscious users.

Thus the request: Make it possible to allow exact comands.

Allowing git show exactly means allowing only exactly those characters, e.g. git show > or git show would not be permitted.

This could be implemented as a bool flag "require exact match" (or better, an explicit "allow prefix match") stored along with each entry in the list of allowed commands. Alternatively (and probably better, because easier to search through), there'd be 2 lists: Allowed Auto-Execute Commands (exact) and Allowed Auto-Execute Commands (prefix). The description text under Allowed Auto-Execute Commands (prefix) should also explain that prefixes are not as safe as exact matches due to the above issue, giving e.g. git show > ~/.ssh/my_id_rsa as an example of caution.

In the Running ... Auto-approved commands GUI in the prompt window where the user can retrospectively click the buttons use Add to allowed list or Add to denied list, the single Add to allowed list button would be replaced with two buttons Add to allowed list (exact) and Add to allowed list (prefix).

This would be especially useful because that way one can without fear add commands such as ./run_my_tests.sh to the exact-match list.

Better, but slightly more complicated way to do this

Limiting to fixed commands might be too rigid, because it allows e.g. git show but not git show 123123ef.

The real problem so far with the prefix commands is that they allow arbitrary shell stuff at the end.

This problem could be avoided by not using the shell, but controlling what arguments get passed into execv().

So I think as the best solution (and replacement of the "exact" commands approach above, because it includes that) would be this list of auto-execute rules: "Allowed Auto-Execute Commands (with args)". These would not be allowed to be run as shell scripts, but instead as execv() calls.

For each rule entry, it would be stored as a JSON object; here some examples:

{
  "argv_matcher": ["git","show", { "tag": "1-argument" }]
}

The above would allow invoking ["git","show", ...] with exactly 1 additional positional argument.

{
  "argv_matcher": ["git","show", { "tag": "0-or-more-arguments" }]
}

The above would allow invoking ["git","show", ...] with 0 or more arbitrary additional positional arguments.

{
  "argv_matcher": ["git","show", { "tag": "optional", "value": "--short" } , { "tag": "0-or-more-arguments" }]
}

The above would allow git show abc123, git show --short abc123, and so on.

{
  "argv_matcher": ["git","show", { "tag": "optional", "value": ["--format", { "tag": "one-of": "value": ["short", "pretty"] } ] } , { "tag": "0-or-more-arguments" }]
}

The above would allow git show abc123, git show --format short abc123, git show --format pretty abc123, and so on.

So the representation would be a JSON-serialised grammar of what's allowed.

Optionally, for the user, we could also make up a language to make this shorter to read or write, such as git show (--format=(short|pretty))? **, but maybe that is not necessary and the user could read the JSON directly for the beginning.

Since producing suggestions to add to the allow-list isn't as easy as with command prefixes or exact command maches (simple yes/no answer for a string so far), and it would be a more complicated suggestion such as "do you want to allow to add { "tag": "optional", "value": ["--format", { "tag": "one-of": "value": ["short", "pretty"] } ] } to the existing git show rule?", we would then let the LLM itself suggest such modifications to the rules, which the user can then approve (checkmark) or reject (cross).

This would allow users to build exactly approved commands that they can run safely.

It would also unlock for the user another way to do things: To allow a single command ./my-command-checker ** as the only approved command, where they can write that program ./my-command-checker themselves in an arbitrary language, that checks the commands given and executes them. This is a bit like an MCP server but much easier, because the user does not have to build a full MCP server including protocol and so on.

Context (who is affected and when)

Any user who wants some bening commands to be executed automatically.

Desired behavior (conceptual, not technical)

Add more restricted ways to auto-approve command exeuction.

Constraints / preferences (optional)

No response

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)

No response

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and explored the codebase. Here's my proposed implementation plan for adding exact match support to auto-execute commands:

Current State

The auto-execute command approval system currently uses prefix matching only:

• Commands are stored in allowedCommands and deniedCommands string arrays
• The matching logic in src/core/auto-approval/commands.ts uses startsWith comparison
• As noted in the issue, this is unsafe because git show also allows git show > ~/.ssh/my_id_rsa

Proposed Implementation

I propose adding a new allowedExactCommands array for exact matches, keeping the existing allowedCommands for prefix matching but renaming it conceptually in the UI.

1. Data Model Changes (packages/types/src/global-settings.ts)

• Add allowedExactCommands: z.array(z.string()).optional() to the schema
• This keeps backward compatibility with existing configs

2. Command Matching Logic (src/core/auto-approval/commands.ts)

• Add findExactMatch() function that requires exact string equality (case-insensitive, trimmed)
• Modify getSingleCommandDecision() to check exact matches first before prefix matches
• Exact matches take precedence over prefix matches (more specific = higher priority)

3. Settings UI (webview-ui/src/components/settings/AutoApproveSettings.tsx)

• Add a new "Allowed Auto-Execute Commands (Exact Match)" section above the existing prefix section
• Update the existing section label to "Allowed Auto-Execute Commands (Prefix Match)" with a warning about shell redirection
• Add description explaining the security difference between exact and prefix matching

4. Chat Command Selector (webview-ui/src/components/chat/CommandExecution.tsx and CommandPatternSelector.tsx)

• Update the "Add to allowed list" functionality to offer two options:
  • "Allow (exact)" - adds to allowedExactCommands
  • "Allow (prefix)" - adds to allowedCommands
• Show the match type (exact/prefix) in the status indicator

5. Localization (locales/ and webview-ui/src/i18n/locales/)

• Add translation keys for new labels and descriptions
• Include security warnings about prefix matching

Key Design Decisions

1. Separate arrays instead of a single array with match type objects - This is simpler for migration, storage, and UI rendering
2. Exact match takes priority - If a command matches both an exact rule and a prefix rule, exact wins
3. Case-insensitive matching - Consistent with current behavior
4. Denied commands remain prefix-based - Prefix denial is safer (blocks more)

Example Behavior

Command	Exact List	Prefix List	Result
git show	git show	-	Approved
git show abc123	git show	-	Ask user
git show > file	git show	-	Ask user
git show	-	git	Approved
git show > file	-	git	Approved (current unsafe behavior)
git show	git show	git	Approved (exact match)

This approach addresses the core security concern while maintaining backward compatibility.

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

[nh2]

@roomote I approve this plan, but I think exact commands should not be "case-insensitive, trimmed", but "case-sensitive, not trimmed", to make them truly exact. For example, git and giT can be different programs on Linux.

[robertjmcintyre]

I came across this issue (in a benign manner) today as well, and it is concerning. The model being able (via Roo) to redirect output of auto-approve commands into sensitive files risks possible system issues.

Would performing validation on the output/target path be sufficient, do you think, @nh2? There's already that ability for file reads. While not a long-term implementation of your feature suggestion, it might be a useful mitigation.