PR #41 Codex Provider 审查报告

M1未知 turn 状态默认 completed protocol.ts:696-700

缺失 / inProgress / 未来新枚举一律报成功完成；配合 getRecord 对 malformed 数据返回 {} 的风格，一条垃圾 turn/completed 也会落库成 Completed。未知一律 → failed，绝不默认成功。

// protocol.ts:696 —— 状态映射的兜底方向反了
function mapTurnStatus(status) {
  if (status === 'failed') return 'failed'
  if (status === 'interrupted') return 'interrupted'
  return 'completed'   // ✗ undefined / 'inProgress' / 未来新枚举 → 全部报成功
}
// 叠加 getRecord(malformed) → {}:一条垃圾 turn/completed 通知 = 一条成功落库的 run

M2会话死亡时对挂起提问回「空答案」 protocol.ts:176-185 · index.ts:610-613

dispose/崩溃时回 {answers:{}}——工具看到的是“用户没答”，不是“会话死了”。Codex 此处确实无 cancel wire 等价物，那就别回成功响应，回 JSON-RPC error 让对端感知。

// dispose/进程死亡时,对挂起的 requestUserInput(cancellationResponseFor :180):
{ answers: {} }   // ✗ 语义 = 「用户提交了空答案」,不是「会话死了」
// 工具按「没答」继续走分支 → 每次崩溃都产生一次错误的 agent 行为;应回 JSON-RPC error

M3usage 只填 2/7 个字段 protocol.ts:313-327

契约 usage.updated 有 cacheReadTokens / cacheCreationTokens / contextTokens / contextWindow / model，全丢；且读 tokenUsage.last（单轮）非 total，累计语义没定义。声明了 token-usage 能力却是半实现。

M4串行队列 + 处理路径里 await sink.emit index.ts:228-233

通知与 provider 请求共用一条串行链，慢 sink（DB 写 + SSE 广播）会 head-of-line 阻塞后续全部 Codex 流量；runControl 还会 await 整条队列。把持久化挪出 dispatch 路径，或请求/通知分队列。

// index.ts:228-233 —— 通知与 provider 请求共用一条串行 promise 链
peer.onNotification((msg) => {
  this.notificationQueue = this.notificationQueue.then(() => this.handleNotificationSafely(msg))
})
// 而 handleNotification 里:
await this.sink.emit(event)   // ✗ DB 写 + SSE 广播挂在队头 → 后面所有 Codex 消息排队等它

M5AgentInput.parts 被静默丢弃 index.ts:621-623

契约写明 parts 存在时是 authoritative（types.ts:248-251）——图片轮次无声退化成派生文本。映射 parts → Codex input items（text/image），不支持的 part 显式 throw。

// 契约(types.ts:248):parts 存在时 authoritative,text 只是派生兜底
type AgentInput = { text: string; parts?: AgentInputPart[] }   // part: text | image

// index.ts:621 现状:
private turnInputItem(input: AgentInput) {
  return { type: 'text', text: input.text, text_elements: [] }  // ✗ 只读 text → 图片 part 无声蒸发
}

M6providerTurnId 提取了却不上报 protocol.ts:194-213

契约 run.started 带 providerTurnId?，代码提取 turn.id 只做非空校验就丢了 → agent_runs.providerTurnId 永远 null。PR body 宣称的 “routes events through Codex provider turn IDs” 在 diff 里不存在。把 turnId 放上事件。

// protocol.ts:194 turnStartedToEvent —— turn.id 提取出来只做了非空校验
const turnId = getString(turn.id)
if (!threadId || !turnId) return { kind: 'none' }
return { kind: 'event', event: {
  type: 'run.started',
  providerSessionId: threadId,
  // ✗ providerTurnId 没放上事件(契约里有这个可选字段)→ agent_runs.providerTurnId 永远 null
  raw,
} }

M7能力声明与事件产出不对账 index.ts:145-147

发着 diff.updated（in-UI diff review 是 Eyrie 的招牌特性，这条事件直接喂它）却不声明 structured-diff → UI 按能力门控就永远看不到你产出的 diff；反之 token-usage 声明了却是 M3 的半残。规则：声明的必须做全，做全的必须声明。

M8reasoning 流永不收口 protocol.ts:96-98 · 380-419

reasoning delta 正常流出，但 item 完成被忽略 → 消费者的思考块永远等不到终结信号。至少按 itemId 配对发一条 completed（message.completed 无 role 是契约缺口，会另行处理；itemId 配对你这边就能做）。

M9配置面与声明 schema 脱节 + 会话级任意可执行文件隐患 index.ts:37-59 · 639-655

adapter 私收 10 个旋钮但 sessionConfig 声明为空；service 校验拒绝一切未声明 key → createSession 落地之日所有旋钮会话级不可达。更要紧：mergeRunnerConfig 允许 session config 覆盖 command/args/env——session config 一旦对用户开放，等于会话级注入任意可执行文件。

// index.ts:639 mergeRunnerConfig —— session config 盖在 provider row 配置之上
providerConfig: {
  ...baseConfig,      // provider row(管理员面):command / args / env / ...
  ...sessionConfig,   // ✗ 会话配置同 key 直接覆盖 —— 包括 command/args/env
}
// 同时 getSessionConfig() 返回 [] → service 校验拒绝一切 key:
// 旋钮今天「不可达」,明天 schema 一补就变「会话级换可执行文件」—— 必须按 key 分级

• command / args / env / codexHome → 钉死 provider row 级（不读 session blob）
• model / approvalPolicy / sandbox / requestTimeoutMs → 会话级候选，且要在 ProviderModule.sessionConfig 里如实声明
• agent-registry.test.ts 里直写 repo 绕过校验的用例一并改掉