›_ Codex Issues
Codex Issues / #35932

Custom-provider subagents lose dynamic task payload on stable v0.146.0 — supported behavior or bug?

Open 💬 4 comments Opened Jul 29, 2026 by ZhongXinlin
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On the current stable standalone CLI, a native subagent configured with a non-OpenAI custom provider is created, but does not receive the dynamic task payload supplied to spawn_agent. The same payload is delivered correctly to a default same-provider control child, and the custom provider's direct Responses API is healthy.

This may be a bug in the custom-provider native-subagent path, or an intentional unsupported design that needs an explicit error and documentation. Either way, the present behavior is silent task loss.

Related: #17598. I am filing this separately because the failure is confirmed on the released stable CLI and because the capability contract is still ambiguous.

Environment

  • macOS
  • Standalone codex-cli 0.146.0 (@openai/codex@0.146.0; npm latest tag)
  • Parent model/provider: OpenAI gpt-5.6-sol
  • Child profile: MiniMax-M3 through a non-OpenAI custom provider
  • Provider transport: wire_api = "responses"
  • Native multi-agent feature enabled

Sanitized provider configuration:

[model_providers.minimax]
name = "MiniMax"
base_url = "https://api.minimax.io/v1"
wire_api = "responses"

[model_providers.minimax.auth]
command = "<redacted command-backed token helper>"

Minimal reproduction

From a fresh codex-cli 0.146.0 session, ask the OpenAI parent to make exactly one native spawn_agent call:

task_name = "stable_minimax_probe"
agent_type = "minimax-worker"
fork_turns = "none"

Delegation-ID: stable-minimax-payload-20260729-A

Need: Sort these inline words alphabetically and return the count: juniper, amber, cobalt, dune.

Boundaries: Do not call tools. Do not read or write files. Do not spawn agents.

Deliverable: Return only the Delegation-ID, sorted comma-separated list, and count.

The custom child profile is configured to fail closed when it does not receive a complete envelope, so the expected first response must include the exact Delegation-ID.

Observed

The stable CLI parent completed its native spawn_agent call. The custom-provider child returned exactly:

TASK_PAYLOAD_MISSING

The parent rollout records the complete delegation message and a spawn_agent function call. Therefore, the message was accepted by the parent, but did not reach the child as usable task context.

A single followup_task attempt in the desktop-app path also produced unrelated text rather than the supplied Delegation-ID or task result.

Controls

  1. A direct stateless POST /v1/responses request to the same MiniMax provider/model returned an exact unique canary marker.
  2. A fresh default same-provider native child received an equivalent inline sorting task and returned the correct sorted list and count.
  3. The failure reproduced after installing the released stable 0.146.0, not only in the prior bundled alpha CLI (0.146.0-alpha.3.1).

These controls suggest that the failure is specific to Codex's native custom-provider child handoff, not provider reachability, authentication, or the MiniMax model itself.

Expected behavior / clarification requested

Please clarify one of these contracts:

  1. Supported: non-OpenAI custom providers can run native subagents. In that case, the full dynamic spawn_agent.message and followup_task.message must reach the child.
  2. Unsupported by design: Codex should reject the spawn with a clear, documented error before creating a child, rather than silently creating a child with no task payload.

Debug suggestions

Could maintainers compare the default-child and custom-provider-child paths at these boundaries?

  • Serialize and log the sanitized child bootstrap payload immediately before and after the provider-specific request builder. Confirm preservation of the dynamic message, developer instructions, and child/thread identifiers.
  • Trace spawn_agent.message and followup_task.message through the Responses-compatible custom-provider adapter. A field may be omitted, transformed, or attached only to the OpenAI route.
  • Verify that fork_turns = "none" still injects the explicit task envelope for custom providers; no inherited parent context should be required for this case.
  • Add an integration regression test with a fake non-OpenAI Responses provider that records the child request and returns the received Delegation-ID. Cover both initial spawn and follow-up delivery.
  • If the adapter cannot safely provide this capability, fail before child creation with a capability-specific error and document the restriction.

I can provide sanitized rollout timestamps and additional control outputs if they would help.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34833

Powered by Codex Action

