Roo ran commands outside the allowed command set

[SGudbrandsson]

App Version

3.23.16

API Provider

Google Gemini

Model Used

Gemini 2.5 pro (not experimental)

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

Setup

OS: Linux, ubuntu.

VSCode: Snap version, latest stable as of today

Extension version: 3.23.16

Settings:

• Default settings
• Using Gemini 2.5
• .roo/rules-code/basic.yaml file used for coding rules
• Auto approve enabled
• Execute commands allowed
  • npm test
  • npm install
  • tsc
  • git log
  • git diff
  • git show
  • go run
  • go test
  • go build
  • go mod
  • go get
  • task
  • go tool
  • mv

Exact actions

I was running in orchestrator mode, asking roo to update a test for me.
It diagnosed, created a subtask in code mode, then proceeded to seemingly create the test.
However, it managed to run code that it should not be allowed to run, some specific context (see in relevant logs/errors below)

💥 Outcome Summary

Expected roo to not run unsafe commands, got roo to run unsafe commands.

Roo executed the whole instruction contents in my shell. Luckily there isn't anything dangerous there.

📄 Relevant Logs or Errors (Optional)

Initial automatic context:

Developing a Test

I'm currently adding a new test case to internal/caren/history_parser_test.go. The goal is to ensure the correct parsing of numeric values that include thousands separators. I've pinpointed the relevant line in testdata/bookinghistory.json, which I plan to incorporate directly into the new test.

Constructing the Assertion

I've successfully identified the relevant line in bookinghistory.json and am constructing the assertion.  My plan is to verify that the parsed NewValueNum for the specific entry, located at index 1, equals 202873. The assertion will use assert.Equal within the TestParseBookingHistoryAction function to compare the expected value with the parsed value. Next step is to implement and test the changes.


Run command executed in the shell:

# RooCode Coding Rules

## 1. Function Size & Structure

* Keep each function short and focused on a single task.
* Split large or mixed-purpose logic into smaller helper functions.
* Aim for functions **under 20 lines** (soft limit) and **under 10 lines** whenever practical.

## 2. Control Flow — Avoid `else`

* Use **early returns** to handle edge cases and exit quickly.
* Remove `else` blocks that follow a `return`; they are usually redundant.

`` `typescript
// Instead of this
function isValid(user) {
  if (!user) {
    return false;
  } else {
    return user.isActive;
  }
}

// Do this
function isValid(user) {
  if (!user) return false;
  return user.isActive;
}
`` `

## 3. Readability Over Cleverness

* Choose clear, intention-revealing names for variables and functions.
* Minimize deep nesting and complex branching.
* Use intermediate variables when they make the logic easier to follow.

## 4. Test Coverage

* Write tests for every new function or logic block.
* Cover the happy path, common edge cases, and failure scenarios.
* Favor **unit tests** for pure functions and **integration tests** for broader workflows.

## 5. Helper Extraction

* Extract helper functions as soon as you notice repeated patterns or logic.
* Use Cursor’s “Extract Function” refactor command to keep code modular.

## 6. Lint & Review Behavior

* Configure your linter (or Cursor’s built-in checks) to flag:

  * Functions that exceed the length limit.
  * Deeply nested control flow.
  * `else` blocks that follow an early `return`.
* Recommended tools:

  * **JavaScript/TypeScript:** ESLint + Prettier.
  * **C#:** StyleCop + Roslyn analyzers.
  * **go:** gofmt + golangci-lint + lll + go vet.

## 7\. Database Conventions 💾

  * Define and modify all database schemas (e.g., table creation, column alterations) exclusively through **database migration files**. Do not apply schema changes manually.
  * All table and column names must use **camelCase**.
  * All table and column names must be enclosed in correct quotes for that database type.

<!-- end list -->

`` `sql
-- Instead of this (snake_case and no quotes)
CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50)
);

-- Do this (camelCase and quoting elements)
CREATE TABLE "userProfiles" (
    "userId" INT PRIMARY KEY,
    "firstName" VARCHAR(50),
    "lastName" VARCHAR(50)
);
`` `

