get-shit-done 跨运行时安全执行Codex 下 execute-phase 如何对不支持的 worktree 隔离 Fail-Closed【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done导读本文围绕 get-shit-doneGSD一次真实修复展开 —— 变更集 .changeset/fix-3360-codex-execute-worktrees.md 记录的#3360/#3365。当 Codex 运行时配合workflow.use_worktreestrue时因其spawn_agent没有与 Claude CodeAgent(isolationworktree)等价的能力映射execute-phase 工作流必须在任何执行器派发前失败关闭fail closed而非让本应隔离于 git worktree 的写入代理直接改动主检出。读完后你将理解跨运行时隔离语义缺口、防护在 execute-phase 工作流 中的落地代码与顺序契约以及如何配置规避、用回归测试守住防线。背景execute-phase 的 wave 并行执行与 worktree 隔离GSD 是一套轻量的规范驱动开发spec-driven development方法论与工作流系统。其执行阶段execute-phase遵循协调者协调、不亲自执行的核心原则协调器orchestrator发现计划 → 分析依赖 → 分组为 wave → 派生执行代理 → 处理检查点 → 收集结果见 execute-phase.md 头部core_principle。为了支撑并行执行工作流默认依赖 git worktree 隔离每个执行代理gsd-executor被派发到独立的worktree-agent-id工作树分支上提交互不踩踏主检出的文件波次结束后由协调器统一合并回主分支并清理工作树对应 execute-phase.md 步骤 5.5 的 Worktree cleanup。而子代理派发本身是运行时特定的。execute-phase.md 的runtime_compatibility块 明示Claude Code使用Agent(subagent_typegsd-executor, ...)阻塞至完成并返回结果Copilot子代理派发无法可靠返回完成信号默认顺序内联执行仅在用户明确要求时才尝试并行其他运行时若Agent/agent工具不可用同样回退到顺序内联执行且需在运行时探测工具可用性而非按运行时名假设。也就是说派发并行隔离代理这件事从来都依赖底层运行时提供对应原语。# execute-phase initialize 步骤读取运行时与 worktree 配置 RUNTIME$(gsd-sdk query config-get runtime --default claude 2/dev/null || echo claude) USE_WORKTREES$(gsd-sdk query config-get workflow.use_worktrees 2/dev/null || echo true)workflow.use_worktrees默认值为truedocs/CONFIGURATION.mdSDK 配置门禁同样以workflowBool(wf.use_worktrees, true)归一sdk/src/query/config-gates.ts。根因isolationworktree在 Codex 中没有直接映射问题并不在 GSD 自身而是跨运行时能力不对齐Claude Code的Agent(...)/Task(...)支持isolationworktree参数派发出的代理会被放进独立 git worktreeCodex把子代理统一映射到spawn_agent而spawn_agent不会自动创建或绑定 git worktree。这条差异被固化在安装器内置的 Codex 技能适配头中。在 bin/install.js 的getCodexSkillAdapterHeader映射表 C. Task() → spawn_agent Mapping 里Task(isolationworktree)/Agent(isolationworktree)→no direct Codex mapping。Codexspawn_agentdoes not create or bind a git worktree automatically. Workflows that require this isolation must fail closed or use an explicit manual worktree protocol before spawning (#3360)。这正是 fix-3360-codex-execute-worktrees.md 描述的缺陷根源若工作流仍假定代理已被隔离而直接派发Codex 下这些写入型代理就会在**主检出main checkout**上编辑文件产生两类风险多个并行代理同时写主检出相互冲突协调器随后的 worktree 合并/清理逻辑找不到对应 worktree陷入以为已隔离、实则未隔离的错误信念。修复坚持的原则是当无法兑现文档所承诺的隔离语义时宁可停下报错也不在错误假设下继续。修复落地任何执行器派发前的 fail-closed 守卫修复位于 execute-phase 工作流的initialize步骤在任何执行器派发之前先读运行时与 worktree 配置再执行守卫if [ $RUNTIME codex ] [ $USE_WORKTREES ! false ]; then echo FATAL: Codex execute-phase worktree isolation is unsupported. Set workflow.use_worktreesfalse or use a runtime with Agent isolation\worktree\ support. 2 exit 1 fi # 在派发执行器之前清扫上次崩溃会话遗留的锁定 worktree#3707。 [ $USE_WORKTREES ! false ] gsd-sdk query worktree.reap-orphans 2/dev/null || true拆解它的三个要点条件成立才拦仅当RUNTIMEcodex且USE_WORKTREES ! false才exit 1。Codex 显式关闭 worktree 的组合不受影响Claude Code 等运行时完全不触发。派发前置守卫位于initialize步骤早于execute_waves内任何Agent()/spawn_agent调用不做无用派发、不残留半截产物。报错可操作FATAL 消息直接给出两条出路 —— 设workflow.use_worktreesfalse或改用支持isolationworktree的运行时。工作流注释点明了为何宁可 fail closedCodex maps subagents tospawn_agent, which has no direct Codex mapping for Claude Codesisolationworktreeparameter. Failing closed prevents main-checkout edits while the workflow believes agents are isolated.配置规避与安全降级路径对确需在 Codex 下运行 execute-phase 的团队规避办法是把项目配置的workflow.use_worktrees显式置为false。依据 docs/CONFIGURATION.md配置项类型默认值说明workflow.use_worktreesbooleantrue置false时关闭并行执行的 git worktree 隔离。偏好顺序执行、或环境不支持 worktree 时可关闭v1.31 起加入。项目级USE_WORKTREESfalse时所有执行代理不带isolationworktree改在主工作树上执行execute-phase.md 明确指出此时逐计划决策不再生效。在同波内出现部分计划保留隔离、部分退化为顺序的混合场景时工作流要求退化的计划逐个串行避免并发写主工作树保留隔离的计划仍可并行execute-phase.md 步骤 2.5 与混合模式说明。类似按计划粒度而非一刀切的工程取舍还出现在同一 initialize 步骤的子模块处理从.gitmodules解析出SUBMODULE_PATHS后仅当某计划声明的files_modified与子模块路径相交时才为其关闭隔离执行器提交协议无法在隔离 worktree 中正确处理子模块提交与子模块无关的计划照常并行隔离 —— 相比旧版见.gitmodules即全局关闭明显更精准。回归测试以契约锁住防护时序为防止后续改动把守卫挪到派发之后、或删掉适配文档的映射说明仓库提供了回归测试 tests/bug-3360-codex-execute-phase-worktrees.test.cjs。它解析工作流中的step块并断言initialize步骤必须读取运行时配置含RUNTIME$(gsd-sdk query config-get runtime --default claudeinitialize必须包含 Codex worktree 守卫文案Codex execute-phase worktree isolation is unsupported守卫步骤必须先于任何 worktree 派发指导guardStepPrecedesWorktreeDispatch: trueCodex 适配头必须记录映射缺口同时匹配isolationworktree与no direct Codex mapping。测试最终断言契约对象{ initializeReadsRuntimeConfig: true, initializeHasCodexWorktreeGuard: true, guardStepPrecedesWorktreeDispatch: true, }可见测试守住的不仅是报错文案存在更是**先读运行时 → 再拦 Codex worktree → 才允许派发这一修复时序**。发布与版本上下文该修复经 PR #3365 合入变更集 frontmatter 标记type: Fixed, pr: 3365。在 docs/RELEASE-v1.42.1.md 发布说明中它被归入 Codex install and hook migration are safer描述为 unsupported execute-phase worktrees are blocked其行为依据即本变更集。若需在具体项目中验证当前是否已包含该防护可直接查看工作流守卫段与对应回归测试是否如本文所述存在。小结一份寥寥数行的 changeset 背后是一整套可验证的工程防线能力缺口写进适配映射表bin/install.js执行路径在最前置的initialize步骤 fail-closedexecute-phase.md错误消息给出可操作规避方案回归测试则把守卫先于派发固化为机器可校验的契约tests/bug-3360-codex-execute-phase-worktrees.test.cjs。对跨运行时编排系统而言没有隔离能力就绝不假装有隔离比任何绕过技巧都更能保护主检出与并行执行语义的完整性。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考