ZhongXinlin · 1 month ago

Additional compatibility / isolation results

I ran a more complete matrix after filing this issue. The result is that the MiniMax provider itself is usable, but the failure remains specific to Codex native custom-provider child handoff.

Controls that succeed

  1. A direct stateless POST /v1/responses request to MiniMax-M3 returned an exact unique canary.
  2. A direct stateless POST /v1/chat/completions request also returned its exact canary (included only as provider health context; my Codex custom-provider config uses wire_api = "responses").
  3. The released standalone codex-cli 0.146.0, launched as a top-level MiniMax-M3 session, returned an exact canary.
  4. An equivalent explicit task sent through an independent OpenClaw Gateway MiniMax-M3 worker returned exactly RECEIVED:<nonce>.
  5. A default OpenAI native child received and completed an equivalent inline task.

Native custom-child failures

Each test below used a fresh child, fork_turns = "none", a unique four-field envelope (Delegation-ID, Need, Boundaries, Deliverable), and no tools/files:

  • MiniMax-M3 native child: exactly TASK_PAYLOAD_MISSING
  • MiniMax-M2.7-highspeed native child: exactly TASK_PAYLOAD_MISSING

I also reran the M3 control from the standalone stable CLI after explicitly removing the inherited desktop-session variables CODEX_CI, CODEX_INTERNAL_ORIGINATOR_OVERRIDE, CODEX_SHELL, and CODEX_THREAD_ID. It still completed the parent spawn_agent call and the custom child still returned exactly TASK_PAYLOAD_MISSING.

This makes a desktop-session environment injection or an OpenClaw runtime interception unlikely. The only local OpenClaw coupling in the Codex provider config is a command-backed token helper; it can affect authentication, but not task text. The provider-health controls above also passed.

Separate model-discovery mismatch

While top-level MiniMax-M3 execution succeeds, Codex 0.146.0 logs a model-discovery error and falls back to metadata:

failed to decode models response: missing field `models`

The provider's /v1/models response has the normal OpenAI list shape:

{"object":"list","data":[...]}

Could maintainers clarify whether Codex custom-provider model discovery intentionally expects a different schema, and whether model_catalog_json should fully suppress this refresh path? This metadata problem may be separate from the child-payload loss, but it is another compatibility mismatch on the same route.

Request

The evidence now points away from provider reachability/authentication and toward the native child bootstrap / dynamic-message path. A high-value regression test would use a fake non-OpenAI Responses provider to assert that both the initial child request and a follow-up contain the exact unique Delegation-ID. If custom providers are intentionally unsupported as native children, please reject the spawn explicitly instead of creating a child that silently lacks its assigned task.

daimon-netizen · 29 days ago

I can still reproduce the native cross-provider child failure described here: a custom-provider child may start without receiving a usable task payload.

I published a user-space workaround that isolates this failure boundary:

  • a dependency-free local STDIO MCP dispatcher launches the worker as an independent top-level codex exec process;
  • the root agent sends a four-field task envelope (task_id, objective, deliverables, constraints);
  • lifecycle operations use stable job_id handles: start, status, bounded wait, follow-up, cancel, and close;
  • a per-turn receipt nonce is verified before a result is accepted;
  • the public test suite covers 16 dispatcher cases, and clean canaries succeeded with both MiniMax M3 and MiniMax M2.7 fast profiles.

Repository and experimental release: https://github.com/daimon-netizen/custom-provider-orchestrator

This is intentionally not presented as a native transport fix. It moves custom-provider workers outside the native child path, so the upstream payload-loss bug remains relevant.

CCanxue · 25 days ago

This is a bug, not supported behavior, for non-OpenAI providers on stable 0.146.0. Same root cause as #36586: the V2 task payload is delivered in encrypted_content inside an OpenAI-specific agent_message item, which DeepSeek's Responses implementation does not consume. The child therefore loses the dynamic payload while the envelope text stays visible.

Workaround that we verified end-to-end (spawn -> PONG, followup -> PONG2): a local patch delivering V2 tasks as plain user input for non-OpenAI providers. Patch and details: https://github.com/CCanxue/codex-deepseek-subagent-fix