aicontainer 沙箱化开发容器
把 Claude Code、Codex、OpenCode 的全自动批准模式关进 devcontainer 沙箱，防止被注入的依赖读走你的 .env、SSH 密钥或 gh 令牌。
证据显示该技能在安全设计上明显优于同类：disable-model-invocation 禁止自动触发；Step 0 强制检测是否已在容器内并拒绝从内部写 .devcontainer；明确禁止绕过 aic trust、禁止 --allow-unsafe，宿主边界信任必须由用户在 TTY 中亲自授予；写文件前要求完整计划并获用户确认；Pull 大镜像前二次确认；从不删除未确认的卷。扣分项：发布者身份未经验证（按规则不作额外扣分但纳入归因），Step 1 依赖运行时 WebFetch 远程 README（供应链与可达性小风险），技能本身不含回滚说明（依赖 aic down/destroy 未在技能内明示），未满 25。
指令内部自洽性很高：golden rules、aic up vs aic rebuild 的 pull_policy 陷阱、mount 目标白名单、post-create 三大约束（manifest 守卫、.git/hooks 只读、NPM_CONFIG_IGNORE_SCRIPTS）均为可诊断的失败模式说明，失败路径有明确反馈而非把调试成本转嫁用户。按静态校准上限不超过 10；技能自身（对话式流程）的关键路径无测试可静态复现，扣去超出部分。
触发边界清晰：disable-model-invocation 使其仅在用户显式调用时运行，避免误触发；Step 2-4 给出明确的栈检测信号表与适用/不适用矩阵（iOS、Windows 原生、GPU、嵌入式等），并允许部分方案。扣分项：全英文、无中文支持说明；核心流程依赖 raw.githubusercontent.com 拉取 README，对大陆网络可达性构成实质依赖（已在注意事项披露）；对 aicontainer 生态外环境无适用范围声明，未达 15。
文档分层良好：SKILL.md 承载判断，references 承载信号表与配方，README 承载语法事实；项目自有文件 vs 托管文件的边界、update mode 审计、版本钉扎（FROM tag）与 --bump-base 更新路径均明确；MIT 许可、package. 版本 0.9.0、CHANGELOG 脚本与维护责任（单一作者、npm/GHCR 发布）可追溯。扣分项：发布者未验证、技能目录内未见独立 FAQ/示例输出、版本治理依托整个仓库而非技能自身，未满 15。
技能将一项真实且高摩擦的任务（为 bypass 模式 AI 代理搭建按项目定制的沙箱）结构化，产出可直接使用的项目文件与命令序列，并覆盖更新模式；相对手工阅读 README 配置有明显边际价值。静态上限 7：核心输出（生成的配置文件）无法静态验证其可运行性，代表性输出未经执行复核，扣去超出部分。
仓库含真实 CI（rebuild.yml/release.yml）与 smoke 测试，实际验证了 aic init、socket-proxy 403 默认、metadata 阻断、PreToolUse hook 拦 .env 等底层关键声明，与技能描述高度互证；事实与推断分离清晰。但按静态校准，测试覆盖的是 aic 底层而非技能自身的对话式关键路径（栈检测、生成建议质量），且部分证据文件在评审截断，无法确认全部覆盖，给予 4 而非满分 5 之外的上限。
- 该技能配置的是以 bypass/自动批准模式运行的 AI 代理沙箱——请先阅读仓库威胁模型，确认信任边界（aic trust、Docker 模式、防火墙白名单）后再启用
- 核心流程依赖从 raw.githubusercontent.com 拉取 README，中国大陆网络可能不可达；技能会降级到本地文档但语法时效性下降
- 技能本身为全英文；发布者未经 FollowSkills 企业注册表验证，身份属未知
- 任何 Dockerfile.project/挂载扩展都意味着一次边界扩张，需用户本人在 TTY 中运行 aic trust，勿让代理代为绕过
- 静态评审未执行任何代码：生成配置的可运行性与首次启动结果未经独立复核
这个 Skill 能做什么，适合哪些场景？
aicontainer 是一个沙箱化的 devcontainer，让你可以在绕过权限/自动批准模式下安全地运行 Claude Code、Codex 和 OpenCode。配套的 setup Skill 以对话方式把一个项目从"没有沙箱"推进到"AI 代理在沙箱边界内、并针对该项目技术栈完成定制"：它检测技术栈、判断 Linux devcontainer 是否适用、提出定制方案并在用户批准后落地。沙箱本身提供文件系统隔离、默认无 Docker 对象访问、PreToolUse 钩子阻止读取 .env 等，凭据需在容器内登录一次并全局持久化。该 Skill 是 aic init / aic sync 之上的便利层，也支持对已有配置做差异审计。
安装并验证 aic CLI（npm install -g aicontainer，需 Node.js 18+）；检查前置条件（宿主终端、git 仓库、Docker 运行状态、是否已有 aic 配置）；扫描清单文件（package.、pyproject.toml、go.mod、Cargo.toml 等）、运行时版本锁定、Compose 服务、端到端测试工具和设计文档来推断技术栈，并向用户确认；对照适用性矩阵排除无法在无头 Linux 容器中运行的场景（iOS/macOS 原生、Windows 原生、需 USB 的嵌入式、GPU/CUDA 等）；随后生成项目自有文件——Dockerfile.project、docker-compose.override.yml、chown-paths、post-create.project.sh、vscode-extensions、vscode-settings.、firewall-allowlist、shell-rc.zsh、p10k.zsh、statusline.*——运行 aic init / aic sync 落地，引导用户完成一次性的 aic trust（需 TTY，必须由用户在宿主终端执行），并用 aic rebuild / aic up 启动验证（LSP 二进制在 PATH 上、命名卷可写、宿主服务可达、覆盖层已安装）。
- 在宿主机上用 Claude Code 开发 Python/TypeScript 项目的开发者，想保持 bypass 模式又不让代理接触真实 $HOME、.env 和 gh 令牌
- 维护多个并行业项目的工程师，希望登录一次凭据即可跨项目复用，同时各项目的会话记录、提示历史彼此隔离
- 项目需要 Playwright 浏览器测试或数据库客户端的团队，需要把 Chromium、apt 依赖和语言服务器烧进项目镜像并在重建后保留
- 已有几个月前搭好的 aic 环境的用户，项目新增了语言或服务，希望只审计并补齐缺失、过期或漂移的定制项
- 想在沙箱里保留个人 zsh 提示符、别名和 Claude 状态栏的重度终端用户，需要通过选择加入的覆盖层文件迁移宿主配置
- 审查不可信代码或受企业网络限制、需要启用出站网络白名单的安全敏感用户
这个 Skill 有哪些优点和局限？
- 核心价值真实且具体：让 bypass/auto-approve 模式可用而不暴露 $HOME、SSH、API 密钥和 gh 令牌
- 方法论严谨：检测先行、方案确认后落地、区分模板托管文件与项目自有文件、把 aic trust 明确交还用户而非绕过
- 边界完全可审计：aic preflight / doctor / status / validate 提供只读检查，信任绑定精确配置哈希、配置变更即失效
- 覆盖更新模式：对已有配置做缺失/过期/漂移三类审计，而非盲目重新生成
- 对常见陷阱有显式处理：aic up 不会触发构建、命名卷 root:root 所有权、NPM_CONFIG_IGNORE_SCRIPTS 对 postinstall 二进制的影响、git 钩子目录只读
- 依赖较重：需要 Docker Engine 25+、Compose 2.24+、Node.js 18+，首次拉取多 GB 镜像耗时数分钟
- 明确不支持的场景较多：iOS/macOS 原生、Windows 原生、需要宿主显示的桌面 GUI、USB/串口嵌入式、Android 模拟器、GPU/CUDA 默认不可用
- aic trust 需要 TTY，代理无法代为执行；任何对 Dockerfile.project 或 override 的后续修改都会撤销信任并需重新审批
- 凭据模型有明确权衡：任一项目中被攻破的会话可使用你在容器内登录的共享令牌；全局 shell 历史对所有项目可读
- headless 启动验证无法确认编辑器侧 IntelliSense（vscode-extensions 仅在 VS Code Dev Containers 会话中生效）
- 覆盖层文件逐字复制且容器内代理可读，绝不放入机密，宿主路径/用户名也会暴露在沙箱中；README 为截断版本，完整威胁模型细节未全部展示
如何安装这个 Skill？
前提：Docker Engine 25+（含 Compose 2.24+）、Node.js 18+、常规 git 检出。先全局安装 CLI：npm install -g aicontainer（或 git clone https://github.com/stefanoginella/aicontainer ~/.aicontainer && ~/.aicontainer/install.sh，此时需另装 npm install -g @devcontainers/cli）。本 Skill 来自 aicontainer 的 Claude Code 插件，在 Claude Code 内安装：/plugin marketplace add stefanoginella/claude-code-plugins，然后 /plugin install aicontainer@stefanoginella-plugins。仓库内 Skill 文件位于 tools/claude-plugin/skills/setup/SKILL.md。MIT 许可。
如何使用这个 Skill？
必须在宿主机（而非沙箱内）的 Claude Code 会话中运行：输入 /aicontainer:setup。Skill 会先检查前置条件并确认技术栈，然后展示完整定制计划（含每个文件的内容和理由），获得明确批准后写入项目自有文件并运行 aic init / aic sync；涉及 Dockerfile.project 时会提前告知需要你在自己的终端运行一次 aic trust，并在拉取多 GB 镜像前再次确认。完成后可用 aic shell 进入容器，直接运行 claude / codex / opencode；VS Code 用户可安装 Dev Containers 扩展后"在容器中重新打开"。首次登录（claude /login、codex auth login、gh auth login 等）在容器内进行一次即可全局持久化。
这个 Skill 与同类方案有什么区别？
源材料自述其形态与 Trail of Bits 的 claude-code-devcontainer 相近，但额外加入 Codex 与 OpenCode 支持、三种显式 Docker 访问模式以及托管的 shell/配置启动。