[Bug] subagent_codex fails on any model newer than the pinned Codex CLI (0.153.4)

[yzxzyz]

subagent_codex fails on any model newer than the pinned Codex CLI

Package: @deepseek-ai/dsh-subagent-codex@0.2.1-rc.1
DSH: 0.2.1-rc.1 (macOS 26 arm64)
Codex desktop on the same machine: 0.163.0-alpha.10.2

Symptom

Calling the subagent_codex tool always fails, with no actionable detail:

Product subagent failure (product: Codex; stage: turn; category: product-error)

The underlying cause only shows up when you run the plugin's own Codex binary by hand:

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."}}

Root cause

The plugin hard-pins "@openai/codex": "0.153.4" and resolves the binary from its own
module scope:

const codexPackageJsonPath = createRequire(import.meta.url).resolve("@openai/codex/package.json");
const codexPackageManifest = JSON.parse(readFileSync(codexPackageJsonPath, "utf8"));
const CODEX_PACKAGE_BIN = resolve(dirname(codexPackageJsonPath), codexPackageManifest.bin.codex);

There is no config or environment option to point it at another binary, so it always uses
the pinned version — not the Codex CLI the user actually has installed.

When the plugin config does not set model, the child Codex falls back to
~/.codex/config.toml, i.e. whatever model the user's desktop Codex is on. On current
builds that is a slug the pinned 0.153.4 does not know, so every turn fails at the server
with a 400. The user sees only product-error, which sends them looking at auth and network.

Reproduction

# with model = "gpt-6.1-sol" in ~/.codex/config.toml
~/.dsh/profiles/desktop/node_modules/.bin/codex exec --skip-git-repo-check \
  --sandbox read-only "say ok"
# -> 400 invalid_request_error: model is not supported when using Codex with a ChatGPT account

# same command, codex 0.163.0 -> works
# same command, 0.153.4 with -m gpt-5.6-sol -> works

Suggested fixes

1. Bump the dependency to a Codex version that tracks the model list the desktop build uses
   (0.163.x at the time of writing), or resolve the user's installed Codex instead of pinning.
2. If the pin must stay, pass a supported model explicitly by default instead of inheriting an
   arbitrary config.toml model.
3. Surface the child's stderr in the tool error. stage: turn / category: product-error hides a
   perfectly clear 400 that names both the model and the cause.

Workaround

Add a pnpm override in the profile and point the plugin at a model the old CLI supports:

overrides:
  '@openai/codex': 0.163.0

- id: subagent-codex
  name: "@deepseek-ai/dsh-subagent-codex"
  config:
    model: gpt-5.6-sol   # only needed when staying on 0.153.4

The second form alone survives upgrades, but costs an older model; the override keeps model
parity and can be clobbered by a reinstall.

Still present on main

Checked main (0.2.1-rc.2): packages/subagent/subagent-codex/package.json still pins "@openai/codex": "0.153.4".

[yzxzyz]

Addendum from the reporter, in case it saves a round trip:

I have a working local override (pnpm overrides: { "@openai/codex": "0.163.0" } in the profile, model inherited from ~/.codex/config.toml) and one end-to-end subagent_codex run verified after it, with gpt-6.1-sol.

Happy to send a PR with the package.json + lockfile bump if that's useful — just say which version you want to track. I only verified the app-server methods this plugin actually uses (initialize, thread/start, turn/start, turn/completed, turn/interrupt) exist in 0.163.0 and one one-shot run; I have not done broader compatibility testing.

[PerryLink]

Confirmed on 687f282e86 (0.2.1-rc.2), and your read of the resolution path is exact.

The pin

packages/subagent/subagent-codex/package.json:51:

"@openai/codex": "0.153.4"

Exact, no caret, no range — so it can never float.

Why no config or env can point it elsewhere

packages/subagent/subagent-codex/src/run.ts resolves the binary at module scope:

const codexPackageJsonPath = createRequire(import.meta.url).resolve('@openai/codex/package.json')  // :44
const codexPackageManifest = JSON.parse(readFileSync(codexPackageJsonPath, 'utf8')) as CodexPackageManifest
const CODEX_PACKAGE_BIN = resolve(dirname(codexPackageJsonPath), codexPackageManifest.bin.codex)   // :50-53
...
return [process.execPath, CODEX_PACKAGE_BIN, 'app-server', '--stdio']                              // :136

Both are const evaluated on import, module-relative via createRequire(import.meta.url). That is why "there is no config option" is not an oversight in the schema — there is nowhere to put one: even if a binaryPath field existed, it could not change a value already computed when the module loaded. Any fix has to move the resolution to a lazy point inside the call, and only then does a config field become meaningful.

That distinction matters for the patch you offered: a package.json + lockfile bump will work, but it is the fragile shape — the next Codex model release re-breaks it the same way. Making the binary path overridable (config, then env, then the pinned package) fixes the class.

On the failure message

