Cross-provider child task is still replaced by a non-portable encrypted inter-agent message on 0.147.0 #38656

Environment

• Codex CLI: 0.147.0 (current npm latest at time of reproduction)
• Platform: Fedora Linux x86_64, kernel 7.1.8-200.fc44.x86_64
• Parent: OpenAI/ChatGPT-authenticated gpt-5.6-sol
• Child: an external OpenAI-compatible Responses provider using wire_api = "responses"
• codex doctor --json: overallStatus = "ok", config/auth/provider reachability all reported healthy

What issue are you seeing?

An external Responses provider works as a standalone top-level Codex profile, but cannot receive a task when used as a native child agent under an OpenAI parent.

The direct control request returned the expected canary (GROK_DIRECT_OK). When the same provider/model was used as a spawned custom agent, the child received this in place of the delegated task:

An encrypted inter-agent message occurred here but is not portable to the Grok Build account.

The child model itself could still respond, but it never received the real task payload, so the resulting answer was unrelated or unusable.

Steps to reproduce

1. Define a user-level external Responses provider:

[model_providers.external]
name = "External Responses Provider"
base_url = "https://example-compatible-provider.invalid/v1"
wire_api = "responses"

2. Confirm a top-level profile using that provider can answer a unique canary.
3. Define a custom agent that selects the same provider/model.
4. From an OpenAI-backed parent, spawn that custom agent with a unique delegation string and ask it to return only that string.
5. Observe that the child receives the non-portable encrypted-message placeholder instead of the delegation string.
6. Repeat with fork_turns = "none". The same failure occurs, which indicates the dynamic task assignment itself is provider-bound/encrypted; it is not caused only by inherited parent history.

Expected behavior

Before sending a child task to a different provider, Codex should serialize the dynamic delegation as a provider-neutral message that the selected child provider can consume.

If plaintext fallback is intentionally unsupported, Codex should detect the cross-provider boundary and fail the spawn clearly before starting the child, rather than starting an agent whose task payload is missing.

An integration test could assert that a unique delegation ID survives an OpenAI-parent to external-Responses-child spawn, including the fork_turns = "none" case.

Additional information

This is an independent reproduction/corroboration of the same underlying compatibility gap reported in:

• MultiAgentV2 cross-provider subagent cannot consume encrypted task assignment #34833
• Multi-Agent V2 sends OpenAI-specific agent_message items to external Responses providers #33551
• Custom-provider subagents lose dynamic task payload on stable v0.146.0 — supported behavior or bug? #35932
• Native subagent orchestration does not work correctly with non-OpenAI custom providers #17598

It also explains an earlier attempt with a DeepSeek-compatible child provider that appeared to run but could not correctly return the delegated task. The current controlled reproduction used a different external Responses provider, showing that the failure is not specific to DeepSeek or to one gateway.

The relevant custom-provider documentation says responses is the only supported wire_api, and custom agent files can override normal session configuration keys. That makes the provider boundary look supported at configuration time, while the inter-agent task transport remains provider-specific.