fix(auth): 将 Codex 启动器身份锚定到真实进程

[47seek]

普通 Codex 经过 shell / Node 启动器启动时，worker 会将启动器 PID 发布为当前回合的身份锚点。真正的 Codex 进程随后进入已有进程快照，工具调用被进程归属校验拒绝，botmux actor current --json 返回 current_actor_unverified。

在普通启动及 PID 延迟出现的路径中增加 Codex 专属的有界进程解析，将身份锚点更新到真实 CLI。解析同时绑定 backend、spawn generation、CLI lifetime 和启动器出生标识。原生 Codex 根进程保持自身锚点，已配置 runtime 使用对应可执行文件匹配规则。

验证：

• 新增真实 worker 的 PTY / tmux 回归，覆盖 shell → Node → Codex → 工具进程，以及失效 generation / 进程身份的拒绝；修改前两例失败，修改后 Node 与 Bun 均通过。
• 当前提交的 7 个相关测试文件共 141 项通过，涵盖 actor、IPC、进程归属及跨 CLI 进程查找。
• bun run build、bun run build:bun 和 git diff --check 通过。

真实进程回归在 Linux 执行；macOS 沿用现有进程探针，未执行设备端验证。生产部署后的真人新回合授权验证单独跟踪。

[deepcoldy]

感谢贡献！这个修复的方向和主链路都是对的：评审中核实了官方 npm 版 codex 的 bin/codex.js 确实以 spawn 方式拉起原生二进制（登录 shell → node 启动器 → 原生 codex，shell exec 后 PID 不变），把身份锚点重新发布到真实 CLI 进程后，current-actor 的进程归属校验即可正常通过；四重陈旧守卫（backend 实例 / spawn 代次 / lifetime / 启动器启动时钟）以及「启动器自身 comm 已是 codex 则首拍退出」的设计也都稳妥。新增的真实 worker 回归（pty/tmux）在修改前失败、修改后通过，相关邻居测试与构建也均通过。

以下是自动评审的初步意见，最终以维护者审阅为准，均不阻断合入：

1.（建议收口）找到真实 codex 后建议同步重锚 backend.cliPid。 目前轮询只重新发布了身份证明，没有像同文件的 startWrapperRealPidResolve / startTraexLauncherPidResolve 两个同类轮询那样把 backend.cliPid 一起指到真实进程。只发证明时，提交侧的 rollout 归属证明读到的仍是启动器 pid（src/adapters/cli/codex.ts 中 pty.cliPid → findCodexRolloutSetByPid），而 rollout 文件由真实 codex 持有，正向归属证明会恒为空——不影响消息提交（会走终端兜底），但这条证明链始终缺失。仿 traex 分支补上 backend.cliPid = realPid 即可。主修复（actor 身份校验）读的是 daemon 侧已发布的锚点，与此相互独立、本身完整有效。

2.（建议收口）陈旧守卫建议复用共享 helper 并补接线测试。 新轮询内联重写了 src/core/session-discovery.ts 中 launcherRetryStillValid 已有的守卫逻辑（该 helper 在 test/find-launched-cli-pid.test.ts 已有单测），而新增的 spawn 代次 / lifetime / 启动时钟条件目前没有测试可以覆盖：现有集成测试的两个负向用例校验的是 daemon 侧逻辑，实测把新守卫整体短路后两个用例仍全部通过。建议复用（或小幅扩展）launcherRetryStillValid 承载 backend 身份 + childPid 两维，代次 / lifetime / 启动时钟作为补充条件，并补一个 worker 内重启 / PID 复用场景的接线测试（旧轮询的 tick 不得再为新会话发布证明）。

3.（小）自定义 runtime 可执行文件名分支缺测试。 cliRuntime.source === 'configured' 的匹配路径没有覆盖，当前用例的 fake codex 不带 cliRuntime，建议补一例自定义可执行文件名的场景。

4.（小）轮询耗尽建议加日志。 30 次 / 约 6 秒解析失败时目前静默返回，线上排查无法区分「启动较慢」与「解析失败」，建议补一条日志。

另供维护者参考：#1745 也在调整同一函数内 wrapper codex 的 pid 解析（仅覆盖显式配置 wrapperCli 的场景，与本 PR 的无 wrapper 官方 npm 形态互补、行上不冲突）。两者都合入后 wrapper codex 会同时存在两个解析轮询；若本 PR 按第 1 点做成统一的完整重锚，两处可在合入窗口收敛为一套机制。

再次感谢，核心修复本身是完整且有效的。

[deepcoldy]

已合并，感谢贡献！

说明一下这次合入的形态：

1. 你 PR 所修复的问题（npm 版 Codex 经 shell / Node 启动器启动时，身份锚点停在启动器进程，导致工具调用的进程归属校验被拒绝、actor current 返回 unverified）在此期间已由主干上的另外两个提交完整修复并上线，且采用了评审中建议的收口形态：复用统一的启动器 PID 解析重试器、同步重锚真实 CLI 进程与身份证明、覆盖延迟出现 PID 的启动路径、透传自定义可执行文件匹配规则，并补齐了切片级单测。因此原 PR 的源码改动在最新主干上已是重复内容，未再合入。

2. 本 PR 最终落地的是你提交里主干唯一缺少的部分：真实 worker 的端到端回归（实际拉起 worker → shell → Node 启动器 → 原生 Codex → 工具进程，验证身份重锚与归属判定的完整链路，pty 与 tmux 各一例），并补充了自定义可执行文件（改名的 Codex 兼容运行时）场景两例。这条端到端链路是切片测试覆盖不到的，作为防止未来回归的护栏保留在主干上。

再次感谢这个修复——问题定位、进程链分析和回归测试都很扎实。

[github-actions]

🚀 Released in v3.41.0