feat: auto-approve commands based on risk level

[KJ7LNW]

Context

This is similar to Cline's competing "auto-approve safe commands" feature—but approval in this PR is much smarter: command risk analysis is performed based on formal predicate logic.

For example, when set to read-only:

Roo will auto-execute only commands that have formally matched the predicate logic for read only (see below):

Implementation

Risk levels are formally defined through predicate logic and the model determines the risk level after producing in the command and risk analysis, so risk level determination is retrospective and accurate. When "disabled" (default), all system instructions for related risk analysis are excluded, so there is no change to Roo's default system prompt size.

Risk level total ordering:
    readOnly < reversibleChanges < complexChanges < serviceInterruptingChanges < destructiveChanges

S = F ∪ P ∪ N ∪ H ∪ M ∪ Z ∪ E
    F = storage: files, databases, git repos, disks, …
    P = processes, services, VMs, containers, …
    N = network configs, …
    H = hardware, physical controls, …
    M = memory states, locks, resources, …
    Z = security: permissions, keys, tokens, …
    E = temporal state: tasks, cron, timers, …

s₀ ∈ S:          initial state before C
s′ ∈ S′:         final state after C
atoms(x):        minimal addressable units
content(x,s):    accessible atoms in s
a ∉ content(x,s) if deleted, truncated, overwritten, corrupted, encrypted with lost key

C = {c₁,c₂,…,cₙ}:  command sequence
T = Tr ∪ Tm: intended targets
    Tr ⊆ S: read-only targets
    Tm = {x | x ∈ S ∨ (x ∉ S ∧ x ∈ S′)}: modifiable/creatable targets
R = {x | (x ∈ s₀ ∧ c(x) ≠ x) ∨ (x ∉ s₀ ∧ x ∈ S′)}: modified/created elements
c⁻¹(R): inverse operations

r(C)=readOnly ⟺
    Tm = ∅ ∧
    R = ∅ ∧
    (Tr ≠ ∅ ∨ Tr = ∅) ∧
    S′ = S ∧
    (∀x ∈ S: content(x,s₀) = content(x,s′))

r(C)=reversibleChanges ⟺
    Tm ≠ ∅ ∧
    ∀s₀ ∈ S: ∃c⁻¹: (c⁻¹(c(s₀))=s₀) ∧ (|c⁻¹|=1) ∧
    R = Tm

r(C)=complexChanges ⟺
    ¬destructiveChanges ∧
    Tm ≠ ∅ ∧
    ∃s′=c(s₀):
        (R ⊆ Tm) ∧
        (∀x ∈ R:
            (∃p ⊂ atoms(x): p ∈ content(x,s′)) ∧
            (∃q ⊂ atoms(x): q ∉ content(x,s′) ∧ ¬∃c⁻¹: c⁻¹(c(q))=q))

r(C)=serviceInterruptingChanges ⟺
    ∃p ∈ Tm ∩ P, ∃t₁ ∈ ℝ⁺:
        A(p,0) ∧
        ¬A(p,t₁) ∧
        ((∃t₂ > t₁: A(p,t₂)) ∨ p ∉ s′)
    where A(x,t): availability at time t

r(C)=destructiveChanges ⟺
    (∃x ∈ s₀: x ∉ s′) ∨
    (R ⊈ Tm) ∨
    (∃x ∈ s₀:
        content(x,s₀) ≠ ∅ ∧
        (∀a ∈ atoms(x): a ∉ content(x,s′)))

For compound commands:
    r(C) = max{r(c₁), r(c₂), …, r(cₙ)}

### Usage:
<execute_command>
<command>Your command here</command>
<risk_analysis>[reasoning]</risk_analysis>
<risk>Risk level here</risk>
<cwd>Working directory path (optional)</cwd>
</execute_command>

Screenshots

This PR provides greater command safety and user feedback before running commands:

and allows users to select the auto-approve risk level they are comfortable with:

How to Test

1. Open settings and verify new 'Allowed Auto-Execute Risk Level' option
2. Set different risk levels and verify command auto-approval behavior
3. Test commands of varying risk levels to ensure proper validation
4. Verify error handling for invalid risk levels

Get in Touch

Discord: KJ7LNW

---

Important

Introduces auto-approve feature for commands based on risk levels, updating settings, UI, and logic across multiple files.

• Behavior:
  • Introduces auto-approve feature for commands based on risk levels in global-settings.ts and terminal.ts.
  • Risk levels include readOnly, reversibleChanges, complexChanges, serviceInterruptingChanges, and destructiveChanges.
  • Adds logic to determine and validate risk levels in terminal.ts.
• Settings:
  • Adds commandRiskLevel setting in global-settings.ts and ClineProvider.ts.
  • Updates SettingsView.tsx and AutoApproveSettings.tsx to include risk level selection.
• UI:
  • Updates ChatView.tsx and CommandExecution.tsx to display risk levels and analyses.
  • Adds translations for risk levels in multiple locale files.
• Functions:
  • Adds utility functions isRiskAnalysisEnabled, isValidRiskLevel, and isRiskAllowed in terminal.ts.
  • Modifies executeCommandTool in executeCommandTool.ts to handle risk levels.

