Codex subagent can fail when DSH’s bundled Codex is older than the user’s configured model

[xiki-tempula]

Summary

Codex receives frequent updates, including support for new models. This creates a compatibility problem when DSH bundles an older Codex version but reads the user’s current Codex configuration.

Example

I updated my terminal Codex to 0.162.0 and set gpt-6.1-sol as the default model in ~/.codex/config.toml. This works when I run codex directly.

However, DSH’s Codex subagent uses its own bundled Codex 0.147.0, rather than the updated executable on my PATH. It reads the same configuration and attempts to use gpt-6.1-sol through the older runtime.

How the mismatch happens

1. The user updates their terminal Codex and selects a newly supported model.
2. DSH’s bundled Codex remains on an older version.
3. Calling subagent_codex loads the user’s current configuration.
4. The older bundled runtime attempts to use the new model and fails.

Observed errors

The bundled version reported:

ERROR codex_models_manager::manager: failed to load models cache:
missing field `supports_parallel_tool_calls` at line 139 column 5

The model request also failed with:

The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.

Running the same minimal request through terminal Codex 0.162.0 succeeded, while bundled Codex 0.147.0 failed.

The DSH subagent then remained pending instead of returning the failure promptly.

Suggested improvements

Could DSH support one or more of the following?

• Use the installed Codex executable from PATH or a configurable executable path.
• Provide a supported way to update bundled Codex independently.
• Allow a separate model configuration for the Codex subagent.
• Detect incompatible configurations and return a clear error.
• Ensure failed subagent calls terminate cleanly and return their error to the parent agent.

[MalikAhed]

This looks like a runtime/configuration mismatch rather than a model-quality problem. The reliable short-term workaround is to make the subagent use a model supported by the bundled Codex version (0.147.0), or run DSH with an explicitly selected Codex executable/configuration if your build exposes that option. Do not let the subagent inherit a newer user config.toml while executing an older binary.

For a durable fix, DSH can resolve the executable first (configured path, then PATH, then bundled fallback), query the selected binary for its version/model list, and validate the configured model before starting the subagent. If the model is unsupported, return that error immediately instead of leaving the subagent pending. Pinning the bundled Codex and its model cache to the same release also avoids the supports_parallel_tool_calls schema mismatch; the cache should be regenerated or migrated when the bundled version changes.

A useful diagnostic to include in the report is the resolved executable path, codex --version, effective CODEX_HOME, and the model name after config resolution. That will prove whether DSH is reading the terminal installation or the bundled copy. If this answer matches the failure you are seeing, please click Mark as answer.

[r2Default-cloud]

Confirmed workaround on Windows — Sol 6.1 working through DSH Desktop

I encountered the same issue and found a working local workaround without upgrading DeepSeek Harness or replacing the entire plugin.

Environment

• DeepSeek Harness Desktop: 0.2.0-rc.2
• @deepseek-ai/dsh-subagent-codex: 0.2.0-rc.2
• Bundled @openai/codex: 0.153.4
• External Codex CLI: 0.162.0-alpha.17.2
• Model configured: gpt-6.1-sol, reasoning effort high
• Windows 10

Original issue

gpt-6.1-sol failed twice through the bundled Codex App Server with Product subagent failure (stage: turn, category: product-error).

The same delegation path worked with gpt-5.6-sol and gpt-6-astra.

Sol 6.1 worked directly through the newer Codex CLI and its App Server.

Workaround

I backed up the installed plugin's lib/index.js and changed only the codexAppServerArgv() function.

Original launch arguments:

[process.execPath, CODEX_PACKAGE_BIN, "app-server", "--stdio"]

Modified launch arguments:

[ABSOLUTE_PATH_TO_NEWER_CODEX_EXE, "app-server", "--stdio"]

I then restarted DeepSeek Harness Desktop.

No other plugin logic, registry configuration, or dependencies were changed. The original plugin version remains 0.2.0-rc.2.

Results

• Normal subagent_codex delegation completed successfully.
• The child returned the exact expected response.
• A separate file-reading test succeeded: the child returned a random nonce, the correct SHA-256 of the file bytes, and the correct line count.
• No retries, fallback providers, or interactive approvals were required.

Limitations

• This is an unofficial local workaround, not a fully validated compatibility upgrade.
• The executable path is hardcoded and may change after a Codex update.
• Reinstalling or updating the Harness plugin may overwrite the modification.
• Approval, cancellation, and error-handling compatibility have not been comprehensively tested.
• The configured model/effort were not independently verified from the delegated child's runtime telemetry.

Suggestion

It would be useful to support a configurable Codex executable path, with the bundled runtime as a fallback, plus version/model compatibility diagnostics.

This would allow users to adopt newer Codex models without manually patching the plugin.