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

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:

• #34833
• #33551
• #35932
• #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.

Start at the custom-agent spawn path and the dynamic delegation transport, focusing on the provider boundary described in the reproduction. Reproduce an OpenAI parent spawning an external Responses child with fork_turns = "none", then add an integration test that checks the unique delegation ID reaches the child or that the spawn fails clearly before starting it.