Quick Start · Why SCC · Commands · Read Next · Documentation · Architecture
Full documentation: scc-cli.dev
SCC is a governed runtime for AI coding agents. It runs Claude Code and Codex inside OCI-compatible containers with provider-aware onboarding, team-managed configuration, runtime safety, network controls, and git worktree support.
SCC is not a new agent. It gives organizations an operating model for existing coding CLIs: one org config, delegated team ownership, repeatable developer onboarding, and a safer runtime that is easier to review and roll out across a company.
The optional scc-safety-net plugin adds extra agent-native git protection where supported. Today it is Claude-focused. SCC's built-in safety engine already protects both Claude and Codex inside the sandbox.
Teams use SCC when they want AI coding agents to feel operationally manageable instead of ad hoc.
- Roll out one governed setup: define org defaults once, then let team leads maintain team-level config within those boundaries.
- Support more than one agent: allow Claude, Codex, or both without rebuilding your workflow around a single vendor.
- Onboard developers faster: new developers run
scc setupand get the approved package instead of manually installing plugins, hooks, MCP servers, and local rules. - Isolate the runtime: run the agent in a container that sees the workspace you mounted, not your whole machine.
- Control the network path: keep egress open, force HTTP/HTTPS through a proxy sidecar, or lock the container down completely.
- Apply runtime safety by default: block destructive git commands and intercept explicit network tools inside the sandbox.
- Keep daily workflows practical: protected-branch prompts, session resume, dashboards, and worktree-based feature work are built in.
Requires: Python 3.10+, Git 2.30+, and a Docker-compatible container runtime such as Docker Engine, OrbStack, Colima, or Docker Desktop. Docker Desktop is supported, but not required.
uv tool install scc-cli
scc setup
cd ~/project && sccWhat scc setup does:
- connects your org config or enables standalone mode
- connects Claude, Codex, or both
- stores your provider preference:
ask,claude, orcodex
What first launch does:
- resolves which provider to use
- checks readiness for auth and images
- builds the provider image if needed
- bootstraps provider auth if needed
- starts the agent inside a sandboxed container
Useful first checks:
scc doctor
scc doctor --provider codexSCC gives AI coding agents an organization-ready operating model.
| Role | What SCC gives them |
|---|---|
| Org admin / platform team | One central config for allowed providers, network policy, plugin/MCP governance, and defaults |
| Team lead | Delegated control over team-specific setup within org-approved boundaries |
| Developer | A repeatable onboarding flow and a ready-to-use sandboxed environment instead of manual local setup |
That combination is the main value: tighter control for the organization, less friction for the developer.
| Surface | What SCC does |
|---|---|
| Providers | Runs Claude Code and Codex through one provider-neutral launch path |
| Filesystem | Mounts the workspace into the sandbox instead of exposing your whole machine |
| Network | Supports open, web-egress-enforced, and locked-down-web |
| Safety | Blocks destructive git commands and checks explicit network tools inside the container |
| Team config | Applies org and team settings consistently across developers |
| Plugins and MCP | Governs what is allowed, blocked, or injected into the runtime |
| Sessions | Supports start, resume, stop, inspect, and prune flows |
| Git workflows | Supports protected-branch prompts and worktree-based feature work |
One important point: a container alone does not solve network risk. If you care about what an agent can reach, use SCC's network policies, not just a default container runtime.
SCC separates sandboxing from egress control on purpose.
open: unrestricted network accessweb-egress-enforced: the agent runs on an internal-only network and reaches HTTP/HTTPS through a Squid proxy sidecar with an ACLlocked-down-web: the container runs with--network=none
The built-in safety engine is provider-neutral. It uses shell wrappers inside the image to evaluate commands before forwarding them to the real binary. In v1, the hard safety baseline focuses on destructive git commands and explicit network tools such as curl, wget, ssh, scp, sftp, and rsync.
Those runtime wrappers are defense-in-depth. They intercept risky commands inside the container, but the hard network boundary remains the runtime topology and proxy policy.
# Start and resume
scc
scc start ~/project
scc start --provider codex ~/project
scc start --resume
scc start --select
# Provider management
scc provider show
scc provider set ask
scc provider set claude
scc provider set codex
# Sessions and containers
scc sessions
scc list
scc stop
scc stop --all
scc prune
# Worktrees
scc worktree . create feature-auth
scc worktree . enter feature-auth
# Diagnostics
scc doctor
scc config explain
scc support safety-auditSCC has three main parts:
- Control plane: provider selection, governance, config inheritance, readiness checks, and audit planning
- Runtime backend: OCI container launch, images, web egress topology, and sandbox lifecycle
- Provider adapters: Claude and Codex auth, settings rendering, runtime spec, and provider-specific startup behavior
That split keeps the core provider-neutral while letting each provider keep its own native details.
If you only want to get productive, start here:
If you are evaluating SCC for a team or organization, read these next:
If you want command details:
uv sync
uv run pytest
uv run ruff check
uv run mypy src/scc_cliIssues, bug reports, docs fixes, and pull requests are welcome.
If you want to contribute:
- open an issue for bugs or product gaps
- open a PR for focused fixes
- keep user-facing claims truthful to the actual runtime behavior
MIT