Governed runtime for AI coding agents with container sandboxes, network controls, and team-managed configuration
Project description
SCC — Sandboxed Coding CLI
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.
Why Teams Use SCC
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.
Quick Start
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 && scc
What 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 codex
How SCC Helps an Organization
SCC 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.
What SCC Controls
| 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.
Network and Safety
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.
Common Commands
# 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-audit
Architecture at a Glance
SCC 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.
Read This Next
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:
Development
uv sync
uv run pytest
uv run ruff check
uv run mypy src/scc_cli
Contributing
Issues, 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
License
MIT
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file scc_cli-2.0.0.tar.gz.
File metadata
- Download URL: scc_cli-2.0.0.tar.gz
- Upload date:
- Size: 1.0 MB
- Tags: Source
- Uploaded using Trusted Publishing? Yes
- Uploaded via: twine/6.1.0 CPython/3.13.7
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
b7319ca16a640ac9d4b7a5dc7d3e7cd2edf58f2f328b9efc1517c8967349d442
|
|
| MD5 |
a3d3c2bbf3c53ebe1ac778712ac05e36
|
|
| BLAKE2b-256 |
794b247061b38559f44c415616b577b74c25d9580bda56f4b02d27ea08e5e15f
|
Provenance
The following attestation bundles were made for scc_cli-2.0.0.tar.gz:
Publisher:
python-publish.yml on CCimen/scc
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
scc_cli-2.0.0.tar.gz -
Subject digest:
b7319ca16a640ac9d4b7a5dc7d3e7cd2edf58f2f328b9efc1517c8967349d442 - Sigstore transparency entry: 1244750370
- Sigstore integration time:
-
Permalink:
CCimen/scc@3ff70427a0ac9c3458d3a14882b3828beca3af6b -
Branch / Tag:
refs/tags/v2.0.0 - Owner: https://github.com/CCimen
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
python-publish.yml@3ff70427a0ac9c3458d3a14882b3828beca3af6b -
Trigger Event:
release
-
Statement type:
File details
Details for the file scc_cli-2.0.0-py3-none-any.whl.
File metadata
- Download URL: scc_cli-2.0.0-py3-none-any.whl
- Upload date:
- Size: 670.4 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? Yes
- Uploaded via: twine/6.1.0 CPython/3.13.7
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
75a06abed5b8ebe16297a64bf6d1139477b5b54487e89c91f5b792974b1f35fa
|
|
| MD5 |
83be92b32a0a6e60db17db7fb1d67782
|
|
| BLAKE2b-256 |
e883a1a8ff26aa9b5b7e1ae4ec0f5aecccc6c1efea83dd51be56ef298d398214
|
Provenance
The following attestation bundles were made for scc_cli-2.0.0-py3-none-any.whl:
Publisher:
python-publish.yml on CCimen/scc
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
scc_cli-2.0.0-py3-none-any.whl -
Subject digest:
75a06abed5b8ebe16297a64bf6d1139477b5b54487e89c91f5b792974b1f35fa - Sigstore transparency entry: 1244750392
- Sigstore integration time:
-
Permalink:
CCimen/scc@3ff70427a0ac9c3458d3a14882b3828beca3af6b -
Branch / Tag:
refs/tags/v2.0.0 - Owner: https://github.com/CCimen
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
python-publish.yml@3ff70427a0ac9c3458d3a14882b3828beca3af6b -
Trigger Event:
release
-
Statement type: