【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本文基于 gsd-coreGit. Ship. Done - Core仓库中的变更档案 .changeset/archived/mellow-lynx-forage.mdPR 3289类型 Fixed展开讲清一个真实的安装器缺陷schema 校验器曾把 Codexconfig.toml中所有hooks.*表一律按事件处理器的数组表array-of-tables下称 AoT来分类导致 Codex CLI 0.130.0 起引入的hooks.state.project/...每钩子信任状态表被误判为非法、安装被拒。读完本篇你将理解该误判的根因、修复在 bin/install.js 中的具体落点迁移与校验两条链路的 carve-out、以及 tests/codex-config-hooks.test.cjs 中用于锁定该行为的回归用例矩阵从而能够在遇到 Codex 配置文件校验报错时自行定位是事件表形状错误还是hooks.state 命名空间误伤。1. 变更档案说了什么变更档案原文.changeset/archived/mellow-lynx-forage.md只有简短的 front matter 和一句话描述front matter 标记type: Fixed、pr: 3289正文要点是get-shit-done-cc --codexno longer rejects valid Codexhooks.statetrust-persistence entries — the schema validator was over-classifying everyhooks.*table as an event-handler array-of-tables, breaking installs against Codex CLI 0.130.0 wherehooks.state.project/...stores per-hook trust state. Regular-table shape is now accepted forhooks.state.*whilehooks.EVENTstill requires AoT.把它拆解成三个可验证的事实断言症状执行--codex安装时校验器拒绝rejects合法的hooks.state信任持久化条目导致安装中断根因schema 校验器过度分类——把每一个hooks.*表都当作事件处理器的 AoT 来处理修复语义hooks.state.*命名空间接受常规表regular table形状而hooks.EVENT真正的钩子事件表仍然要求AoT 形状二者规则分轨。下面结合源码逐条印证这三点并补全0.124.0 格式变更 → 0.130.0 新增命名空间 → 校验器踩坑的完整时间线。2. 背景Codex config.toml 的钩子格式演进与 gsd-core 为什么要在意它gsd-core 安装到 Codex 运行时时会写入并维护用户的config.toml。在安装器源码 bin/install.js 中钩子配置的格式演进有明确注释记录bin/install.js#L5483-L5492Codex 0.124.0 之前map 风格的[hooks]容器 [hooks.TYPE]子表Codex 0.124.0 起改为 AoTarray-of-tables风格即[[hooks.TYPE]]且事件表内部的处理程序字段command、type、timeout、statusMessage必须嵌套在[[hooks.TYPE.hooks]]子表中Codex 0.130.0 起新增hooks.state命名空间用于持久化每个钩子的信任状态per-hook trust state形状是常规表例如子键是带引号的项目/钩子路径字符串。安装器对应地实现了三个关键纯函数均位于 bin/install.js函数位置职责migrateCodexHooksMapFormatbin/install.js#L5503把旧的 map 风格 / 扁平[[hooks]]/ 单层[[hooks.TYPE]]形状迁移到当前[[hooks.EVENT]]AoT 形式保留键值对与注释validateCodexConfigSchemabin/install.js#L6158安装前/后的结构校验解析 TOML 扫描表头按 Codex 当前 schema 规则逐条放行或拒绝stripStaleGsdHookBlocksbin/install.js#L5386用 TOML AST 结构性地剥离 GSD 自管的过期钩子块按command值识别而非正则缺陷正发生在validateCodexConfigSchema与migrateCodexHooksMapFormat共同依赖的那条粗粒度规则上凡是hooks.*路径的表都应按钩子事件表对待。3. 缺陷复盘一个合法的 0.130.0 配置为什么会安装失败Codex CLI 0.130.0 的用户config.toml中合法地存在这样的结构键名形状取自仓库回归测试的真实 fixture见 tests/codex-config-hooks.test.cjs#L2529-L2542[features] hooks true [[hooks.SessionStart]] matcher [[hooks.SessionStart.hooks]] command node gsd-check-update.js [hooks.state] [hooks.state./home/user/.codex/hooks.json:pre_tool_use:0:0] # Codex 写入的每钩子信任持久化字段注意最后一节[hooks.state....]是单括号常规表且子键是一个包含路径、冒号、点号的带引号 key。在修复前validateCodexConfigSchema的表头检查对一切以hooks.开头的非数组表统一执行事件表必须是 AoT的拒绝逻辑于是裸的[hooks.state]容器 → 被当作非法的单括号[hooks.Event]拒绝[hooks.state.key]→ 同样被拒绝。安装流程因此中断报错信息形如bare [hooks.state] table is invalid in current Codex schema (expected [[hooks.state]] array-of-tables)——错误提示反而建议用户把信任状态表改写成 AoT方向完全相反。这正是变更档案所说的 over-classifying everyhooks.*table as an event-handler array-of-tables。还有一个容易忽视的次生风险若不做 carve-outmigrateCodexHooksMapFormat会在迁移阶段把hooks.state.*这些常规表改写成[[hooks.state.*]]AoT 形式——不但不修复还会把合法配置主动写成 Codex 拒绝的形状。因此修复必须同时落在迁移与校验两条链路上源码中这两处都有对应的排除逻辑见下节。4. 修复落点一迁移函数排除 hooks.state 命名空间migrateCodexHooksMapFormat收集遗留 map 风格节的过滤器在修复后显式排除hooks.state与其全部子键bin/install.js#L5510-L5517// Exclude hooks.state and hooks.state.* — these are Codexs persistent hook-trust // namespace (Codex CLI 0.130.0) and use regular-table shape, never AoT. const legacyMapSections sections.filter( (section) !section.array ( section.path hooks || (section.path.startsWith(hooks.) section.segments.length 2 section.path ! hooks.state !section.path.startsWith(hooks.state.)) ) );两处细节值得注意section.segments.length 2而非单纯的前缀匹配。getTomlTableSectionsbin/install.js#L5118-L5133保留了表头真实解析出的 key 段数其注释明确说明动机要区分 2 段路径如带引号的hooks.before.toolkey 本身含点号与 3 段路径如hooks.SessionStart.hooks而不能对section.path做按点号 split——否则带引号、内含点号的事件名会被错误分级。hooks.state的排除同样依赖这个准确段数保证[hooks.state.key]2 段hooks 引号 key被正确识别。!section.path.startsWith(hooks.state.)覆盖任意深度子键hooks.state本身再用section.path ! hooks.state精确排除两者合起来封住整个命名空间。效果迁移阶段对hooks.state.*一律不看见只处理真正的遗留事件表用户注释与信任状态字段原样保留。5. 修复落点二校验器的分轨规则validateCodexConfigSchemabin/install.js#L6158采用表头形状检查 解析对象结构确认双通道。修复后的分轨规则完整表述如下通道一表头检查bin/install.js#L6203-L6221// hooks.state.* is Codexs persistent hook-trust namespace (added in // Codex CLI 0.130.0). It uses regular-table shape, NOT array-of-tables. // [[hooks.state]] or [[hooks.state.key]] (AoT) is invalid; reject it. if (section.array (section.path hooks.state || section.path.startsWith(hooks.state.))) { return { ok: false, reason: [[${section.path}]] is invalid; hooks.state namespace must use regular tables }; } // All other hooks.* paths (event handlers like hooks.SessionStart) require // AoT shape — bare [hooks.Event] (single-bracket) is invalid. if (!section.array section.path.startsWith(hooks.) section.path ! hooks.state !section.path.startsWith(hooks.state.)) { return { ok: false, reason: bare [${section.path}] table is invalid in current Codex schema (expected [[${section.path}]] array-of-tables) }; }即一张按路径前缀分轨的规则表表头形状路径修复前修复后[[hooks.state]]/[[hooks.state.key]]AoThooks.state*通过误放行错误形状拒绝hooks.state namespace must use regular tables[hooks.state]/[hooks.state.key]常规表hooks.state*拒绝误伤本 bug放行[hooks.Event]单括号其他hooks.*拒绝仍拒绝事件表必须 AoT[[hooks.Event]]AoT其他hooks.*通过仍通过通道二解析对象结构确认bin/install.js#L6227-L6261仅靠表头还不够——同一个解析后形状可能来自不同表头写法如[agents]default x与[agents.foo]解析结果无法仅凭对象区分源码注释对此有专门说明因此校验器对解析出的parsed.hooks对象再做结构确认if (event state) { if (Array.isArray(value)) { return { ok: false, reason: hooks.state must be a regular table/object, got array-of-tables }; } if (typeof value ! object || value null) { return { ok: false, reason: hooks.state must be a regular table/object, got ${typeof value} }; } continue; } // 其余 hooks.Event 必须仍是数组AoT if (!Array.isArray(value)) { return { ok: false, reason: hooks.${event} must be an array of tables, got ${typeof value} }; }关键在event state分支解析后hooks.state是一个普通对象因为它是常规表而非 AoT如果不在这里continue跳过就会被下面其他hooks.Event必须是数组的循环误拒——这正是测试用例hooks.state object in parsed structure does not trigger non-array rejectiontests/codex-config-hooks.test.cjs#L2585锁定的点。此外[[hooks.Event]]的 AoT 语义校验并未放松每个事件条目要么只含matcher等事件级键要么必须携带[[hooks.Event.hooks]]处理器子数组处理器字段command/type/timeout/statusMessage出现在事件条目顶层即拒绝bin/install.js#L6262-L6289。这保证了修复是精准分轨而非整体放宽。6. 回归测试矩阵#3285 用例组如何锁定修复回归用例集中在 tests/codex-config-hooks.test.cjs 的#3285标记用例组tests/codex-config-hooks.test.cjs#L2518标题直白validateCodexConfigSchema: hooks.state is a regular table (not AoT)。核心断言覆盖用例输入形状期望裸[hooks.state]表头2 段常规表通过[hooks.state.project-key]带引号键的常规表子键如[hooks.state./home/user/.codex/hooks.json:pre_tool_use:0:0]通过hooks.state与[[hooks.SessionStart]]AoT 共存混合形状两者都通过分轨不互相干扰解析结构中hooks.state为对象通道二不触发 must be an array 拒绝多个hooks.state.key子键多项目[hooks.state./project/a/...]、[hooks.state./project/b/...]全部通过[[hooks.state]]AoT 根拒绝且 reason 提及hooks.state[[hooks.state.foo]]AoT 子键拒绝且 reason 提及hooks.state另有端到端安装用例组#3285 — install succeeds when config.toml contains hooks.state entriestests/codex-config-hooks.test.cjs#L2657在临时安装目录写入含hooks.state信任条目的config.toml后执行安装断言安装不抛异常——直接对应变更档案中 breaking installs 的用户症状。仓库是只读的你可以只读地查看上述文件或按仓库自身测试入口运行对应用例来复现验证例如以 Node 执行tests/codex-config-hooks.test.cjs具体方式以仓库根 package.json 的 test 脚本与 TESTING-STANDARDS.md 为准。7. 给使用者的自查清单你的 config.toml 现在应该长什么样结合修复后的校验规则Codex 0.130.0 环境下 GSD 安装路径能接受的钩子区段形状可以归纳为# 事件钩子必须是 AoT处理器字段必须嵌套在 .hooks 子表 [[hooks.SessionStart]] matcher [[hooks.SessionStart.hooks]] command node gsd-check-update.js # 信任持久化必须是常规表单括号子键为带引号的路径字符串 [hooks.state] [hooks.state./home/user/.codex/hooks.json:pre_tool_use:0:0] trusted true # 字段内容以 Codex 实际写入为准此处仅示意形状对照检查时的判断口诀看到[[hooks.state开头 →形状错误GSD 校验会明确报hooks.state namespace must use regular tables需把双括号改回单括号常规表看到[hooks.SessionStart]单括号→形状错误报expected [[hooks.SessionStart]] array-of-tables需改为 AoT看到hooks.Event条目顶层挂着command ...而没有[[hooks.Event.hooks]]→ 这是 0.124.0 前被 Codex 拒绝的单层形状migrateCodexHooksMapFormat会在安装时将其提升为两级嵌套形式bin/install.js#L5529-L5551事件名含点号/空格时表头 key 必须是带引号的 TOML 字符串如hooks.before.tool这也是getTomlTableSections坚持用解析段数而非字符串 split 的原因。8. 小结这次修复PR 3289回归组 #3285的技术实质是在hooks.*命名空间内部为hooks.state开了一个双向 carve-out——迁移链路不碰它bin/install.js#L5510-L5517校验链路对它单独分轨常规表放行、AoT 与标量形状拒绝bin/install.js#L6203-L6261。它没有放松hooks.EVENT的 AoT 强制也没有把校验退化为只看表头而是保持了表头形状 解析对象结构双通道确认。对维护者而言该用例组tests/codex-config-hooks.test.cjs是理解 gsd-core 如何处理上游 CLI 格式演进 vs 本地 schema 校验这一类问题的良好范本每次 Codex 引入新命名空间正确动作是精准分轨 全形状矩阵的拒绝/放行断言而不是放宽前缀规则。关联文件索引变更档案 .changeset/archived/mellow-lynx-forage.md安装器实现 bin/install.jsmigrateCodexHooksMapFormat L5503、getTomlTableSections L5118、stripStaleGsdHookBlocks L5386、validateCodexConfigSchema L6158、installCodexConfig L7074回归测试 tests/codex-config-hooks.test.cjs。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐get-shit-doneGSDCodex Skill 物化契约解析修复 1.42.2 回归让 Codex CLI 0.130.0 重新路由 $gsd-* 命令get shit doneGSDCodex Skill 物化契约解析修复 1.42.2 回归让 Codex CLI 0.130.0 重新路由 $gsd人工智能AI 应用提示工程开发工具工作流自动化AI Agent修复 get-shit-done-cc --codex 拒绝合法 TOML 浮点数Codex 配置合并与安装回滚机制的源码级剖析修复 get shit done cc codex 拒绝合法 TOML 浮点数Codex 配置合并与安装回滚机制的源码级剖析 本篇以 .changeset/f人工智能AI 应用提示工程开发工具工作流自动化AI Agentget-shit-done 配置键白名单机制解析workflow._auto_chain_active 为何不再被 config-set 拒绝get shit done 配置键白名单机制解析workflow._auto_chain_active 为何不再被 config set 拒绝 本文以 get人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇Palworld存档工具深度解析技术架构与高级应用实战指南下一篇Palworld存档编辑器终极指南5分钟掌握游戏数据可视化修改创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考