subagent-codex pins @openai/codex 0.153.4, so current models fail with model_not_found

[Venompool888]

Bilingual report — English first, 中文在下半部分。
双语报告 —— 上半部分英文，下半部分中文。

---

Symptom

With a ChatGPT (not API-key) login, every subagent_codex delegation opens fine but dies at the turn stage (product-error, no closing message). Running the payload the plugin ships reproduces it outside DSH entirely:

$ node ~/.dsh/profiles/desktop/node_modules/@openai/codex/bin/codex.js \
    exec --model gpt-6.1-sol --skip-git-repo-check "Reply with exactly: OK"
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error",
  "message":"The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.",
  "code":"model_not_found"}}

Root cause

@deepseek-ai/dsh-subagent-codex pins @openai/codex at 0.153.4 — both 0.2.1-rc.5 and the newer 0.2.2-alpha.2. That CLI's app-server serves a legacy model catalog, so the current models are rejected by the backend:

payload	model/list
0.153.4 (pinned)	gpt-6-astra, gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna
0.166.0 (current)	gpt-6.1-sol (default), gpt-6-astra, gpt-6.1-terra, gpt-6-sol, gpt-6-luna, gpt-5.6-*

Same account, same ~/.codex, same binary path — only the CLI version differs. With 0.166.0 a plain turn with gpt-6.1-sol returns normally.

Environment

• DSH 0.2.1-rc.5, @deepseek-ai/dsh-subagent-codex 0.2.1-rc.5 (0.2.2-alpha.2 has the same pin)
• macOS arm64; Codex login is a ChatGPT account; ~/.codex/config.toml sets model = "gpt-6.1-sol"
• Codex Desktop on the same machine runs 0.166.0-alpha.5.1 and uses gpt-6.1-sol without problems

Suggested fix

Bump the @openai/codex dependency to the current stable (0.166.0 as of this report) and re-verify the app-server handshake. The delegate path used by the provider (initialize → thread/start → turn/start) worked unchanged after swapping only the payload.

Workaround

An overrides entry for @openai/codex@0.153.4 in the desktop profile's pnpm-workspace.yaml, plus a local payload swap for existing installs. subagent_codex then works end to end, including tool calls inside the child workspace.

---

中文版

现象

用 ChatGPT 账号（不是 API key）登录时，每次 subagent_codex 委派都能连上，但在 turn 阶段失败（product-error，没有收尾消息）。用插件自带的那份 payload 在 DSH 之外就能复现同一个错误：

$ node ~/.dsh/profiles/desktop/node_modules/@openai/codex/bin/codex.js \
    exec --model gpt-6.1-sol --skip-git-repo-check "Reply with exactly: OK"
ERROR: {"type":"error","status":400,"error":{"type":"invalid_request_error",
  "message":"The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.",
  "code":"model_not_found"}}

根因

@deepseek-ai/dsh-subagent-codex 把 @openai/codex 钉死在 0.153.4——0.2.1-rc.5 和更新的 0.2.2-alpha.2 都是这个版本。该版本 CLI 的 app-server 提供的是旧的模型目录，导致当前这一代模型被后端拒绝：

payload 版本	model/list 返回
0.153.4（当前 pin）	gpt-6-astra、gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna
0.166.0（当前稳定版）	gpt-6.1-sol（默认）、gpt-6-astra、gpt-6.1-terra、gpt-6-sol、gpt-6-luna、gpt-5.6-*

同一个账号、同一份 ~/.codex、同一个二进制路径，只有 CLI 版本不同。换成 0.166.0 后，用 gpt-6.1-sol 跑普通 turn 能正常返回。

环境

• DSH 0.2.1-rc.5，@deepseek-ai/dsh-subagent-codex 0.2.1-rc.5（0.2.2-alpha.2 的 pin 相同）
• macOS arm64；Codex 登录的是 ChatGPT 账号；~/.codex/config.toml 里 model = "gpt-6.1-sol"
• 同一台机器上的 Codex 桌面端跑的是 0.166.0-alpha.5.1，用 gpt-6.1-sol 没有任何问题

建议修法

把 @openai/codex 依赖升到当前稳定版（写这份报告时是 0.166.0），再复验一次 app-server 握手。提供方用的委派链路（initialize → thread/start → turn/start）在只换 payload 的情况下没有改动就正常工作。

临时方案

在桌面 profile 的 pnpm-workspace.yaml 里给 @openai/codex@0.153.4 加一条 overrides；对已经装好的环境再本地替换一次 payload。这样 subagent_codex 就能端到端跑通，包括在子工作区里调用工具。

[PerryLink]

The pin is the same in every channel: 0.153.4.

packages/subagent/subagent-codex/package.json:51 is "@openai/codex": "0.153.4" at master ce7073d5, and the same line at dsh-v0.2.1-rc.5 (b830ec95) and dsh-v0.2.2-alpha.2 (f3803c96). So the desktop build, the released CLI, and the alpha all drive the same payload — a fix in any one channel has to bump this dependency.

What that means for your report: DSH does not choose a codex model itself; it spawns the package-local payload as app-server --stdio (packages/subagent/subagent-codex/src/run.ts:136, which is the fixed package-local bin, not whatever is on PATH) and asks it to run a turn, so the catalog the backend accepts is whatever that payload advertises. Your two-payload comparison is the cleanest possible evidence for that, and the 400 text (not supported when using Codex with a ChatGPT account) comes from the payload's own request, not from DSH.

I verified the pin only. I did not run either payload, so the model lists in your table are yours, not mine.

Workaround, in the shape this tree expects: the profile is a pnpm project with a flat node_modules (nodeLinker: hoisted, written into pnpm-workspace.yaml by packages/boot/app-boot/src/profile.ts:184-189). Add an override next to it and reinstall:

# ~/.dsh/profiles/desktop/pnpm-workspace.yaml
overrides:
  '@openai/codex': 0.166.0

dsh plugin --profile desktop install

pnpm ≥10 reads settings from pnpm-workspace.yaml; on an older pnpm the same override belongs under pnpm.overrides in the profile's package.json.

Fix shape for the tree: bump the dependency and add a check that the payload version is what the provider expects, so the next model-catalog change is a deliberate bump rather than a silent break.

If it still fails after the override, the useful next datum is which payload actually ran: node ~/.dsh/profiles/desktop/node_modules/@openai/codex/bin/codex.js --version and the full 400 body.