[GH-ISSUE #392] Codex 0.148.0: Responses silently drops multi-agent agent_message tasks #123

New issue

Open

opened 2026-10-26 09:45:43 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented 2026-10-26 09:45:43 +00:00

Owner

Copy link

Originally created by @Arcobalneo on GitHub (Aug 19, 2026).
Original GitHub issue: https://github.com/deepseek-ai/awesome-deepseek-agent/issues/392

Summary

When DeepSeek is used as a custom model provider for OpenAI Codex with wire_api = "responses", Codex multi-agent tasks are silently lost. spawn_agent, followup_task, and send_message create or address a child thread, but the child never receives the dispatched task text. It initializes and replies with a generic “I don't see a task” message instead of executing the task.

This still reproduces with Codex CLI 0.148.0 and affects both deepseek-v4-flash and deepseek-v4-pro when the official setup selects multi_agent_version: "v2".

Related reports: #335 and #349. This issue adds the current-version reproduction, protocol-level failure mode, and a working configuration workaround.

Environment

• OpenAI Codex CLI: 0.148.0 (also reproduced on 0.145.0 and 0.146.0)
• Provider: DeepSeek
  • base_url: https://api.deepseek.com/
  • wire_api: responses
• Models: deepseek-v4-flash and deepseek-v4-pro
• Model entries generated by the official DeepSeek one-command Codex setup

Sanitized ~/.codex/config.toml:

model = "deepseek-v4-pro"
model_provider = "deepseek"

[model_providers.deepseek]
name = "deepseek"
base_url = "https://api.deepseek.com/"
wire_api = "responses"

Relevant ~/.codex/models.json entry:

{
  "slug": "deepseek-v4-pro",
  "multi_agent_version": "v2",
  "supports_search_tool": true,
  "tool_mode": null,
  "web_search_tool_type": "text"
}

Steps to reproduce

1. Configure Codex with DeepSeek using the official DeepSeek Codex integration setup.

2. Start a new Codex session with deepseek-v4-flash or deepseek-v4-pro.

3. Dispatch a trivial task, for example:

   spawn_agent(task_name="probe", message="Reply with exactly: PONG")
   

4. Alternatively, resend the same task using followup_task.

Actual behavior

• A child thread is created and initializes successfully.
• The child reads the workspace, but never sees Reply with exactly: PONG.
• It replies with a generic greeting such as “I don't see a task or question yet.”
• Repeating the task through followup_task has the same result.
• The parent never receives PONG.
• No API validation error or warning explains that the task payload was discarded.

Expected behavior

The child should receive the exact dispatched task and return PONG. If the endpoint does not support the item or content-block type used by Codex, it should return an explicit 400 invalid_request_error rather than silently accepting and dropping it.

Protocol analysis

With Codex MultiAgent V2, the dispatched task is carried in a ResponseItem::AgentMessage whose content contains:

1. an input_text routing header ending in Payload:; and
2. an encrypted_content block carrying the task text.

Representative shape:

{
  "type": "agent_message",
  "author": "/root",
  "recipient": "/root/probe",
  "content": [
    {
      "type": "input_text",
      "text": "Message Type: NEW_TASK\nTask name: /root/probe\nSender: /root\nPayload:\n"
    },
    {
      "type": "encrypted_content",
      "encrypted_content": "Reply with exactly: PONG"
    }
  ]
}

The DeepSeek Responses endpoint appears to skip the unsupported agent_message input item entirely. Tests reported in #335 show that replacing encrypted_content with plaintext input_text inside agent_message still loses the content, and even a deliberately unknown item type is accepted and skipped in the same way. This suggests the primary incompatibility is the agent_message item type, not only the nested content-block type.

The silent acceptance is particularly harmful: it converts a protocol incompatibility into a successful-looking response whose model context is missing the task.

Suggested actions

1. Server validation: return 400 invalid_request_error for unsupported ResponseItem or content-block types instead of silently discarding them.
2. Compatibility documentation: publish the supported Responses API item and content-block types, especially message, agent_message, input_text, output_text, and encrypted_content.
3. Official setup: do not advertise multi_agent_version: "v2" until the transport is supported end-to-end; document the limitation and workaround.
4. Coordination: work with OpenAI/Codex on a provider-neutral plaintext inter-agent transport, or normalize agent_message to a model-visible user message at the DeepSeek compatibility layer.

Impact

Codex multi-agent workflows are silently non-functional under the official DeepSeek Responses configuration. Because the child may fall back to visible parent context and produce a plausible but unrelated answer, this can also create incorrect results without an obvious failure signal.

Workaround

In ~/.codex/models.json, set the DeepSeek model entries to:

{
  "multi_agent_version": "v1",
  "supports_search_tool": false
}

Then fully quit all Codex CLI/Desktop processes and start a new session. In tested CLI builds, V1 sends the task as plain user input and the child receives it. supports_search_tool: false keeps collaboration tools directly visible and does not disable hosted web search.

Note: as discussed in #335, some Desktop alpha builds may hide collaboration tools under V1 instead of restoring task delivery, so this workaround may be client-build dependent.

References

• deepseek-ai/awesome-deepseek-agent#335
• deepseek-ai/awesome-deepseek-agent#349
• openai/codex#36586 — custom-provider subagent payload invisibility with MultiAgent V2
• openai/codex#36382 — tools silently unavailable with the official DeepSeek setup
• https://aident.ai/blog/fix-codex-deepseek-subagent-no-task

Originally created by @Arcobalneo on GitHub (Aug 19, 2026). Original GitHub issue: https://github.com/deepseek-ai/awesome-deepseek-agent/issues/392 ## Summary When DeepSeek is used as a custom model provider for OpenAI Codex with `wire_api = "responses"`, Codex multi-agent tasks are silently lost. `spawn_agent`, `followup_task`, and `send_message` create or address a child thread, but the child never receives the dispatched task text. It initializes and replies with a generic “I don't see a task” message instead of executing the task. This still reproduces with Codex CLI 0.148.0 and affects both `deepseek-v4-flash` and `deepseek-v4-pro` when the official setup selects `multi_agent_version: "v2"`. Related reports: #335 and #349. This issue adds the current-version reproduction, protocol-level failure mode, and a working configuration workaround. ## Environment - OpenAI Codex CLI: 0.148.0 (also reproduced on 0.145.0 and 0.146.0) - Provider: DeepSeek - `base_url`: `https://api.deepseek.com/` - `wire_api`: `responses` - Models: `deepseek-v4-flash` and `deepseek-v4-pro` - Model entries generated by the official DeepSeek one-command Codex setup Sanitized `~/.codex/config.toml`: ```toml model = "deepseek-v4-pro" model_provider = "deepseek" [model_providers.deepseek] name = "deepseek" base_url = "https://api.deepseek.com/" wire_api = "responses" ``` Relevant `~/.codex/models.json` entry: ```json { "slug": "deepseek-v4-pro", "multi_agent_version": "v2", "supports_search_tool": true, "tool_mode": null, "web_search_tool_type": "text" } ``` ## Steps to reproduce 1. Configure Codex with DeepSeek using the official DeepSeek Codex integration setup. 2. Start a new Codex session with `deepseek-v4-flash` or `deepseek-v4-pro`. 3. Dispatch a trivial task, for example: ```text spawn_agent(task_name="probe", message="Reply with exactly: PONG") ``` 4. Alternatively, resend the same task using `followup_task`. ## Actual behavior - A child thread is created and initializes successfully. - The child reads the workspace, but never sees `Reply with exactly: PONG`. - It replies with a generic greeting such as “I don't see a task or question yet.” - Repeating the task through `followup_task` has the same result. - The parent never receives `PONG`. - No API validation error or warning explains that the task payload was discarded. ## Expected behavior The child should receive the exact dispatched task and return `PONG`. If the endpoint does not support the item or content-block type used by Codex, it should return an explicit `400 invalid_request_error` rather than silently accepting and dropping it. ## Protocol analysis With Codex MultiAgent V2, the dispatched task is carried in a `ResponseItem::AgentMessage` whose content contains: 1. an `input_text` routing header ending in `Payload:`; and 2. an `encrypted_content` block carrying the task text. Representative shape: ```json { "type": "agent_message", "author": "/root", "recipient": "/root/probe", "content": [ { "type": "input_text", "text": "Message Type: NEW_TASK\nTask name: /root/probe\nSender: /root\nPayload:\n" }, { "type": "encrypted_content", "encrypted_content": "Reply with exactly: PONG" } ] } ``` The DeepSeek Responses endpoint appears to skip the unsupported `agent_message` input item entirely. Tests reported in #335 show that replacing `encrypted_content` with plaintext `input_text` inside `agent_message` still loses the content, and even a deliberately unknown item type is accepted and skipped in the same way. This suggests the primary incompatibility is the `agent_message` item type, not only the nested content-block type. The silent acceptance is particularly harmful: it converts a protocol incompatibility into a successful-looking response whose model context is missing the task. ## Suggested actions 1. **Server validation:** return `400 invalid_request_error` for unsupported `ResponseItem` or content-block types instead of silently discarding them. 2. **Compatibility documentation:** publish the supported Responses API item and content-block types, especially `message`, `agent_message`, `input_text`, `output_text`, and `encrypted_content`. 3. **Official setup:** do not advertise `multi_agent_version: "v2"` until the transport is supported end-to-end; document the limitation and workaround. 4. **Coordination:** work with OpenAI/Codex on a provider-neutral plaintext inter-agent transport, or normalize `agent_message` to a model-visible user message at the DeepSeek compatibility layer. ## Impact Codex multi-agent workflows are silently non-functional under the official DeepSeek Responses configuration. Because the child may fall back to visible parent context and produce a plausible but unrelated answer, this can also create incorrect results without an obvious failure signal. ## Workaround In `~/.codex/models.json`, set the DeepSeek model entries to: ```json { "multi_agent_version": "v1", "supports_search_tool": false } ``` Then fully quit all Codex CLI/Desktop processes and start a new session. In tested CLI builds, V1 sends the task as plain user input and the child receives it. `supports_search_tool: false` keeps collaboration tools directly visible and does not disable hosted web search. Note: as discussed in #335, some Desktop alpha builds may hide collaboration tools under V1 instead of restoring task delivery, so this workaround may be client-build dependent. ## References - deepseek-ai/awesome-deepseek-agent#335 - deepseek-ai/awesome-deepseek-agent#349 - openai/codex#36586 — custom-provider subagent payload invisibility with MultiAgent V2 - openai/codex#36382 — tools silently unavailable with the official DeepSeek setup - https://aident.ai/blog/fix-codex-deepseek-subagent-no-task

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels   

pull-request

Mirrored from GitHub Pull Request

No labels

pull-request

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

deepseek-ai/awesome-deepseek-agent#123

No description provided.