shiyue/cc-web
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
cc-web/task_plan.md
shiyue ddd97398e7 chore: rebuild CentOS7 release package
2026-07-01 00:00:29 +08:00

2.3 KiB
Raw Permalink Blame History

cc-web Codex hooks 验证计划

Goal

验证 cc-web 的 Codex App 模式下，Codex hooks 应由谁加载、当前链路是否让 app-server 发现项目/全局 hooks，以及 planning-with-files hook 没体现效果的真实原因。

Status

  • 建立验证计划
  • 官方文档验证：确认 app-server/hooks 官方支持边界
  • cc-web 实现链路验证：确认 cwd、CODEX_HOME、thread params、config 注入逻辑
  • 本地环境/触发条件验证：确认 hook 文件、active plan、trust/feature 开关等条件
  • 汇总结论：明确是否需要 cc-web 改造，以及改造点

Focused Breakpoints

  • app-server 进程看到的 CODEX_HOME / HOME 是否正确
  • thread/start / thread/resume 的 cwd 是否为 /home/cc-web
  • /home/cc-web/.codex 项目层是否被 Codex trust
  • .codex/hooks.json 里的 command hook 是否已 review/trust
  • [features].hooks 是否被关闭
  • 最小 marker hook 是否能证明 app-server 触发 hooks

Final Synthesis

  • 当前目标会话没看到 planning-with-files hook 效果，主因是项目 hooks 的 command hash 未被 Codex trust：hooks/list 已显示 7 条 command hook 全部 untrusted。
  • HOME/CODEX_HOME、thread cwd、项目根 trust、[features].hooks 这些前置条件在当前 local 模式下都不是阻断点。
  • planning-with-files 脚本本身有效；手动 smoke test 可输出 active plan。它的效果被 Codex command hook trust 层挡住，而不是 skill 逻辑坏。
  • cc-web 不应自行模拟执行 hooks，也不应把 thread/start.config.hooks.* 当主路径；应让 Codex app-server 原生 hooks/list/trust 机制工作，并补诊断/信任入口。

Questions

  1. thread/start.config.hooks.* 是否有官方文档支持，还是不应作为主路径？
  2. cc-web 是否应该自行执行 hooks，还是只保证 app-server 能看到官方 config layers？
  3. 当前项目 hooks 没生效，更可能是哪一层断了？
  4. 如何用最小可复现实验证明 app-server 端是否加载并执行 hooks？

Constraints

  • 不修改业务代码。
  • 不覆盖用户已有未提交改动。
  • 代码理解优先使用 codebase-memory-mcp，不用 graphify。
  • 官方 Codex 行为优先参考 OpenAI 官方文档。