^{This description was created by for c6b43fb77746c38c2622188b20d865b4c01c070e. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7e088aef189df631f9bf840cbc7cebeccf43d5e9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

The pull request introduces a significant number of changes across various components, primarily focused on adding risk level parameters and metadata. While these changes are related to the new feature of risk level handling, the size of the pull request is quite large, with 22 files changed and over 1300 lines added.

To improve reviewability and maintainability, consider splitting the pull request into smaller, more focused pull requests. Here are some suggestions on how to split the changes:

1. Core Logic Changes: Group changes related to the core logic, such as modifications in src/core/Cline.ts, src/core/assistant-message/index.ts, and src/core/tools/executeCommandTool.ts, into one pull request.

2. UI Component Updates: Separate the changes related to UI components, like those in webview-ui/src/components/chat/ChatRow.tsx and webview-ui/src/components/settings/AutoApproveSettings.tsx, into another pull request.

3. Testing and Validation: Consider having a separate pull request for updates to tests and validation logic, such as changes in src/core/tools/__tests__/executeCommandTool.test.ts and webview-ui/src/utils/commandRiskUtils.ts.

By splitting the changes into these categories, it will be easier for reviewers to focus on specific areas and ensure thorough review and testing. Thank you for your hard work on this feature!

[KJ7LNW]

translations coming to a pull request near you ...

[KJ7LNW]

languages are already

[adamhill]

It would be nice to add this Markdown table at /src/core/prompts/tools/executeCommandTool-explainer.md (so it will sort next to the .ts file) to explain a little better what its doing by letting you read through the rules in English, for non-math nerds. I don't think I can add files to the PR, so I am leaving a comment.

This was a really cool & practical example of using symbolic math to solve common CS problems we have to deal with.

Thanks!

Symbol	Explanation
S	Represents the complete system state, including all files, processes, and configurations.
c	Represents the command operation being executed.
s	Represents an individual state within the complete system state S.
∀	Universal quantifier, meaning "for all". For example, ∀s ∈ S means "for all states s in set S".
∈	Element of, meaning "is a member of". For example, s ∈ S means "state s is a member of set S".
=	Equals, meaning the system state remains unchanged.
∃	Existential quantifier, meaning "there exists". For example, ∃c⁻¹ means "there exists an inverse command".
c⁻¹	Inverse of the command operation c, which undoes the changes made by c.
≠	Not equal, meaning the state has changed.
∧	Logical AND, meaning both conditions must be true.
∨	Logical OR, meaning at least one of the conditions must be true.
t	Represents time.
A(s, t)	Availability function, where A(s, t) = 0 means a service is unavailable for state s at time t.
d	Represents data or information being removed from the system.
D	Represents the set of all data or information in the system.
⊂	Proper subset, meaning d(s) is a subset of s but not equal to s.
¬	Negation, meaning "not". For example, ¬∃f means "there does not exist a function f".
f	Represents a recovery function attempting to restore the original state.

[KJ7LNW]

It would be nice to add this Markdown table at /src/core/prompts/tools/executeCommandTool-explainer.md

great idea!

This was a really cool & practical example of using symbolic math to solve common CS problems we have to deal with.

I really enjoyed predicate logic it and set notation in some of my early computer science discrete math courses, but it's funny that I have only really used them for any practical purpose as part of artificial intelligence instructions (oh yeah, and whiteboard notes!).

[KJ7LNW]

this is ready for review

[ellipsis-dev]

This pull request is quite large, with 34 files changed and over 2000 lines added. It seems to introduce a comprehensive set of features related to command risk levels and risk analysis.

To improve the review process, consider splitting the changes into smaller, more focused pull requests if possible. For example:

1. Core Functionality: Changes related to the core logic of risk analysis and command execution (e.g., src/core/Cline.ts, src/core/tools/executeCommandTool.ts).
2. Webview Integration: Updates related to the webview components and settings (e.g., webview-ui/src/components/chat/ChatRow.tsx, webview-ui/src/components/settings/AutoApproveSettings.tsx).
3. Localization: Changes related to localization files (e.g., webview-ui/src/i18n/locales/en/settings.json).

This will make it easier to review and test each part independently. Thank you!

[KJ7LNW]

Reddit stats, people really want this PR to merge:

https://www.reddit.com/r/RooCode/comments/1lmzm6l/autoapprove_commands_based_on_risk_level_pending/

[daniel-lxs]

This is a solid implementation and functions as expected when tested. However, the addition of ~2,000 tokens to the system prompt for risk analysis is concerning. If the context window fills up, there's a risk the model will ignore these instructions, especially with weaker models, leading to potentially incorrect risk assertions.

I believe that allowing people to whitelist and eventually blacklist command and command prefixes is a pretty simple but effective approach.

[KJ7LNW]

This is a solid implementation and functions as expected when tested

Awesome, thanks for testing. I've been using it almost every day for months and it works great, even in very large contexts.

[KJ7LNW]

This is a solid implementation and functions as expected when tested

Awesome, thanks for testing. I've been using it almost every day for months and it works great, even in very large contexts.

Hi @daniel-lxs, what do you think about making this an experimental feature?

This would give users a chance to test it, and since it is experimental it can always be pulled out if you find that it is not beneficial to the project.

[mrubens]

This is definitely a clever idea, but it seems hard to get right - I don't really trust the LLMs to make the right call on risk level without human oversight.

My energy is more around using the LLMs to generate good suggested prefixes for allowlisting commands inline (and maybe eventually blocklisting), but still with the human making the final call on which commands execute in a deterministic way. I'd rather use the pixels in the command execution area to support this interaction.

Thank you for your efforts on this one, but I am going to close it for now.

[KJ7LNW]

This is definitely a clever idea, but it seems hard to get right - I don't really trust the LLMs to make the right call on risk level without human oversight.

I understand your concern, which is why I thought an experimental flag could be appropriate.

I've been using this every day since April and it works great with Sonnet 3.x,4 and Gemini 2.5.

I'm not pressuring you, this is your project. I hope you give it some more thought and consider letting other users test it to see how it how it performs.