Summary

Add the ability to configure per-tool sandbox execution independent of session sandbox mode. This would allow specific tools (especially those handling external/untrusted data) to always run in a Docker sandbox while keeping other tools on the host for performance and compatibility.

Use Case

Problem: The current sandbox modes (off, non-main, all) are session-scoped. Users must choose between:

• Full host access (fast, but vulnerable to prompt injection from fetched content)
• Full sandboxing (secure, but breaks skills/cron that need host resources)

Desired behavior: Run most operations on the host, but isolate tools that handle untrusted external data:

• web_fetch → sandbox (fetched HTML could contain prompt injection)
• browser → sandbox (web content is untrusted)
• exec → host (needs local tools, credentials, paths)
• message, cron, built-in tools → host

Proposed Config

{
  "tools": {
    "sandbox": {
      "mode": "selective",
      "always": ["web_fetch", "browser"],
      "never": ["exec", "message", "cron", "gateway"]
    }
  }
}

Or per-tool:

{
  "tools": {
    "web": {
      "fetch": {
        "sandbox": "always"
      }
    }
  }
}

Security Benefit

This directly addresses prompt injection risks from external content without sacrificing the ergonomics of host-based execution for trusted operations. Defense in depth: even if fetched content contains malicious instructions, the sandboxed environment limits what damage can be done.

Alternatives Considered

1. mode: "non-main" with subagent delegation — Works but adds latency and complexity for simple fetch operations.
2. mode: "off" and accept risk — Functional but leaves a security gap.
3. URL allowlisting for fetch — Helps but doesn't fully address the problem (even trusted sites can be compromised).

Additional Context

Related to the broader "defense in depth" philosophy for agentic systems handling untrusted input. Would pair well with existing tools.exec.security allowlist patterns.