The Product subagent failure (product: Codex; stage: turn; category: product-error) line is what the harness produces when the child exits non-zero. The status/body you extracted by hand is the only place the real cause appears. Carrying the child's stderr tail into that diagnostic would have turned a day of guessing into one line — worth raising separately as a diagnosability gap, since it applies to every subagent provider, not just this one.

One correction to a detail in your report

0.153.4 is not a "minimum" being enforced — it is a hard eq pin. If the intent were to track the newest compatible CLI, the dependency would be ^0.153.4; the eq pin looks like a deliberate "known-good, verified against this app-server protocol" decision. That changes the maintainers' likely answer: they will probably want a bump, not a range, because the app-server surface this plugin uses is exactly what a newer CLI can move. Your verified-methods list is therefore the useful part of the report — it is the evidence a bump needs.

[xiaopengli2003]

Adding an independent reproduction plus a verified fix, in case it helps move this forward. Environment differs slightly from the report: macOS 27.0.1 arm64, DSH Desktop 0.2.1-rc.2, plugin @deepseek-ai/dsh-subagent-codex 0.2.1-rc.2, ChatGPT Plus account, model = "gpt-6.1-sol" in ~/.codex/config.toml.

Reproduction

subagent_codex fails as described with stage: turn / category: product-error. Running the plugin's own binary by hand exposes the cause:

$ <plugin>/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/bin/codex \
    exec --skip-git-repo-check -m gpt-6.1-sol -s read-only "Reply with exactly: ok"

model: gpt-6.1-sol
warning: Model metadata for `gpt-6.1-sol` not found. Defaulting to fallback metadata; ...
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."}}

Verified fix: swapping the vendored binary is enough

I replaced only the platform package's vendored binary directory (vendor/aarch64-apple-darwin/, 0.153.4 → 0.163.0, old one kept as a backup). package.json, plugin code, and ~/.codex/config.toml were left untouched.

Check	Result
Text delegation via subagent_codex	✅ normal answer, no product-error
Shell tool call inside the delegation	✅ returned dsh-codex-tool-ok
Installed binary version	✅ codex-cli 0.163.0

So in addition to initialize / thread/start / turn/start, the tool-call path also works against 0.163.0 — one more data point for the compatibility question raised above.

Control group on the same account and config: 0.153.4 + gpt-6-astra works; 0.153.4 + gpt-6.1-sol returns the 400 above. The only variable is the client version.

Suggestion

Pinning to 0.163.x (or a matrix-driven update mechanism rather than an exact pin) looks sufficient for this path, and the PR offer above seems worth taking. The Windows workaround in #9346 (patching codexAppServerArgv() to use an external CLI) is a reasonable stopgap. The "no actionable diagnostic" aspect is separately tracked in #9640.

[yzxzyz]

Two things from the original reporter, both cheap to add to the record.

1. A clean-room control, in case anyone still suspects a local config problem

I re-ran the comparison with an isolated CODEX_HOME and a config.toml containing exactly one line, so nothing from DSH, no profile patch, no override, and no user settings were in play (only the auth file was borrowed):

Setup	Result
0.153.4 + gpt-6.1-sol from config	400, model is not supported when using Codex with a ChatGPT account
0.153.4 + -m gpt-5.6-sol	normal reply
0.163.0 + gpt-6.1-sol from config	normal reply

The middle row is the one that isolates the variable: same binary, same auth, same account, only the slug changes. So this is not a broken dotfile, not auth, not network — it is purely client version vs. model catalog, which matches @xiaopengli2003's control group.

2. rc.1 → rc.2 upgrade behaviour, since that was an open question

I kept the pnpm override through the 0.2.1-rc.1 → 0.2.1-rc.2 upgrade to see what the updater does to it:

• rc.2's package.json:51 still pins "@openai/codex": "0.153.4", as @PerryLink confirmed.
• The updater rewrote pnpm-workspace.yaml (minimumReleaseAgeExclude gained the rc.2 entries) but kept the overrides block and its comments — it merged rather than regenerated. Same after two restarts.
• subagent_codex regression after the upgrade: passes, inheriting gpt-6.1-sol from config.toml.
• I keep a small check-mode script that compares installed version against the override and exits non-zero if they drift, so a future silent clobber shows up as one command rather than another debugging session.

A caveat on the vendored-binary swap

Replacing vendor/aarch64-apple-darwin/ works, but it leaves package.json (and the lockfile) still declaring 0.153.4 while the running binary is 0.163.0, and one pnpm install restores it. The pnpm overrides route costs one entry more and keeps declared and actual versions consistent, which matters if anyone later quotes the manifest to diagnose something else. Worth noting for whoever picks a stopgap.

I agree with @PerryLink that the class-level fix is lazy, overridable resolution (config → env → pinned package), and that a bump alone re-breaks on the next model release. Happy to send the package.json + lockfile bump if it helps in the meantime — just name the version to track.