Codex DeepSeek Subagent Gets No Task? Restore Plain Delivery

If a Codex subagent running DeepSeek starts successfully but answers "I don't see a task" or asks what it should work on, stop retrying the prompt. The current official DeepSeek catalog marks its models for Codex Multi-Agent V2, which sends the task inside an agent_message with an encrypted_content block. DeepSeek's Responses-compatible endpoint can ignore that item, so the child receives the task header with an empty payload.

The safest configuration bridge is to back up models.json, set the DeepSeek entries to Multi-Agent V1, set supports_search_tool to false, restart Codex completely, and prove delivery with a one-word canary. The upstream reports validate these two changes separately, so treat the combination as a temporary compatibility bridge rather than an official fix.

Confirm This Exact Failure Before Editing Anything

This article applies when all of the following are true:

• the parent is using a non-OpenAI custom provider such as deepseek-v4-flash or deepseek-v4-pro;

• the provider uses wire_api = "responses";

• a child thread is created, but it replies with a greeting, workspace summary, or "no new task input";

• sending the task again with followup_task produces the same result; and

• a native OpenAI model receives the same subagent task correctly.

The August 2 upstream reproduction used Codex CLI 0.145.0 on Windows. Independent comments reproduced it on Codex CLI 0.146.0, Windows 11, and the macOS Codex app. Check your version and catalog without printing credentials:

codex --version

CODEX_HOME_DIR="${CODEX_HOME:-$HOME/.codex}"
jq '.models[]
  | select(.slug | startswith("deepseek-"))
  | {slug, multi_agent_version, supports_search_tool, tool_mode}' \
  "$CODEX_HOME_DIR/models.json"

An affected official setup has values like these:

{
  "slug": "deepseek-v4-flash",
  "multi_agent_version": "v2",
  "supports_search_tool": true,
  "tool_mode": null
}

If no child is created, the provider returns 401 or 429, or the model cannot call any tool, diagnose provider authentication, quota, or tool exposure first. Fix Codex MCP Startup Interrupted shows how to separate a startup banner from actual tool availability.

Back Up the Generated Catalog

The DeepSeek setup script writes models.json, and running it again can replace your changes. Preserve an exact rollback copy before editing:

CODEX_HOME_DIR="${CODEX_HOME:-$HOME/.codex}"
cp "$CODEX_HOME_DIR/models.json" \
  "$CODEX_HOME_DIR/models.json.before-deepseek-subagent-fix"

Confirm the backup exists and parses:

jq empty "$CODEX_HOME_DIR/models.json.before-deepseek-subagent-fix"

Expected result: jq exits successfully and prints nothing.

Do not paste the surrounding config.toml into an issue or chat. A custom-provider block can contain a token, token helper, internal base URL, or other secret-bearing configuration.

Apply Both Compatibility Changes

On macOS, Linux, or WSL, update only model objects whose slug begins with deepseek-:

CODEX_HOME_DIR="${CODEX_HOME:-$HOME/.codex}"
MODELS_TMP="$(mktemp "$CODEX_HOME_DIR/models.json.XXXXXX")"

jq '
  .models |= map(
    if (.slug | startswith("deepseek-")) then
      .multi_agent_version = "v1"
      | .supports_search_tool = false
    else
      .
    end
  )
' "$CODEX_HOME_DIR/models.json" > "$MODELS_TMP"

jq empty "$MODELS_TMP"
mv "$MODELS_TMP" "$CODEX_HOME_DIR/models.json"

On Windows PowerShell, use the same two-field change:

$codexHomeDir = if ($env:CODEX_HOME) { $env:CODEX_HOME } else { Join-Path $HOME '.codex' }
$modelsPath = Join-Path $codexHomeDir 'models.json'
$backupPath = Join-Path $codexHomeDir 'models.json.before-deepseek-subagent-fix'

Copy-Item -LiteralPath $modelsPath -Destination $backupPath -Force
$catalog = Get-Content -LiteralPath $modelsPath -Raw -Encoding UTF8 | ConvertFrom-Json

foreach ($entry in $catalog.models) {
  if ($entry.slug -like 'deepseek-*') {
    $entry.multi_agent_version = 'v1'
    $entry.supports_search_tool = $false
  }
}

$catalog | ConvertTo-Json -Depth 100 | Set-Content -LiteralPath $modelsPath -Encoding UTF8
Get-Content -LiteralPath $modelsPath -Raw -Encoding UTF8 | ConvertFrom-Json | Out-Null

Then inspect only the non-secret model metadata again:

jq '.models[]
  | select(.slug | startswith("deepseek-"))
  | {slug, multi_agent_version, supports_search_tool}' \
  "${CODEX_HOME:-$HOME/.codex}/models.json"

Expected result: every DeepSeek entry you plan to use shows "multi_agent_version": "v1" and "supports_search_tool": false.

