[Bug] ocx v2 status can report OFF/v1 while ~/.codex/config.toml forces multi_agent_v2=true #1337

Client or integration

Codex CLI / OpenCodex

Area

Multi-agent mode / status / doctor

Summary

ocx v2 status can report that V2 is disabled and multi_agent_mode: v1, while Codex still runs the V2 collaboration surface because ~/.codex/config.toml contains multi_agent_v2 = true.

This creates a misleading state where OpenCodex says all models are forced to v1, but routed subagents are actually spawned through the V2 worker path.

Observed symptom when using a native ChatGPT parent (gpt-5.6-sol) with a routed child (anthropic/claude-opus-5):

Routed V2 worker task is encrypted for the native ChatGPT backend and cannot be read by the selected provider. Use plaintext V2 agent-message delivery or select a native ChatGPT model.

code: unreadable_encrypted_agent_task

The root cause was eventually found in ~/.codex/config.toml: multi_agent_v2 = true was still set there. After removing/disabling that override, the OpenCodex-reported v1 state and the actual Codex runtime surface can agree.

Reproduction

1. Have ~/.codex/config.toml contain a V2 feature override such as:

[features]
multi_agent_v2 = true

2. Configure OpenCodex for v1:

ocx v2 mode v1

3. Check status:

ocx v2 status

Observed status:

multi_agent_v2: OFF — v1 multi-agent surface (default install)
multi_agent_mode: v1 — ALL models forced to v1 surface (upstream pins overridden)

4. Start a fresh Codex session with gpt-5.6-sol as the parent.
5. Use a custom agent whose TOML specifies a routed model, for example:

model = "anthropic/claude-opus-5"

6. Spawn that agent.

Actual result: the request goes through the V2 worker path and fails with unreadable_encrypted_agent_task.

Expected behavior

At minimum, ocx v2 status and/or ocx doctor should detect the conflicting Codex-side feature override and warn clearly that the effective runtime may still be V2.

Preferably one of the following:

• ocx v2 status reports the effective Codex feature override from ~/.codex/config.toml.
• ocx doctor flags a conflict when OpenCodex is configured for v1 but Codex has multi_agent_v2 = true.
• ocx v2 mode v1 removes or overrides the conflicting Codex-side setting, if that is safe and intended.

Impact

This is difficult to diagnose because users may repeatedly restart Codex, restart the OpenCodex service, resync the catalog, repair the service, or even reinstall OpenCodex while the real conflicting flag remains in ~/.codex/config.toml.

The status output currently strongly suggests that V2 is off even when runtime behavior proves otherwise.

Environment

• OpenCodex: reproduced around 2.10.1 / 2.11.0 while troubleshooting
• Codex CLI: 0.147.0
• OS: Ubuntu/Linux
• Parent model: gpt-5.6-sol
• Routed child model: anthropic/claude-opus-5

Checks

• Reproduced after fresh sessions and process restarts.
• Reproduced after OpenCodex service repair / catalog resync.
• Root cause isolated to the Codex-side multi_agent_v2 = true override.
• No secrets or credentials included.