SCC vs Dev Containers

This guide compares SCC’s purpose-built AI agent sandboxing to using generic dev containers for AI-assisted development.

Different Goals

Dev Containers standardize your entire development environment—language runtimes, tools, extensions, and settings—in a reproducible container.

SCC specifically governs how AI coding agents such as Claude Code and Codex run: container isolation, built-in safety engine, plugin control, network enforcement, and team policies. It focuses on the AI agent, not your full dev environment.

Quick Comparison

Aspect	SCC CLI	Dev Containers
Primary purpose	Sandbox and govern AI coding agents	Standardize dev environment
Scope	Claude Code and Codex sessions	Full development workflow
Agent-specific features	Safety engine, plugin governance, provider policy, worktrees	None (runs agents normally)
Configuration	Org/team JSON configs	devcontainer.json
IDE integration	CLI-based	VS Code, JetBrains, Codespaces

What SCC Provides

SCC focuses on coding-agent governance:

Built-in Safety Engine

Blocks destructive commands that could damage your repository and intercepts explicit network tools:

• git push --force
• git reset --hard
• git branch -D
• git clean -fd

Plugin Governance

Organizations control which provider artifacts developers can use:

{
  "security": {
    "blocked_plugins": ["*experimental*", "*beta*"]
  },
  "defaults": {
    "enabled_plugins": ["scc-safety-net@sandboxed-code-official"]
  }
}

Team Profiles

Consistent agent configuration across all team members:

{
  "profiles": {
    "backend": {
      "additional_plugins": ["java-analyzer@internal"],
      "session": { "timeout_hours": 8 }
    }
  }
}

Git Worktree Management

Built-in isolation for parallel AI tasks:

scc worktree create ~/project feature-auth
# AI work happens on isolated branch

What Dev Containers Provide

Dev containers standardize your full development environment:

• Language runtimes and versions
• Build tools and dependencies
• VS Code extensions
• Editor settings
• Port forwarding

Dev containers don’t provide coding-agent-specific governance. Claude Code or Codex run inside them the same way they run on your host unless another tool governs the agent runtime.

Using Both Together

Many teams combine both approaches:

1. Dev Container defines the development environment (Node.js version, tools, extensions)
2. SCC governs Claude Code or Codex sessions within that environment

# Inside your dev container
scc setup --org https://example.com/org-config.json
scc start .

Note

Running SCC inside a devcontainer requires Docker access. SCC creates a sibling agent container; it does not run the agent inside the existing devcontainer.

Host Docker socket path mapping

When a devcontainer uses the host Docker socket, SCC may see the workspace as /workspaces/app while the host Docker daemon needs the host path, such as /Users/name/app, for bind mounts. Set one explicit path map before launch:

export SCC_WORKSPACE_PATH_MAP=/workspaces/app:/Users/name/app
scc doctor . --json
scc start . --dry-run --json
scc start .

In doctor output, the “Workspace Path Map” check reports whether the mapping is valid and whether it matches the current workspace. For projects with .devcontainer/devcontainer.json, .devcontainer.json, compose.yaml, compose.yml, docker-compose.yaml, or docker-compose.yml, the “Dev Environment Bridge” check also reports the detected devcontainer/Compose evidence, the path-map state, Docker socket visibility to the SCC process, and the unsupported bridge actions. In dry-run JSON, runtime_mount_source shows the host-visible path SCC will pass to the runtime, while mount_root and container_workdir stay on the logical path used inside the agent container.

Named bridge actions

Organizations and delegated teams can define named dev_environment.commands, dev_environment.logs, and dev_environment.health_checks with fixed argv lists. These actions are visible in scc config explain, scc config explain --json, and scc dev status --json so reviewers and agents can see which project-support actions are allowed by policy.

Example project config:

dev_environment:
  commands:
    test:
      argv: ["uv", "run", "pytest", "-q"]
      working_directory: "."
      timeout_seconds: 120
      description: "Run the project test suite"
  logs:
    api:
      argv: ["docker", "compose", "logs", "--tail", "100", "api"]
      timeout_seconds: 30
      description: "Read recent API logs"
  health_checks:
    api:
      argv: ["curl", "-fsS", "http://localhost:8000/health"]
      timeout_seconds: 10
      description: "Check local API health"

Use:

scc config explain --field dev_environment
scc config explain --json
scc dev status . --json
scc dev run test .
scc dev logs api .
scc dev health api .
scc dev run test . --json

scc dev run <name>, scc dev logs <name>, and scc dev health <name> are host-owned: SCC resolves the effective config for the workspace/team, writes a pre-execution audit event, then runs only the approved fixed argv list with shell=false. The action working directory must stay inside the workspace, stdout/stderr are returned as bounded stdout/stderr tails, and durable audit metadata stores status and byte counts, not command output. scc dev status does not run a host process; it only reports the effective bridge contract.

The agent container still does not receive Docker socket access or arbitrary project-network attachment.

If your devcontainer uses Docker-in-Docker, the path visible to SCC and the path visible to that inner daemon are usually the same, so no path map is needed.

SCC does not attach the agent container to arbitrary devcontainer or Compose service networks in v1. Network access remains controlled by SCC’s own network_policy and, in web-egress-enforced, by the SCC proxy topology. This is a reliability and governance boundary: joining a project service network would create another route that needs its own policy, explain output, audit event, and runtime smoke tests before it can be called an SCC control.

Optional real-runtime smoke

Normal SCC tests use fake runtimes so CI does not require Docker. Operators who want to verify a local Docker/devcontainer setup can run the opt-in smoke tests:

cd scc
SCC_REAL_RUNTIME_SMOKE=1 \
SCC_REAL_RUNTIME_IMAGE=scc-agent-claude:latest \
uv run pytest -q --no-cov -m real_runtime

The smoke checks are skipped unless SCC_REAL_RUNTIME_SMOKE=1 is set and the image named by SCC_REAL_RUNTIME_IMAGE exists locally. They validate the host-path bind mount used by SCC_WORKSPACE_PATH_MAP, the locked-down-web Docker create path, and one approved bridge log/health action against a live local container.

When to Use Each

Choose SCC When

• Your priority is governing Claude Code, Codex, or both
• You need runtime safety guardrails for destructive git commands and explicit network tools
• Organization must control provider artifacts, plugins, MCP servers, and policy
• Team needs consistent coding-agent policies, not just a repeatable dev environment

Choose Dev Containers When

• Your priority is standardizing the overall dev environment
• You need reproducible builds and consistent tooling
• IDE integration (VS Code, Codespaces) is important
• Coding-agent governance isn’t a concern

Use Both When

• You want standardized dev environments and coding-agent governance
• Your org has both general dev standards and AI-specific policies
• Different teams need different agent configurations within similar dev environments

Next Steps

Quick Start Try SCC in minutes

Security Model Understand SCC's isolation layers

Team Profiles Configure team-specific profiles