Archon 容器隔离为 Folder 项目工作流提供 Overlay 隔离的 Docker 执行与审批门控写回【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/ArchonArchon 的Container Isolation容器隔离让 folder 项目多仓库根目录或纯业务运营目录即非 Git 工作区的整个工作流在一个 Docker 容器中运行项目根以只读挂载进容器所有写入落在可写 overlay upper 层上直到你显式批准任何改动都不会触碰实时目录live root。读完本文你会掌握--container运行工作流的完整命令与审批流程、runner 镜像的构建方式、overlay 挂载模式fuse/native的安全差异以及从packages/isolation源码层面理解暂停/恢复与写回的实现原理。该特性仅适用于 folder 项目repo 项目走 git worktrees 隔离不受影响见 后端路由 中的 folder-only 约束。工作原理只读 lower 可写 overlay upper文档给出的整体生命周期如下源自 container-isolation 指南prepare → container (root mounted read-only, overlay upper on a per-run volume) claude bash/script nodes all run INSIDE via docker exec env the Archon-managed bag auth only (never the host process.env) │ … approval gate? → docker stop (0 RAM while paused) → approve/resume → docker start │ nodes done → WRITE-BACK GATE: overlay diff summarized, run pauses │ approve → diff applied to the live root → run completed reject → diff discarded, live root untouched → run completed (noted) │ teardown → container volume removed几个关键机制均可在源码中印证overlay 的 upper 层本身就是 diff。由 overlayfs 的构造决定计算改了什么只是一次目录遍历directory walk而不是整树比较。写回摘要与应用逻辑位于 overlay.ts由 ContainerBackend.finalize/applyChanges 调用。所有节点都在容器内执行。Claude 节点通过 SDK 的spawnClaudeCodeProcess钩子转成docker execbash:/script:节点同样在同一个容器里 exec而不是悄悄回落到宿主机执行——源码注释明确写着 so isolation has no host-escape hole见 container.ts 文件头注释。环境隔离容器只接收 Archon 管理的环境袋codebase env 每用户 AI 凭据 GitHub token宿主process.env从不跨界。容器资源上限docker run时带--memoryMiB、--pids-limit防 fork 炸弹、--network bridge|none对应 types.ts 中ContainerBackendConfig的四个字段image、network: bridge | none、memoryMb、pidsLimit。CLI 侧解析时会校验 network 必须是 bridge/nonehost 网络被显式禁止。同绝对路径不变量合并后的 overlay 被挂载在与宿主 cwd完全相同的绝对路径上因此working_path与所有路径替换在容器内外含义一致无需任何路径翻译层见 entrypoint.sh 中挂载到$ARCHON_WORKSPACE_PATH的逻辑。资源命名与标签每次运行创建archon-uuid容器与archon-uuid-upper卷并打上diy.archon.managed、diy.archon.codebase-id、diy.archon.env-id三个标签CONTAINER_LABELS定义于 types.ts。isolation list/cleanup与恢复逻辑都靠标签而非名称猜测来定位资源。容器显式--restart no避免自动重启把被刻意暂停的容器复活重跑。容器内还有一个细节CLAUDE_CONFIG_DIR被设为/mnt/upper/claude-home它是 overlay data/work 目录的兄弟目录——Claude 会话状态因此能在同一次运行的 stop/start 间存活又永远不会污染写回的文件 diff见 runner.Dockerfile 注释。前置条件与 runner 镜像宿主机上运行DockerEngine ≥ 20.10 / Docker Desktop。一次性构建 runner 镜像使用仓库内置 Dockerfilebun run build:runner-image该命令由 build-runner-image.sh 实现从根 package.json 读取版本号构建packages/isolation/docker/runner.Dockerfile同时打上archon-runner:version与archon-runner:latest默认使用两个标签也可用ARCHON_RUNNER_TAG自定义标签。runner 镜像runner.Dockerfile的内容值得细看它直接解释了为什么 claude/bash/script 节点都能在容器内跑基础镜像debian:bookworm-slim按 digest 锁定保证可复现版本钉死的工具链Claude Code 原生二进制构建参数CLAUDE_VERSION2.1.211、bun1.4.2、uv0.11.29另装git、bash、rsync、fuse-overlayfsoverlay 降级方案、procpsENV IS_SANDBOX1Claude Code 在 root 下拒绝--dangerously-skip-permissions除非有该标志——容器内工作有意以 root 运行跨宿主只读 lower 层写入需要 root隔离边界由容器本身承担git config --system --add safe.directory *合并 overlay 挂载在宿主绝对路径上git 会把其中的文件标记为 dubious-ownership容器是单用途隔离环境所以信任所有路径。供应链上有一个文档化的已知残留厂商安装脚本claude.ai/install.sh等在构建时经 TLS 拉取执行工具版本已钉死但脚本本身没有独立校验和——见 SECURITY.md。运行与写回审批门在 folder 根目录注册并一次跑进容器# Register the folder run in a container in one go cd /path/to/ops-root bun run cli workflow run assist --folder --container reorganize the invoices你会看到容器启动、节点在容器内执行然后——如果运行结束时存在变更——出现write-back gate写回审批门Container run finished — review before applying to the live folder. 7 file(s) changed (3 added, 3 modified, 1 deleted): invoices/2026-06/summary.md ~ invoices/index.md - invoices/stale.tmp … and 3 more Approve to APPLY these changes to the live folder, or reject to discard them.像对待任何暂停一样驱动它bun run cli workflow approve run-id # apply the diff to the live root, then complete bun run cli workflow reject run-id # discard the overlay, live root untouched, complete两条补充规则来自文档与源码的双重确认空 diff 跳过审批门静默完成。finalize()返回requiresApproval: changeSummary.totalCount 0container.ts零变更就不会暂停。在工作流上设置container.write_back: auto可免暂停自动应用记入日志适合无人值守任务。schema 层只有两个取值packages/workflows/src/schemas/workflow.ts中write_back: z.enum([approve, auto]).optional()CLI 组装写回上下文时默认取workflow.container?.write_back ?? approve。注意写回是唯一触碰实时根目录的时刻approve 时 diff 应用到 live rootreject 时 overlay 被丢弃、live root 原样保留两种情况下运行都视为完成。discardChanges的实现甚至只是一个 breadcrumb 日志——丢弃就是不碰 live root然后 destroy。选择优先级与配置后端选择遵循四级优先级CLI 源码注释与文档一致--container flag workflow container.enabled config container.enabled off其中 config 即.archon/config.yaml的container:块包含 runner 镜像image、网络network: bridge|none、内存上限memoryMbMiB、进程上限pidsLimit——对应前文ContainerBackendConfig四字段。完整字段说明见文档站 configuration 参考 的 container 小节。选择逻辑集中在一个缝隙seam里resolveFolderBackend。对 repo 项目调用它属于调用方错误直接抛错对 folder 项目container: true时返回具体的ContainerBackend否则返回InPlaceBackend默认即原地执行、每次写入立即落盘的既有行为。还有一个防坑设计要求了container却缺少 store 或 containerConfig 时会 fail-fast 抛错绝不静默降级成 in-place 运行——用户要了容器就不能悄悄在宿主上跑。配套的环境管理命令archon isolation list显示活跃的容器环境暂停中运行的容器会带存活时长列在这里且永不被自动清理archon isolation cleanup收割超过阈值的终端态/孤儿运行的容器 卷。暂停经济学与恢复语义任何暂停——运行中途的审批/交互门或结尾的写回门——都会docker stop容器。多日等待的 CPU/RAM 成本约为零。审批/拒绝/恢复时按diy.archon.env-id标签重新发现容器并docker start若容器已不存在则在持久化的 upper 卷之上重建容器继续。恢复的四分支语义在 resumeEnv 中逐字实现状态行为容器存在且在跑原样复用容器存在但已停止docker start 重新等待 overlay ready容器消失但 upper 卷还在在同一卷上重建容器overlay 累积成果保留卷也消失了大声失败——未应用的改动已丢失绝不从空 overlay 静默重启卷是唯一保存未应用成果的地方所以卷没了就报错是刻意的错误信息会明确提示很可能是docker volume rm或激进的 prune 干的暂停中的运行永不被自动清理。另一条重要限制容器暂停只能从 CLI 恢复因为只有 CLI 侧接了 Docker 后端。从 chat/web 批准一个容器运行会失败并给出指向 CLI 的提示运行本身保持可恢复状态。工程上还有一个防泄漏细节暂停和销毁时都会对 artifacts 挂载做一次尽力而为的chown归还restoreHostOwnership——rootful Linux daemon 上容器内 root 写入的文件会是 root 属主Archon 在 suspend/destroy 时把它交还给宿主用户。Provider 支持矩阵Provider容器内说明Claude支持通过docker exec启动其 CLI二进制已烘焙进 runner 镜像Codex待实现需要 Codex SDK 的 spawn/transport 覆写 镜像内二进制CODEX_HOME/auth.json放在 upper 卷。当前经containerExec能力位快速失败Pi待实现进程内 harness需要容器 tool-transportFlue 风格或镜像内 shimOpenCode / Copilot / community待实现声明containerExec: true并基于ExecutionContext契约实现自己的容器内 exec 翻译关键安全性质非 Claude 节点在容器运行中会在任何节点执行前快速失败fail fast before any node executes错误信息中会点名 provider 与containerExec能力位——永远不会出现静默的宿主逃逸。安全姿态隔离强化而非对抗性沙箱容器就是隔离边界只读 lower bind 位于 VM-local 卷上的 overlay upper 仅 Archon 管理的环境 审批门控写回。apply 是唯一写 live root 的时刻。overlay 挂载模式按最小权限优先选择OVERLAY_MODES [fuse, native]backend 依次尝试、保留第一个成功者模式授权能否重挂载只读 lower适用 daemonfuse首选仅--device /dev/fuse无CAP_SYS_ADMIN不能——remount 逃逸被堵死rootless / userns-remapnative回退--cap-add SYS_ADMIN --security-opt apparmorunconfined能——容器内 root 可mount -o remount,rw /mnt/lower标准 rootful daemon如默认 Docker Desktop这意味着在标准 rootful daemon 上会落到native它提供的是隔离强化isolation-hardening而不是针对恶意/prompt-injected agent 的沙箱。引擎在实际落到native模式时会发出响亮的运行开始警告PreparedEnv.overlayMode字段 isolation.container_overlay_fallback日志。要拿到强边界无CAP_SYS_ADMIN请以 rootless 或 userns-remap 方式运行 daemon。完整威胁模型包括docker exec -e使密钥短暂出现在宿主进程表、capture 完整性检查是检查点检测而非包含等边界都写在 packages/isolation/docker/SECURITY.md——运行不受信任的工作前请先读它。两个 Archon 自有的宿主目录按宿主路径原样绑定进容器本次运行冻结的工作流源码只读$ARTIFACTS_DIR读写——这是容器内节点把截图、报告、evidence_policy标记留在引擎与操作者都能读的地方的通道也是容器唯一可写的宿主目录内容是运行输出宿主永不执行。挂载路径本身也有一道防御assertMountableHostPath拒绝非绝对路径、ARCHON_HOME之外的路径以及与工作区根重叠的路径防止影子 overlay 根。写回 apply 的加固来自 SECURITY.md实现于 overlay.tsupper 层被视为攻击者可控输入——摘要与应用助手都在一次性容器里以--cap-drop ALL --network none --security-opt no-new-privileges运行whiteout 解码名拒绝空/./../含斜杠所有写入被父目录 symlink 守卫限制在目标下并开set -f只复制常规文件、真实目录与项目内symlink特殊设备文件整体跳过setuid/setgid 位被剥除、按内容复制惰性落盘目标逃出项目根的 symlink 被拒绝并在变更摘要中点名。macOS / Linux 平台注意overlay 的 upper/work 目录放在VM-local 命名卷上绝不用宿主 bind mount——宿主 bind 的 upperdir 在 macOS 上会撞EACCESentrypoint 注释引用了 orbstack#1376。合并 overlay 挂载在与宿主 cwd相同的绝对路径容器内路径语义零变化。标准 Docker Desktop / rootful Engine daemon 上预期落到nativeCAP_SYS_ADMINoverlay 模式。深入源码的索引主题文件容器后端实现prepare/destroy/suspend/resumeEnv/finalize/apply/discardpackages/isolation/src/backends/container.tsfolder 后端选择缝隙in-place vs containerpackages/isolation/src/backend-router.ts后端契约、ContainerBackendConfig、Docker 标签常量packages/isolation/src/types.tsoverlay diff 摘要 / 写回应用packages/isolation/src/container/overlay.ts容器执行与 docker 预检封装packages/isolation/src/container/docker-exec.tsrunner 镜像工具钉版、IS_SANDBOX、CLAUDE_CONFIG_DIRpackages/isolation/docker/runner.Dockerfileoverlay 挂载入口脚本fuse/native 分支、ready sentinelpackages/isolation/docker/entrypoint.sh威胁模型与写回加固清单packages/isolation/docker/SECURITY.mdCLI 侧--container解析、优先级与销毁保障packages/cli/src/commands/workflow.tscontainer.write_back的 schemaapprove/autopackages/workflows/src/schemas/workflow.tsrunner 镜像构建脚本scripts/build-runner-image.sh本文档来源packages/docs-web/src/content/docs/guides/container-isolation.md从 CLI 源码结构还能看到一个值得留意的运维性质终端态运行会销毁容器 卷暂停态运行保留已挂起的容器与卷供恢复而当写回悬而未决overlay diff 已产生但未批准时容器与卷同样被保留——因为 overlay 是未应用成果的唯一载体误销毁等于丢失工作teardown 失败且运行本身成功时CLI 会以非零退出码报告泄漏了一个带权限的容器不算成功。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Archon 容器隔离：为 Folder 项目工作流提供 Overlay 隔离的 Docker 执行与审批门控写回
Archon 容器隔离为 Folder 项目工作流提供 Overlay 隔离的 Docker 执行与审批门控写回【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/ArchonArchon 的Container Isolation容器隔离让 folder 项目多仓库根目录或纯业务运营目录即非 Git 工作区的整个工作流在一个 Docker 容器中运行项目根以只读挂载进容器所有写入落在可写 overlay upper 层上直到你显式批准任何改动都不会触碰实时目录live root。读完本文你会掌握--container运行工作流的完整命令与审批流程、runner 镜像的构建方式、overlay 挂载模式fuse/native的安全差异以及从packages/isolation源码层面理解暂停/恢复与写回的实现原理。该特性仅适用于 folder 项目repo 项目走 git worktrees 隔离不受影响见 后端路由 中的 folder-only 约束。工作原理只读 lower 可写 overlay upper文档给出的整体生命周期如下源自 container-isolation 指南prepare → container (root mounted read-only, overlay upper on a per-run volume) claude bash/script nodes all run INSIDE via docker exec env the Archon-managed bag auth only (never the host process.env) │ … approval gate? → docker stop (0 RAM while paused) → approve/resume → docker start │ nodes done → WRITE-BACK GATE: overlay diff summarized, run pauses │ approve → diff applied to the live root → run completed reject → diff discarded, live root untouched → run completed (noted) │ teardown → container volume removed几个关键机制均可在源码中印证overlay 的 upper 层本身就是 diff。由 overlayfs 的构造决定计算改了什么只是一次目录遍历directory walk而不是整树比较。写回摘要与应用逻辑位于 overlay.ts由 ContainerBackend.finalize/applyChanges 调用。所有节点都在容器内执行。Claude 节点通过 SDK 的spawnClaudeCodeProcess钩子转成docker execbash:/script:节点同样在同一个容器里 exec而不是悄悄回落到宿主机执行——源码注释明确写着 so isolation has no host-escape hole见 container.ts 文件头注释。环境隔离容器只接收 Archon 管理的环境袋codebase env 每用户 AI 凭据 GitHub token宿主process.env从不跨界。容器资源上限docker run时带--memoryMiB、--pids-limit防 fork 炸弹、--network bridge|none对应 types.ts 中ContainerBackendConfig的四个字段image、network: bridge | none、memoryMb、pidsLimit。CLI 侧解析时会校验 network 必须是 bridge/nonehost 网络被显式禁止。同绝对路径不变量合并后的 overlay 被挂载在与宿主 cwd完全相同的绝对路径上因此working_path与所有路径替换在容器内外含义一致无需任何路径翻译层见 entrypoint.sh 中挂载到$ARCHON_WORKSPACE_PATH的逻辑。资源命名与标签每次运行创建archon-uuid容器与archon-uuid-upper卷并打上diy.archon.managed、diy.archon.codebase-id、diy.archon.env-id三个标签CONTAINER_LABELS定义于 types.ts。isolation list/cleanup与恢复逻辑都靠标签而非名称猜测来定位资源。容器显式--restart no避免自动重启把被刻意暂停的容器复活重跑。容器内还有一个细节CLAUDE_CONFIG_DIR被设为/mnt/upper/claude-home它是 overlay data/work 目录的兄弟目录——Claude 会话状态因此能在同一次运行的 stop/start 间存活又永远不会污染写回的文件 diff见 runner.Dockerfile 注释。前置条件与 runner 镜像宿主机上运行DockerEngine ≥ 20.10 / Docker Desktop。一次性构建 runner 镜像使用仓库内置 Dockerfilebun run build:runner-image该命令由 build-runner-image.sh 实现从根 package.json 读取版本号构建packages/isolation/docker/runner.Dockerfile同时打上archon-runner:version与archon-runner:latest默认使用两个标签也可用ARCHON_RUNNER_TAG自定义标签。runner 镜像runner.Dockerfile的内容值得细看它直接解释了为什么 claude/bash/script 节点都能在容器内跑基础镜像debian:bookworm-slim按 digest 锁定保证可复现版本钉死的工具链Claude Code 原生二进制构建参数CLAUDE_VERSION2.1.211、bun1.4.2、uv0.11.29另装git、bash、rsync、fuse-overlayfsoverlay 降级方案、procpsENV IS_SANDBOX1Claude Code 在 root 下拒绝--dangerously-skip-permissions除非有该标志——容器内工作有意以 root 运行跨宿主只读 lower 层写入需要 root隔离边界由容器本身承担git config --system --add safe.directory *合并 overlay 挂载在宿主绝对路径上git 会把其中的文件标记为 dubious-ownership容器是单用途隔离环境所以信任所有路径。供应链上有一个文档化的已知残留厂商安装脚本claude.ai/install.sh等在构建时经 TLS 拉取执行工具版本已钉死但脚本本身没有独立校验和——见 SECURITY.md。运行与写回审批门在 folder 根目录注册并一次跑进容器# Register the folder run in a container in one go cd /path/to/ops-root bun run cli workflow run assist --folder --container reorganize the invoices你会看到容器启动、节点在容器内执行然后——如果运行结束时存在变更——出现write-back gate写回审批门Container run finished — review before applying to the live folder. 7 file(s) changed (3 added, 3 modified, 1 deleted): invoices/2026-06/summary.md ~ invoices/index.md - invoices/stale.tmp … and 3 more Approve to APPLY these changes to the live folder, or reject to discard them.像对待任何暂停一样驱动它bun run cli workflow approve run-id # apply the diff to the live root, then complete bun run cli workflow reject run-id # discard the overlay, live root untouched, complete两条补充规则来自文档与源码的双重确认空 diff 跳过审批门静默完成。finalize()返回requiresApproval: changeSummary.totalCount 0container.ts零变更就不会暂停。在工作流上设置container.write_back: auto可免暂停自动应用记入日志适合无人值守任务。schema 层只有两个取值packages/workflows/src/schemas/workflow.ts中write_back: z.enum([approve, auto]).optional()CLI 组装写回上下文时默认取workflow.container?.write_back ?? approve。注意写回是唯一触碰实时根目录的时刻approve 时 diff 应用到 live rootreject 时 overlay 被丢弃、live root 原样保留两种情况下运行都视为完成。discardChanges的实现甚至只是一个 breadcrumb 日志——丢弃就是不碰 live root然后 destroy。选择优先级与配置后端选择遵循四级优先级CLI 源码注释与文档一致--container flag workflow container.enabled config container.enabled off其中 config 即.archon/config.yaml的container:块包含 runner 镜像image、网络network: bridge|none、内存上限memoryMbMiB、进程上限pidsLimit——对应前文ContainerBackendConfig四字段。完整字段说明见文档站 configuration 参考 的 container 小节。选择逻辑集中在一个缝隙seam里resolveFolderBackend。对 repo 项目调用它属于调用方错误直接抛错对 folder 项目container: true时返回具体的ContainerBackend否则返回InPlaceBackend默认即原地执行、每次写入立即落盘的既有行为。还有一个防坑设计要求了container却缺少 store 或 containerConfig 时会 fail-fast 抛错绝不静默降级成 in-place 运行——用户要了容器就不能悄悄在宿主上跑。配套的环境管理命令archon isolation list显示活跃的容器环境暂停中运行的容器会带存活时长列在这里且永不被自动清理archon isolation cleanup收割超过阈值的终端态/孤儿运行的容器 卷。暂停经济学与恢复语义任何暂停——运行中途的审批/交互门或结尾的写回门——都会docker stop容器。多日等待的 CPU/RAM 成本约为零。审批/拒绝/恢复时按diy.archon.env-id标签重新发现容器并docker start若容器已不存在则在持久化的 upper 卷之上重建容器继续。恢复的四分支语义在 resumeEnv 中逐字实现状态行为容器存在且在跑原样复用容器存在但已停止docker start 重新等待 overlay ready容器消失但 upper 卷还在在同一卷上重建容器overlay 累积成果保留卷也消失了大声失败——未应用的改动已丢失绝不从空 overlay 静默重启卷是唯一保存未应用成果的地方所以卷没了就报错是刻意的错误信息会明确提示很可能是docker volume rm或激进的 prune 干的暂停中的运行永不被自动清理。另一条重要限制容器暂停只能从 CLI 恢复因为只有 CLI 侧接了 Docker 后端。从 chat/web 批准一个容器运行会失败并给出指向 CLI 的提示运行本身保持可恢复状态。工程上还有一个防泄漏细节暂停和销毁时都会对 artifacts 挂载做一次尽力而为的chown归还restoreHostOwnership——rootful Linux daemon 上容器内 root 写入的文件会是 root 属主Archon 在 suspend/destroy 时把它交还给宿主用户。Provider 支持矩阵Provider容器内说明Claude支持通过docker exec启动其 CLI二进制已烘焙进 runner 镜像Codex待实现需要 Codex SDK 的 spawn/transport 覆写 镜像内二进制CODEX_HOME/auth.json放在 upper 卷。当前经containerExec能力位快速失败Pi待实现进程内 harness需要容器 tool-transportFlue 风格或镜像内 shimOpenCode / Copilot / community待实现声明containerExec: true并基于ExecutionContext契约实现自己的容器内 exec 翻译关键安全性质非 Claude 节点在容器运行中会在任何节点执行前快速失败fail fast before any node executes错误信息中会点名 provider 与containerExec能力位——永远不会出现静默的宿主逃逸。安全姿态隔离强化而非对抗性沙箱容器就是隔离边界只读 lower bind 位于 VM-local 卷上的 overlay upper 仅 Archon 管理的环境 审批门控写回。apply 是唯一写 live root 的时刻。overlay 挂载模式按最小权限优先选择OVERLAY_MODES [fuse, native]backend 依次尝试、保留第一个成功者模式授权能否重挂载只读 lower适用 daemonfuse首选仅--device /dev/fuse无CAP_SYS_ADMIN不能——remount 逃逸被堵死rootless / userns-remapnative回退--cap-add SYS_ADMIN --security-opt apparmorunconfined能——容器内 root 可mount -o remount,rw /mnt/lower标准 rootful daemon如默认 Docker Desktop这意味着在标准 rootful daemon 上会落到native它提供的是隔离强化isolation-hardening而不是针对恶意/prompt-injected agent 的沙箱。引擎在实际落到native模式时会发出响亮的运行开始警告PreparedEnv.overlayMode字段 isolation.container_overlay_fallback日志。要拿到强边界无CAP_SYS_ADMIN请以 rootless 或 userns-remap 方式运行 daemon。完整威胁模型包括docker exec -e使密钥短暂出现在宿主进程表、capture 完整性检查是检查点检测而非包含等边界都写在 packages/isolation/docker/SECURITY.md——运行不受信任的工作前请先读它。两个 Archon 自有的宿主目录按宿主路径原样绑定进容器本次运行冻结的工作流源码只读$ARTIFACTS_DIR读写——这是容器内节点把截图、报告、evidence_policy标记留在引擎与操作者都能读的地方的通道也是容器唯一可写的宿主目录内容是运行输出宿主永不执行。挂载路径本身也有一道防御assertMountableHostPath拒绝非绝对路径、ARCHON_HOME之外的路径以及与工作区根重叠的路径防止影子 overlay 根。写回 apply 的加固来自 SECURITY.md实现于 overlay.tsupper 层被视为攻击者可控输入——摘要与应用助手都在一次性容器里以--cap-drop ALL --network none --security-opt no-new-privileges运行whiteout 解码名拒绝空/./../含斜杠所有写入被父目录 symlink 守卫限制在目标下并开set -f只复制常规文件、真实目录与项目内symlink特殊设备文件整体跳过setuid/setgid 位被剥除、按内容复制惰性落盘目标逃出项目根的 symlink 被拒绝并在变更摘要中点名。macOS / Linux 平台注意overlay 的 upper/work 目录放在VM-local 命名卷上绝不用宿主 bind mount——宿主 bind 的 upperdir 在 macOS 上会撞EACCESentrypoint 注释引用了 orbstack#1376。合并 overlay 挂载在与宿主 cwd相同的绝对路径容器内路径语义零变化。标准 Docker Desktop / rootful Engine daemon 上预期落到nativeCAP_SYS_ADMINoverlay 模式。深入源码的索引主题文件容器后端实现prepare/destroy/suspend/resumeEnv/finalize/apply/discardpackages/isolation/src/backends/container.tsfolder 后端选择缝隙in-place vs containerpackages/isolation/src/backend-router.ts后端契约、ContainerBackendConfig、Docker 标签常量packages/isolation/src/types.tsoverlay diff 摘要 / 写回应用packages/isolation/src/container/overlay.ts容器执行与 docker 预检封装packages/isolation/src/container/docker-exec.tsrunner 镜像工具钉版、IS_SANDBOX、CLAUDE_CONFIG_DIRpackages/isolation/docker/runner.Dockerfileoverlay 挂载入口脚本fuse/native 分支、ready sentinelpackages/isolation/docker/entrypoint.sh威胁模型与写回加固清单packages/isolation/docker/SECURITY.mdCLI 侧--container解析、优先级与销毁保障packages/cli/src/commands/workflow.tscontainer.write_back的 schemaapprove/autopackages/workflows/src/schemas/workflow.tsrunner 镜像构建脚本scripts/build-runner-image.sh本文档来源packages/docs-web/src/content/docs/guides/container-isolation.md从 CLI 源码结构还能看到一个值得留意的运维性质终端态运行会销毁容器 卷暂停态运行保留已挂起的容器与卷供恢复而当写回悬而未决overlay diff 已产生但未批准时容器与卷同样被保留——因为 overlay 是未应用成果的唯一载体误销毁等于丢失工作teardown 失败且运行本身成功时CLI 会以非零退出码报告泄漏了一个带权限的容器不算成功。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考