[ENHANCEMENT] Support configurable command sandboxing

[kamelkace]

Problem (one or two sentences)

Approving commands by prefix is useful, but doesn't provide a high degree of network or filesystem isolation. Ideally, agents would be given the ability to run any command they want, while providing assurances to the user that they cannot execute anything that is unduly risky.

Context (who is affected and when)

Users who want to allow agents to run in the background with little intervention, but desire some control over their behaviour, to an extent not enforceable via prompting.

Desired behavior (conceptual, not technical)

Commands executed via run_command can be run in a configurable, isolated environment, in a way that does not trivially permit escapes.

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)

I propose using Anthropic's sandbox-runtime to wrap all commands which are sent to the VS Code Terminal, or via execa.

Trade-offs / risks (optional)

Alternatives considered:

• Use an MCP server for executing commands. This fails pretty often, as LLMs can't remember to use the MCP server, and will often try to call execute_command anyways.
• Isolate all of Roo Code, in Visual Studio Code, inside a bubblewrap'd environment. This is a miserable working experience, as VS Code configs are difficult to import, and many pieces of VS Code functionality (e.g. SCM operations, extension updates, etc.) require network access, which violates that isolation requirement.

[roomote]

I've analyzed this issue and explored the codebase to understand the current command execution architecture. Here's what I found and my proposed implementation plan:

Current Architecture

Commands flow through these key components:

• ExecuteCommandTool (src/core/tools/ExecuteCommandTool.ts) - handles the execute_command tool invocations
• TerminalRegistry (src/integrations/terminal/TerminalRegistry.ts) - manages terminal creation/lifecycle
• Terminal (src/integrations/terminal/Terminal.ts) - VSCode terminal wrapper using shell integration
• ExecaTerminal (src/integrations/terminal/ExecaTerminal.ts) - execa-based terminal for non-shell-integration mode
• BaseTerminal (src/integrations/terminal/BaseTerminal.ts) - abstract base class with runCommand()

Commands are executed either via VSCode's shellIntegration.executeCommand() or via execa depending on shell integration availability.

Proposed Implementation Plan

1. Add sandbox configuration to settings

• Add a new commandSandbox configuration section in the extension settings schema, with options like:
  • enabled: boolean - toggle sandboxing on/off
  • provider: "sandbox-runtime" | "none" - sandbox provider (extensible for future providers)
  • networkPolicy: "allow" | "deny" | "restricted" - network access policy
  • filesystemPolicy: "readwrite" | "readonly" | "restricted" - filesystem access policy
  • allowedPaths: string[] - paths the sandbox can access
  • deniedPaths: string[] - paths the sandbox cannot access

2. Create a SandboxManager abstraction

• New file: src/integrations/terminal/sandbox/SandboxManager.ts
• Interface CommandSandbox with methods like wrapCommand(command: string, cwd: string): string and isAvailable(): Promise<boolean>
• Implementation SandboxRuntimeProvider that wraps commands using Anthropic's sandbox-runtime
• A NoOpSandbox passthrough for when sandboxing is disabled

3. Integrate sandboxing into the terminal execution path

• Modify executeCommandInTerminal() in ExecuteCommandTool.ts to check sandbox configuration
• Before passing commands to terminal.runCommand(), route them through SandboxManager.wrapCommand()
• This approach keeps the change minimal and centralized - all terminal types (VSCode and execa) benefit automatically

4. Add sandbox-runtime as an optional dependency

• Add @anthropic-experimental/sandbox-runtime as an optional dependency
• Handle the case where it's not installed gracefully (fall back to NoOpSandbox)
• Provide setup instructions in documentation

5. Add UI controls in the settings view

• Add a "Command Sandboxing" section in the settings webview
• Allow users to configure sandbox policies through the UI
• Show sandbox availability status

6. Add tests

• Unit tests for SandboxManager and providers
• Integration tests for the modified executeCommandInTerminal flow
• Tests for configuration handling

Key Design Decisions

• Wrap at the command level, not the terminal level: This is the least invasive approach and works with both VSCode and execa terminals
• Optional dependency: Users who don't need sandboxing shouldn't be affected
• Provider pattern: Makes it easy to add alternative sandbox implementations in the future (e.g., Docker, Firejail, nsjail)

Open Questions

1. Should sandbox configuration be per-mode (e.g., different policies for architect vs code mode)?
2. Should there be a visual indicator in the UI when a command is running sandboxed?
3. The sandbox-runtime package appears to be experimental - should we also support alternative sandboxing backends from the start (e.g., bubblewrap/firejail on Linux)?
4. How should sandbox failures be handled - should the command fail entirely, or fall back to unsandboxed execution with a warning?

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

[kamelkace]

@roomote Sure, I approve. Bear in mind that -- at least for Terminal.ts, if not ExecaTerminal.ts -- you'll probably have to use the srt command line tool instead of using the sandbox-runtime library. Your choice, of course.

[roomote]

Thanks for the approval and the tip about using the srt CLI tool for Terminal.ts! I'll get started on the implementation. For Terminal.ts (VSCode shell integration), I'll use the srt command-line wrapper approach, and for ExecaTerminal.ts I'll evaluate whether the library or CLI approach works best. I'll open a draft PR shortly to share progress.

[roomote]

Opened a draft PR with my attempt at addressing this: #11773

The implementation uses the srt CLI tool to wrap commands at the string level (as suggested), which works for both VSCode shell integration terminals and execa terminals. Configuration is exposed through 5 new VS Code settings (commandSandboxEnabled, commandSandboxNetworkPolicy, commandSandboxWritePolicy, commandSandboxAllowedPaths, commandSandboxDeniedPaths). All 46 tests pass (23 new + 23 existing). Feedback welcome!