Skip to content

CLI Agent and IDE Sandbox Integration

Aug 30, 20261 min
TL;DRThe local products post (order 6) of the Sandbox Series. How OpenCode, Codex CLI, Cursor and other CLI agents and IDEs set up local sandboxes, where the isolation boundary lies, common pitfalls, and security best practices.

Look up & save

Loading dictionary…

🌏 中文版

What This Post Is

This post is the "local products" post (order 6) of the Sandbox Series. It doesn't cover single provider technical details (Claude Code in order 5), but focuses on CLI agent and IDE local sandbox integration:

  1. How do OpenCode, Codex CLI, Cursor and other CLI agents set up local sandboxes?
  2. Where is the isolation boundary? — Filesystem, network, subprocesses, credentials.
  3. What are the common pitfalls? — Docker socket, SSH keys, Git hooks, environment variables.
  4. What are the security best practices?

Current State of CLI Agent and IDE Sandboxes

Modern CLI agents (OpenCode, Codex CLI, Antigravity CLI, Kiro) and IDE agents (Cursor, Windsurf, Copilot in local mode) all need to execute user code. Their sandbox modes fall into three categories:

ModeRepresentative ToolsIsolation StrengthSuitable Scenario
No sandboxEarly Copilot, some IDE pluginsWeakRead-only, no code execution
Local OS sandboxOpenCode, Codex CLI, CursorMediumLocal development, code generation & execution
Container/VM sandboxSome enterprise IDE versionsStrongMulti-tenant, untrusted code

This post focuses on local OS sandbox, the model adopted by most CLI agents and IDEs today.


OpenCode Local Sandbox Setup

OpenCode uses local OS primitives (macOS Seatbelt, Linux bubblewrap/Landlock) to enforce the same boundary on every Bash command.

Key Configuration

// ~/.opencode/settings.json
{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["./", "./src", "./tmp"],
      "denyRead": ["~/.ssh", "~/.aws", "~/.env", "/etc/passwd"]
    },
    "network": {
      "allowedDomains": ["api.opencode.dev", "github.com"],
      "strictAllowlist": true
    },
    "process": {
      "maxProcesses": 64,
      "maxMemoryMB": 512
    }
  }
}

Isolation Boundary

LayerRestrictionDescription
FilesystemWrite limited to working directory + session tempPrevent writing system files
FilesystemRead defaults to entire machine, but denyRead can blockRequires explicit setup
NetworkDefault zero domains, requires allowlistPrevent lateral movement
ProcessPID limit, memory limitPrevent fork bomb
CapabilitiesDrop SYS_ADMIN and other high-risk capabilitiesPrevent privilege escalation

Codex CLI Local Sandbox Setup

Codex CLI uses container or local OS sandbox, depending on platform.

Basic Usage

# Enable sandbox mode
codex --sandbox enabled

# Specify working directory
codex --sandbox-workdir ./workspace

# Restrict network
codex --sandbox-network allowlist github.com,api.openai.com

Common Pitfalls

  1. Docker socket not blocked: If Codex CLI can access /var/run/docker.sock, it can start new containers, bypassing sandbox limits.
  2. SSH key leakage: ~/.ssh/id_rsa is readable by default, needs explicit blocking.
  3. Environment variable inheritance: AWS credentials, API keys may be passed into the sandbox.

Cursor Local Sandbox Setup

Cursor's sandbox mode mainly targets its agent mode (Composer, Chat).

Configuration Entry

Cursor sandbox settings in Settings > Features > Agent > Sandbox:

{
  "agent.sandbox.enabled": true,
  "agent.sandbox.docker.enabled": false,
  "agent.sandbox.local.enabled": true,
  "agent.sandbox.local.readOnlyPaths": [
    "~/.ssh",
    "~/.aws",
    "~/.config/git/credentials"
  ],
  "agent.sandbox.local.writePaths": [
    "${workspaceFolder}"
  ]
}

Common Issues

  • Git hook executed: After agent modifies code, Git hooks (pre-commit, post-commit) may auto-execute, leading to malicious code running outside sandbox. CVE-2026-50548 is exactly this type of vulnerability.
  • Working directory escape: Agent accesses files outside workspace via ../ paths.

Common Pitfalls Across Tools

Pitfall 1: Docker Socket Not Blocked

If agent can access Docker socket, it can start new containers, bypassing all sandbox limits.

Defense: Do not mount Docker socket into sandbox:

--mount type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock,readonly

Pitfall 2: SSH Keys and Cloud Credentials

~/.ssh/id_rsa, ~/.aws/credentials, ~/.env are readable by default.

Defense:

  • Use denyRead to block sensitive paths
  • Use short-lived credential proxy, not long-term keys
  • Environment variables should not be passed into sandbox

Pitfall 3: Git Hook Auto-Execution

Agent modifies code, then Git hooks (pre-commit, post-commit) may auto-execute.

Defense:

  • Disable Git hooks inside sandbox
  • Or set Git hooks to read-only

Pitfall 4: Environment Variable Inheritance

OPENAI_API_KEY, ANTHROPIC_API_KEY may be passed into sandbox, agent can steal and exfiltrate them.

Defense:

  • Do not pass full API keys into sandbox environment
  • Use credential broker to inject on demand

Security Best Practices Checklist

ItemSuggestionPriority
Block Docker socketDo not mount Docker socket into sandboxHigh
Block sensitive pathsdenyRead ~/.ssh, ~/.aws, ~/.envHigh
Network allowlistDefault no egress, only allow necessary domainsHigh
Limit process countPID limit, memory limitMedium
Disable Git hookNo Git hook execution inside sandboxMedium
Short-lived credentialsUse credential broker, not long-term keysMedium
Audit logsRecord all file and network operationsMedium

What You Should Understand After Reading

  1. Three sandbox modes for CLI agents and IDEs and applicable scenarios.
  2. OpenCode, Codex CLI, Cursor local sandbox setup methods.
  3. Five common pitfalls: Docker socket, SSH keys, environment variables, Git hooks, working directory escape.
  4. Five security best practices: block Docker socket, sensitive paths, network allowlist, process limits, short-lived credentials.
  5. Sandboxing isn't a "whether" question — it's a "how strict" question.

References