Skip to content
SCC CLI

What is SCC?

SCC (Sandboxed Coding CLI) is a provider-neutral governed runtime for AI coding agents. It runs Claude Code and Codex inside container sandboxes (Docker Engine, OrbStack, Colima, or Docker Desktop) with organization-managed team profiles, a built-in safety engine, and git worktree support.

Read This First

Section titled “Read This First”

You do not need to read every page to start using SCC.

The Problem SCC Solves

Section titled “The Problem SCC Solves”

When teams use AI coding agents, several challenges emerge:

Security Risk

AI agents can execute arbitrary commands on your host machine, including destructive ones like rm -rf or git push --force.

Configuration Drift

Each developer sets up their environment differently, leading to inconsistent behavior and hard-to-reproduce issues.

Plugin Chaos

Without governance, developers install random plugins that may conflict or introduce security vulnerabilities.

Provider Lock-in

Teams want to evaluate or switch between AI coding agents without rebuilding their governance, config, and plugin infrastructure.

How SCC Helps

Section titled “How SCC Helps”

Provider-Neutral Runtime

Section titled “Provider-Neutral Runtime”

SCC supports multiple AI coding agents through a provider-neutral architecture. Claude Code and Codex are first-class providers today. The architecture is extensible — adding a new provider means adding one adapter, not changing the core.

Terminal window
scc provider show          # See current preference
scc provider set codex     # Switch default provider
scc start --provider claude ~/project  # Override for one session

Your org config, team plugins, safety policies, and governance carry over regardless of which provider you use. Teams can standardize on one provider, allow both, or mix them by workflow. That makes SCC easier to adopt in organizations where one team prefers Claude for exploratory work and another prefers Codex for backend-heavy tasks.

Container Isolation

Section titled “Container Isolation”

Every agent session runs inside an OCI container. The agent can only access files you explicitly mount, and it cannot affect your host system directly.

Container Sandbox Isolation
Container Sandbox Isolation

Containers Are Necessary, Not Sufficient

Section titled “Containers Are Necessary, Not Sufficient”

Container isolation protects the host filesystem boundary, but it does not automatically solve network risk. A normal container can still reach the internet or internal services that your runtime can route to.

SCC separates those concerns clearly:

  • Container isolation limits filesystem and process scope
  • open keeps normal outbound network access
  • web-egress-enforced routes HTTP/HTTPS through a Squid proxy sidecar on an internal-only network
  • locked-down-web disables network access entirely with --network=none

That distinction matters when teams worry about agents reaching internal APIs, metadata endpoints, or services outside the current workspace.

Built-in Safety Engine

Section titled “Built-in Safety Engine”

SCC includes a fail-closed safety engine that runs inside every container:

  • Git safety rules — blocks push --force, reset --hard, branch -D, clean -fd, and other destructive git commands
  • Network tool interception — wraps curl, wget, ssh, scp, sftp, and rsync with policy checks
  • Shell tokenizer — parses compound commands to catch destructive operations hidden in pipes or subshells
  • Fail-closed — if safety policy cannot be loaded, all guarded commands are blocked by default

The optional scc-safety-net plugin provides additional coverage via agent-native hooks (currently Claude Code; Codex support planned).

Centralized Configuration

Section titled “Centralized Configuration”

Organization admins define a single JSON config that specifies:

  • Which plugins are allowed/blocked
  • Which MCP servers teams can use
  • Security policies (network posture, safety-net action)
  • Team-specific profiles

Developers just run scc setup once and they’re ready.

Topology-Enforced Web Egress

Section titled “Topology-Enforced Web Egress”

When network_policy is set to web-egress-enforced, SCC creates an internal-only Docker network. The agent container can only reach the internet through a Squid proxy sidecar that enforces an ACL. This is real network topology enforcement — even if the agent ignores proxy environment variables, it physically cannot bypass the proxy. The compiled ACL also denies loopback, private CIDRs, link-local ranges, and cloud metadata endpoints before any allow rules are applied.

Git Worktree Integration

Section titled “Git Worktree Integration”

SCC uses git worktrees to create isolated branches for each task:

Terminal window
scc worktree create ~/project feature-auth
# Creates isolated branch scc/feature-auth
# Auto-starts an agent session in the worktree

Who Uses SCC?

Section titled “Who Uses SCC?”
RoleWhat SCC Provides
DevelopersInstant setup, protected main branch, isolated experiments, provider choice
Team LeadersApproved plugin sets, consistent configs across the team
Org AdminsSecurity policies, blocked plugins, audit trails, provider governance

Requirements

Section titled “Requirements”
  • Python 3.10+
  • Container runtime — Docker Engine 20.10+, OrbStack, Colima, or Docker Desktop (Podman support is planned but not yet fully validated)
  • Git 2.30+
  • uv (recommended for installation)

Next Steps

Section titled “Next Steps”