39 lines
5.0 KiB
Markdown
39 lines
5.0 KiB
Markdown
# cc-web Codex hooks 验证进度
|
||
|
||
## Log
|
||
|
||
- 2026-06-30T00:00:00+08:00 使用 `planning-with-files` 建立本次验证计划。
|
||
- 2026-06-30T00:00:00+08:00 确认根目录此前没有 `task_plan.md`、`findings.md`、`progress.md`；工作区存在用户已有未提交改动，主线程不会触碰。
|
||
- 2026-06-30T00:00:00+08:00 先创建 4 个背景子线程：官方文档、cc-web 链路、hapi 对齐、本地 hooks 条件。
|
||
- 2026-06-30T00:00:00+08:00 根据用户纠正，收敛到 6 个精准断点，并分别创建子线程验证。
|
||
- 2026-06-30T00:00:00+08:00 官方文档背景线程已返回：确认 hooks 属于官方 config layer 发现机制，未确认 `thread/start.config.hooks.*` 是稳定注入路径。
|
||
- 2026-06-30T00:00:00+08:00 断点 1、2、3、5 已有子线程/主线程证据：当前通或未关闭；断点 4、6 仍是关键未闭环点。
|
||
- 2026-06-30T00:00:00+08:00 断点 4 已返回直接证据：app-server `hooks/list` 显示项目 7 条 command hook 全部 untrusted。marker 验证不再是定位根因的必要步骤。
|
||
- 2026-06-30T00:00:00+08:00 cc-web 接入链路线程已纳入：local 模式不阻断 hooks；custom 模式存在 CODEX_HOME 隔离风险；当前缺少 hooks/trust 诊断入口。
|
||
- 2026-06-30T00:00:00+08:00 hapi 对齐线程已纳入：hapi app-server 路径没用 hooks 注入，支持“不走 thread/start.config.hooks.*”；但不能否定 Codex 原生 hooks/list/trust 机制。
|
||
- 2026-06-30T00:00:00+08:00 本地 planning-with-files 条件线程已纳入：脚本和 active-plan 检测本身可用；当前阻断点仍是 command hook untrusted。
|
||
- 2026-06-30T00:00:00+08:00 断点 3 返回后完成总线收敛：项目根 `/home/cc-web` 已 trusted，但这不等于 `.codex/hooks.json` 里的每条 command hook 已通过 hash trust。最终结论锁定为 command hook trust 阻断。
|
||
- 2026-06-30T00:00:00+08:00 断点 4 正式返回并确认：app-server 只读 `hooks/list` 对当前 `/home/cc-web/.codex/hooks.json` 返回 7 条 command hook，全部 `enabled=true`、`source=project`、`trustStatus=untrusted`。这是本轮最直接根因证据。
|
||
- 2026-06-30T00:00:00+08:00 断点 5 正式返回并确认：用户级 `[features]` 未设置 `hooks=false`，项目 `.codex/config.toml` 无 `[features]`，cc-web thread config/app-server 参数/环境变量均未发现关闭 hooks 的配置。hooks feature 开关不是阻断点。
|
||
- 2026-06-30T00:00:00+08:00 断点 6 隔离 marker 验证返回：临时 app-server 能通过 `hooks/list` 发现 `/tmp` 项目 hook，状态为 `enabled=true/source=project/trustStatus=untrusted`；`turn/start` 可触发但 marker 不出现、无 hook started/completed 通知。结论是“加载但未 trust”，不是“未加载 hooks”。
|
||
- 2026-06-30T00:00:00+08:00 修复入口核验：本机 Codex CLI 0.140.0 帮助中没有公开 `hooks trust` 子命令，只有 `--dangerously-bypass-hook-trust`；app-server schema 暴露 `hooks/list` 和 `HookTrustStatus`，未发现公开 `hooks/trust` 请求。产品修复第一阶段应先做诊断/引导，不直接发明 trust 写入。
|
||
- 2026-06-30T00:00:00+08:00 用户执行 Codex hook review 后复核：`/home/hdzx/.codex/config.toml` 新增 `[hooks.state]` 下 7 条 `/home/cc-web/.codex/hooks.json:<event>:0:0` 的 `trusted_hash`；按 schema 用 `hooks/list { cwds: ["/home/cc-web"] }` 复查，7 条 project hooks 均返回 `trustStatus=trusted`。
|
||
|
||
## 2026-08-23 CentOS 7 重新打包会话
|
||
|
||
- 已按 `cc-web-centos7-release` 技能开始复核。
|
||
- 已确认现有归档时间为 2026-08-21 16:57，源码在该时间点前后有更新，用户启动旧版的判断有事实依据。
|
||
- 已定位多个可复用的 baseline Bun，下一步将校验其版本/目标后执行 `BUN_BIN=... npm run build:single-exe`。
|
||
- 已使用 `/tmp/ccweb-bun.vyBprA/node_modules/@oven/bun-linux-x64-baseline/bin/bun`（1.3.14）成功重建 `dist-exe/bun-linux-x64-baseline/` 与 `dist-exe/cc-web-bun-linux-x64-baseline.tar.gz`。
|
||
- 已验证目录二进制与 tar.gz 内二进制 SHA-256 一致；已从发布目录直接启动并用 HTTP、启动日志、进程可执行文件路径完成本机等价验收。
|
||
- 已清理临时 `CentOS7重新打包 TO DO list.csv`；目标机部署仍需将新归档解压到目标目录并停止旧进程后启动新目录二进制。
|
||
- 发布技能规定的 `node --check` 六项检查、发布二进制 MCP `initialize` smoke 和 tar 清单检查均通过。
|
||
- 当前工作区仅发布归档、规划发现与进度日志有变更；未修改业务源码或构建脚本。
|
||
|
||
## 2026-08-23 start.sh 启动回退修复
|
||
|
||
- 保留原有 Node/PM2 为默认启动方式；新增启动前端口清理，默认处理 8002。
|
||
- 新增 CentOS 7 自动回退：源码启动失败时自动校验/刷新 `dist-exe` baseline 单文件并用 nohup 启动。
|
||
- 回退通过 `CC_WEB_APP_DIR` 复用现有 `config/auth.json`，未要求重新配置 `CC_WEB_PASSWORD`。
|
||
- 已完成 shell 语法检查、源码 PM2 启动回归、single-exe auth 回归和占用端口清理回归。
|