Why both fields? V1 delivers a spawned task as ordinary user input instead of V2 encrypted inter-agent communication. However, the official DeepSeek catalog also declares search-tool support. With that flag enabled, Codex can defer the V1 collaboration tools behind tool_search, which DeepSeek may not call. Setting it to false makes those tools directly visible. Changing only the version can therefore replace an empty task with a missing spawn tool.

Restart Codex and Run a Delivery Canary

Quit every Codex CLI process and the Codex desktop app before testing. A running session retains its resolved model metadata.

Start a new disposable session in a harmless repository and give it this exact task:

Spawn exactly one fresh-context subagent. Its only task is to reply exactly:
DEEPSEEK_SUBAGENT_OK

Return the child's reply and nothing else. Do not edit files or run commands.

Success requires all three observations:

1. the parent invokes the V1 subagent tool;

2. a child turn starts and receives the exact marker task; and

3. the parent returns DEEPSEEK_SUBAGENT_OK.

A greeting, empty payload, direct answer from the parent, or absent collaboration tool is a failed canary. Do not infer success because a child thread merely exists.

Repeat once with a different marker through the follow-up path:

Send the same child one follow-up task: reply exactly DEEPSEEK_FOLLOWUP_OK.
Return the child's reply and nothing else.

Expected result: the existing child returns the new marker without another greeting.

Avoid Full-History Forks While This Bug Is Open

One August 4 reproduction reported that fork_turns="all" did more than lose the task: the child replayed inherited spawn calls and created recursive chains. Use a fresh child context for the canary, keep the task bounded, and interrupt unexpected descendants immediately.

Do not solve task delivery by copying secrets, the entire parent conversation, or repository-wide context into the child prompt. That hides the transport defect and increases both exposure and token use. Diagnose Codex Usage Limit Spikes provides a controlled baseline for one bounded subagent.

If the Compatibility Bridge Still Fails

Restore the catalog instead of stacking more speculative fields:

CODEX_HOME_DIR="${CODEX_HOME:-$HOME/.codex}"
cp "$CODEX_HOME_DIR/models.json.before-deepseek-subagent-fix" \
  "$CODEX_HOME_DIR/models.json"
jq empty "$CODEX_HOME_DIR/models.json"

Then use one of these bounded alternatives until Codex or the provider ships a compatible transport:

• keep the orchestrating parent and native subagents on an OpenAI catalog model;

• run DeepSeek in a separate Codex session and pass it a reviewed, plain-text task manually; or

• use an adapter only if it explicitly translates Codex Responses items and you can audit its source, request logging, and credential handling.

Do not install an unreviewed source patch into a production coding environment just to regain V2. The upstream issue includes a community patch, but it changes how inter-agent messages are delivered and must be rebuilt for each Codex release.

Why the Child Sees an Empty Payload

Codex Multi-Agent V2 constructs a task as inter-agent communication. The visible text contains routing metadata ending in Payload:, while the actual task is carried in a separate encrypted content block. OpenAI endpoints understand that client-server contract.

A Responses-compatible provider can support ordinary messages and function calls without supporting Codex-specific agent_message or encrypted_content items. In the reported DeepSeek path, the provider ignores that item, leaving only the empty envelope. Retrying followup_task repeats the same transport and therefore repeats the failure.

V1 avoids this specific contract by placing the task in plain user input. Making collaboration tools direct addresses the independent discovery problem created by the official catalog's supports_search_tool: true setting.

Verify One Read-Only Integration After Recovery

Task delivery is not enough if your coding workflow also needs external tools. After the marker canary passes, verify one harmless read-only integration without exposing a provider key to the child.

If the aident command is not installed, tell your coding agent: Follow https://aident.ai/SETUP.md.

aident account auth status
aident vault vault --action status
aident capabilities search \
  --query 'read-only Action for my test' \
  --targetEnv staging

Inspect and preflight the exact Action before execution. Success means the recovered agent can receive a bounded task, discover the reviewed Action contract, and return the expected read-only result while the underlying credential stays in Aident Vault.

Ready to prove both paths? Set up Aident Loadout and preflight one read-only Action.

Sources

• OpenAI Codex issue 36586: DeepSeek subagent task payload is invisible

• OpenAI Codex issue 36382: DeepSeek catalog hides deferred tools

• OpenAI Codex issue 17598: custom-provider native subagents fail

• OpenAI Codex Multi-Agent V2 handler

• OpenAI Codex Responses client

• DeepSeek official Codex setup script

• DeepSeek Codex integration guide

Review this article when issue 36586 closes, a Codex stable release changes non-OpenAI agent_message delivery, DeepSeek changes its Responses item compatibility, or the official DeepSeek catalog changes either multi_agent_version or supports_search_tool.