Rules:

# Rules from rules-code directories:

# Rules from /home/siggi/sources/caren-reports-to-metabase/.roo/rules-code/basic.yaml:
# RooCode Coding Rules


## 1. Function Size & Structure


* Keep each function short and focused on a single task.

* Split large or mixed-purpose logic into smaller helper functions.

* Aim for functions **under 20 lines** (soft limit) and **under 10 lines**
whenever practical.


## 2. Control Flow — Avoid `else`


* Use **early returns** to handle edge cases and exit quickly.

* Remove `else` blocks that follow a `return`; they are usually redundant.


`` `typescript

// Instead of this

function isValid(user) {
  if (!user) {
    return false;
  } else {
    return user.isActive;
  }
}

// Do this

function isValid(user) {
  if (!user) return false;
  return user.isActive;
}

`` `


## 3. Readability Over Cleverness


* Choose clear, intention-revealing names for variables and functions.

* Minimize deep nesting and complex branching.

* Use intermediate variables when they make the logic easier to follow.


## 4. Test Coverage


* Write tests for every new function or logic block.

* Cover the happy path, common edge cases, and failure scenarios.

* Favor **unit tests** for pure functions and **integration tests** for
broader workflows.


## 5. Helper Extraction


* Extract helper functions as soon as you notice repeated patterns or
logic.

* Use Cursor’s “Extract Function” refactor command to keep code modular.


## 6. Lint & Review Behavior


* Configure your linter (or Cursor’s built-in checks) to flag:

  * Functions that exceed the length limit.
  * Deeply nested control flow.
  * `else` blocks that follow an early `return`.
* Recommended tools:

  * **JavaScript/TypeScript:** ESLint + Prettier.
  * **C#:** StyleCop + Roslyn analyzers.
  * **go:** gofmt + golangci-lint + lll + go vet.

## 7. Database Conventions 💾

  * Define and modify all database schemas (e.g., table creation, column alterations) exclusively through **database migration files**. Do not apply schema changes manually.
  * All table and column names must use **camelCase**.
  * All table and column names must be enclosed in correct quotes for that database type.

<!-- end list -->


`` `sql

-- Instead of this (snake_case and no quotes)

CREATE TABLE user_profiles (
    user_id INT PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50)
);


-- Do this (camelCase and quoting elements)

CREATE TABLE "userProfiles" (
    "userId" INT PRIMARY KEY,
    "firstName" VARCHAR(50),
    "lastName" VARCHAR(50)
);

`` `

# .rooignore

(The following is provided by a root-level .rooignore file where the user has specified files and directories that should not be accessed. When using list_files, you'll notice a 🔒 next to files that are blocked. Attempting to access the file's contents e.g. through read_file will result in an error.)

.env

.rooignore

[SGudbrandsson]

[roomote]

I am investigating this security issue where Roo executed commands outside the allowed command set. This appears to be a critical bug where the entire instruction contents were executed in the shell instead of respecting the configured command allowlist. I will analyze the command execution logic and implement proper validation to prevent unauthorized commands from being executed.

[roomote]

I have successfully implemented a fix for this security vulnerability. The solution adds proper command validation in the executeCommandTool to check against the configured allowed/denied command lists before execution.

Pull Request: #5998 - #5998

Changes made:

• Added validation logic to check commands against allowed/denied lists in executeCommandTool.ts
• Denied commands take precedence over allowed commands
• Commands are validated by both base command and full prefix matching
• Added comprehensive test coverage with 13 test cases

All CI checks have passed successfully. The fix ensures that Roo will now properly respect the configured command restrictions and prevent execution of unauthorized commands.

[daniel-lxs]

Hey @SGudbrandsson, thanks for the report. Can you clarify what you mean by “ran code it shouldn't run”? From the logs, it looks like Roo executed the full contents of your coding rules as a shell command, but I want to make sure I'm understanding your setup and what actually happened.