SCC — Sandboxed Coding CLI

快速开始 · 为什么选择 SCC · 常用命令 · 延伸阅读 · 文档 · 架构

完整文档： scc-cli.dev

SCC 是一个面向 AI 编码代理的受管运行时。它在兼容 OCI 的容器中运行 [Claude Code](https://docs.anthropic.com/en/docs/claude-code) 和 [Codex](https://openai.com/index/introducing-codex/)，具备感知提供商的接入流程、团队管理的配置、运行时安全、网络控制以及 git worktree 支持。 SCC 并不是一个新的代理。它为现有的编码 CLI 提供了一套组织运营模型：统一的组织配置、委托的团队所有权、可重复的开发者接入流程，以及更易于审查并在全公司范围内推广的更安全的运行时。 ## 为什么团队使用 SCC 当团队希望 AI 编码代理在运营上变得可管理，而不是临时拼凑时，他们会选择 SCC。 - **部署一套受管设置**：一次性定义组织默认值，然后让团队负责人在这些边界内维护团队级别的配置。 - **支持多个代理**：允许同时使用 Claude、Codex 或两者，而无需围绕单一供应商重建工作流。 - **更快接入开发者**：新开发者运行 `scc setup` 即可获得经过批准的软件包，无需手动安装插件、hooks、MCP 服务器和本地规则。 - **隔离运行时**：在容器中运行代理，该容器仅能看到你挂载的工作区，而不是你的整个机器。 - **控制网络路径**：保持出口开放，强制 HTTP/HTTPS 通过代理 sidecar，或者完全锁定容器。 - **默认应用运行时安全**：拦截破坏性的 git 命令，并在沙箱内拦截显式的网络工具。 - **保持日常工作流的实用性**：内置了受保护分支提示、会话恢复、仪表板以及基于 worktree 的特性开发。 ## 快速开始 **要求：** Python 3.10+、Git 2.30+，以及兼容 Docker 的容器运行时，例如 [Docker Engine](https://docs.docker.com/engine/)、[OrbStack](https://orbstack.dev/)、[Colima](https://github.com/abiosoft/colima) 或 [Docker Desktop](https://www.docker.com/products/docker-desktop/)。支持 Docker Desktop，但不是必需的。 ``` uv tool install scc-cli scc setup cd ~/project && scc ``` `scc setup` 的作用： - 连接你的组织配置或启用独立模式 - 连接 Claude、Codex 或两者 - 存储你的提供商偏好：`ask`、`claude` 或 `codex` 首次启动的作用： - 解析使用哪个提供商 - 检查认证和镜像的就绪状态 - 如有需要，构建提供商镜像 - 如有需要，引导提供商认证 - 在沙箱容器内启动代理 有用的首次检查： ``` scc doctor scc doctor --provider codex ``` ## SCC 如何帮助组织 SCC 为 AI 编码代理提供了适合组织的运营模型。 | 角色 | SCC 提供的内容 | |---|---| | **组织管理员 / 平台团队** | 针对允许的提供商、网络策略、插件/MCP 治理以及默认值的统一中心配置 | | **团队负责人** | 在组织批准的边界内，对团队特定设置的委托控制权 | | **开发者** | 可重复的接入流程和开箱即用的沙箱环境，无需手动进行本地设置 | 这种组合是主要的价值所在：对组织而言更严格的控制，对开发者而言更少的摩擦。 ## SCC 控制的内容 | 层面 | SCC 的作用 | |---|---| | 提供商 | 通过一个中立的提供商启动路径运行 Claude Code 和 Codex | | 文件系统 | 将工作区挂载到沙箱中，而不是暴露你的整个机器 | | 网络 | 支持 `open`、`web-egress-enforced` 和 `locked-down-web` | | 安全 | 拦截破坏性的 git 命令，并检查容器内显式的网络工具 | | 团队配置 | 在开发者之间一致地应用组织和团队设置 | | 插件和 MCP | 管理允许、阻止或注入到运行时的内容 | | 会话 | 支持启动、恢复、停止、检查和清理流程 | | Git 工作流 | 支持受保护分支提示和基于 worktree 的特性开发 | 重要的一点：仅靠容器本身**无法**解决网络风险。如果你关心代理能访问什么，请使用 SCC 的网络策略，而不仅仅是默认的容器运行时。 ## 网络与安全 SCC 故意将沙箱与出口控制分离开来。 - `open`：不受限制的网络访问 - `web-egress-enforced`：代理运行在仅限内部网络的网络上，并通过带有 ACL 的 Squid 代理 sidecar 访问 HTTP/HTTPS - `locked-down-web`：容器使用 `--network=none` 运行 内置的安全引擎是提供商中立的。它使用镜像内的 shell 包装器在将命令转发给真正的二进制文件之前对其进行评估。在 v1 版本中，严格的安全基线主要关注破坏性的 git 命令和显式的网络工具，例如 `curl`、`wget`、`ssh`、`scp`、`sftp` 和 `rsync`。 这些运行时包装器属于纵深防御。它们拦截容器内的风险命令，但硬性的网络边界仍然是运行时拓扑和代理策略。 ## 常用命令 ``` # 开始和恢复 scc scc start ~/project scc start --provider codex ~/project scc start --resume scc start --select # Provider 管理 scc provider show scc provider set ask scc provider set claude scc provider set codex # Sessions 和 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 ``` ## 架构概览 SCC 有三个主要部分： - **控制平面**：提供商选择、治理、配置继承、就绪检查和审计规划 - **运行时后端**：OCI 容器启动、镜像、Web 出口拓扑和沙箱生命周期 - **提供商适配器**：Claude 和 Codex 认证、设置渲染、运行时规范以及特定于提供商的启动行为 这种分离使核心保持提供商中立，同时允许每个提供商保留其自己的原生细节。 ## 延伸阅读 如果你只想快速上手，请从这里开始： - [快速开始](https://scc-cli.dev/getting-started/quick-start/) - [核心概念](https://scc-cli.dev/getting-started/core-concepts/) - [日常工作流](https://scc-cli.dev/guides/developer/daily-workflow/) 如果你正在为团队或组织评估 SCC，请接着阅读这些内容： - [架构概览](https://scc-cli.dev/architecture/overview/) - [安全模型](https://scc-cli.dev/architecture/security-model/) - [治理模型](https://scc-cli.dev/architecture/governance-model/) - [示例](https://scc-cli.dev/examples/) - [插件市场](https://scc-cli.dev/plugins/marketplace/) 如果你想要命令的详细信息： - [CLI 参考](https://scc-cli.dev/reference/cli/overview/) - [故障排除](https://scc-cli.dev/troubleshooting/) ## 开发 ``` uv sync uv run pytest uv run ruff check uv run mypy src/scc_cli ``` ## 贡献 欢迎提交 Issue、错误报告、文档修复和 Pull Request。 如果你想做出贡献： - 针对错误或产品缺陷打开一个 Issue - 针对针对性的修复打开一个 PR - 确保面向用户的声明与实际的运行时行为保持一致 ## License MIT

标签：AI编程代理, Claude Code, DevSecOps, Git Worktree, OCI容器, OpenAI Codex, Python CLI, Web截图, 上游代理, 企业级部署, 团队协作, 威胁情报, 安全合规, 容器安全, 开发者工具, 沙箱环境, 网络代理, 网络安全研究, 网络控制, 请求拦截, 运行时管理, 逆向工具