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

[firewine]

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.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Wibias]

Resolved on current dev.

The effective Codex-side multi_agent_v2 state is now part of the actual mode transition rather than being allowed to drift independently from OpenCodex's multiAgentMode setting.

ocx v2 mode v1 now:

1. reads the active Codex config.toml;
2. performs the official codex features disable multi_agent_v2 transition when V2 is enabled;
3. re-reads the feature state after the command;
4. fails with codex feature command did not disable multi_agent_v2 if the flag is still enabled;
5. rolls back the original config bytes if the transition or its postconditions fail;
6. only then persists the OpenCodex multiAgentMode: "v1" state.

ocx v2 status likewise reads the actual Codex feature flag rather than inferring it from the OpenCodex mode override.

PR #1309 (b90b41ff) also hardened that read path by switching multi_agent_v2 detection to a real TOML parse. This covers the reported [features] multi_agent_v2 = true form as well as the dedicated-table and inline-table forms, including configurations containing multiline TOML values that previously confused the line scanner.

The reported state where ocx v2 mode v1 succeeds while an effective multi_agent_v2 = true silently remains active is therefore no longer permitted by the current transition contract.

Closing as completed.