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

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