Codex desktop does not render MCP ImageContent as a visible chat attachment

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.51231 (bundled codex-cli 0.153.4)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 24.6.0 arm64 arm (macOS 15.6, build 24G84)

What issue are you seeing?

Codex desktop does not display images returned by an MCP tool, even when the response contains a valid standard MCP ImageContent block (type: "image", base64 data, and mimeType: "image/webp").

The tool result reaches the model as image content—the model can reason about it—and the response also includes structured metadata and working HTTPS links. However, the desktop chat shows no visible image attachment. Rendering the returned HTTPS URL with Markdown is also blank.

By comparison, Codex's built-in image generator renders images correctly through its dedicated media-result path. A local absolute-file Markdown image also renders, but only after host-side file handling, which is not a suitable production contract for MCP tools. No error is shown.

Impact: third-party MCP tools cannot present image outputs directly in Codex desktop, blocking the expected multimodal experience.

What steps can reproduce the bug?

1. Configure an MCP tool that returns a standard CallToolResult containing a bounded 37 KB WebP image, for example:

{
  "content": [
    {
      "type": "image",
      "data": "<base64-encoded 37 KB WebP>",
      "mimeType": "image/webp"
    },
    { "type": "text", "text": "Image metadata and HTTPS URL" }
  ],
  "structuredContent": { "imageUrl": "https://<working-image-url>" }
}

2. Invoke the tool from a Codex desktop task.
3. Observe that the model receives the image tool content, but the chat UI does not show an image attachment.
4. Ask Codex to embed the working HTTPS image URL using Markdown (![image](https://...)); the rendered result is blank.
5. Compare with Codex's built-in image generator, whose image is visible. A local absolute-file Markdown path also renders after manually saving the file on the host.

Reproduces consistently. The affected session ID is intentionally omitted from this public report and can be provided privately through in-app feedback.

What is the expected behavior?

A valid MCP ImageContent block accepted by Codex should appear as a visible inline image/attachment in the desktop conversation, with behavior comparable to Codex's built-in media-result rendering. This should not require the assistant or MCP host to write a local file or emit instruction-dependent Markdown.

Additional information

Technical details:

• Payload: valid, bounded 37 KB WebP; standard MCP image content block plus structured metadata.
• The HTTPS image links in the response are reachable.
• The model receives the image as tool content, so transport/tool ingestion succeeds; the failure appears limited to promoting that content into a user-visible desktop attachment.
• Built-in image generation works via a separate dedicated media-result path.
• Local absolute-file Markdown works, confirming the desktop can display file-backed images.
• Remote Markdown image embedding is blank.
• Suggested duplicate #23878 covers external Markdown image fetching (including macOS). That is adjacent, but this report's primary defect is different: a first-class MCP ImageContent tool result is already present inside Codex and is not rendered as an attachment.
• Suggested duplicate #19027 covers built-in generated images failing to embed; here the built-in generator renders correctly and the missing display path is specifically third-party MCP image content.
• No credentials, tokens, logs, base64 payload, or private URLs are included.

Start at the MCP ImageContent ingestion path and trace how tool results reach desktop chat attachment rendering; compare it with the built-in media-result path and the local file-backed image path described here. Done means a valid standard MCP image block appears as an inline image or attachment without Markdown or host-side file handling.