Problem
idd-verify 的 Codex reviewer 目前用 codex exec --full-auto subprocess 呼叫 Codex CLI:
codex exec --full-auto -c 'model="gpt-5.5"' -c 'model_reasoning_effort="xhigh"' \
-c 'service_tier="fast"' -o /tmp/codex-verify-$NUMBER.md "..."
姊妹 plugin parallel-ai-agents(v2.4.0+)已經把同樣的 codex 呼叫從 subprocess 改寫成直接 HTTP wrapper bin/codex-call,理由是 codex exec subprocess 偶爾會 hang(stdin/stdout pipe 互鎖、tty 問題),要等到 timeout 才能繼續。
Type
refactor
現狀 vs 目標
| 面向 |
codex exec(idd-verify 現用) |
codex-call(parallel-ai-agents 已用) |
| 執行模型 |
Spawn codex CLI subprocess,stdin/stdout pipe 通訊 |
Direct HTTPS POST 到 chatgpt.com/backend-api/codex/responses |
| Hang 風險 |
⚠ pipe 互鎖 / tty 問題偶發 hang,等 10min timeout |
無 subprocess → 無 pipe 問題 |
--max-time 硬性保證 |
❌ CLI 不一定守 |
✅ HTTP timeout 強制 |
| OAuth token refresh race |
CLI 無 file lock,ensemble 平行 spawn 會 race |
wrapper 有 ~/.codex/.token-refresh.lock |
| 產物 |
-o <path> |
--output <path> |
Expected
idd-verify 的 Step 2b Codex invocation 改用 codex-call:
- 把
bin/codex-call(Swift script)從 parallel-ai-agents 引入(copy / symlink / 共用安裝)
- 改
idd-verify/SKILL.md 的 codex invocation block:codex exec ... → codex-call --output ... --model gpt-5.5 --effort xhigh --service-tier fast --max-time 600
- OAuth 共用
~/.codex/auth.json(兩個 wrapper 同一份 token store)
Actual
idd-verify 仍用 codex exec subprocess。實測中(2026-05-22 一次 /idd-verify #31 run)Codex 那次沒 hang,但 subprocess 模型的 hang 是已知偶發風險,parallel-ai-agents 就是為此重寫的。
Impact
- 影響檔案:
plugins/issue-driven-dev/skills/idd-verify/SKILL.md(codex invocation block)+ 可能需要引入 bin/codex-call
- 影響使用者流程:
/idd-verify 的 6-AI ensemble 第 6 個 reviewer(Codex)更穩定,不會偶發卡 10 分鐘
- 跨 plugin 協調:
codex-call 的 source-of-truth 在 parallel-ai-agents,要決定 idd-verify 是 copy 一份、symlink、還是抽成共用 dependency
- Priority: P3 — 現狀能跑,只是偶發 hang 風險;有空再做
Open questions
codex-call 要不要抽成獨立可共用的東西(避免兩個 plugin 各維護一份 Swift script)?
- idd-verify 是否也想要 parallel-ai-agents 的 file-lock OAuth refresh(ensemble 平行跑多個 codex 時才有意義 — idd-verify 一次只跑 1 個 codex,race 風險較低)?
Source: surfaced during /idd-issue kiki830621/che-cheng-website#27 linked-context sister sweep (Step 4.7) — orphan mention from a 2026-05-22 Claude Code session discussing how parallel-ai-agents invokes Codex.
Problem
idd-verify的 Codex reviewer 目前用codex exec --full-autosubprocess 呼叫 Codex CLI:姊妹 plugin
parallel-ai-agents(v2.4.0+)已經把同樣的 codex 呼叫從 subprocess 改寫成直接 HTTP wrapperbin/codex-call,理由是codex execsubprocess 偶爾會 hang(stdin/stdout pipe 互鎖、tty 問題),要等到 timeout 才能繼續。Type
refactor
現狀 vs 目標
codex exec(idd-verify 現用)codex-call(parallel-ai-agents 已用)codexCLI subprocess,stdin/stdout pipe 通訊chatgpt.com/backend-api/codex/responses--max-time硬性保證~/.codex/.token-refresh.lock-o <path>--output <path>Expected
idd-verify的 Step 2b Codex invocation 改用codex-call:bin/codex-call(Swift script)從 parallel-ai-agents 引入(copy / symlink / 共用安裝)idd-verify/SKILL.md的 codex invocation block:codex exec ...→codex-call --output ... --model gpt-5.5 --effort xhigh --service-tier fast --max-time 600~/.codex/auth.json(兩個 wrapper 同一份 token store)Actual
idd-verify仍用codex execsubprocess。實測中(2026-05-22 一次/idd-verify #31run)Codex 那次沒 hang,但 subprocess 模型的 hang 是已知偶發風險,parallel-ai-agents 就是為此重寫的。Impact
plugins/issue-driven-dev/skills/idd-verify/SKILL.md(codex invocation block)+ 可能需要引入bin/codex-call/idd-verify的 6-AI ensemble 第 6 個 reviewer(Codex)更穩定,不會偶發卡 10 分鐘codex-call的 source-of-truth 在parallel-ai-agents,要決定 idd-verify 是 copy 一份、symlink、還是抽成共用 dependencyOpen questions
codex-call要不要抽成獨立可共用的東西(避免兩個 plugin 各維護一份 Swift script)?Source: surfaced during /idd-issue kiki830621/che-cheng-website#27 linked-context sister sweep (Step 4.7) — orphan mention from a 2026-05-22 Claude Code session discussing how parallel-ai-agents invokes Codex.