Codex Windows: subagent-generated images missing from parent Canvas, no lossless add/import path

Existing in-app feedback

This issue has already been submitted through the Codex app’s /feedback entry. The app confirmed that feedback was uploaded. Please correlate this GitHub report with feedback ID:

01a05eb4-6d9d-7cd2-8bae-207d9839f69b

This GitHub issue provides the detailed chronology and expected behavior; it is a follow-up to the uploaded feedback, not a separate independent reproduction.

Environment

• Codex desktop app on Windows, x64
• App package version: 26.901.4073.0
• Observed: September 5, 2026 (Asia/Shanghai)
• Built-in image generation, delegated subagents, native image Canvas
• Scope: one real UI-mockup workflow plus subsequent recovery attempts; not independently reproduced in a fresh chat or another version

Context and chronology

The user requested a consistent set of Windows application UI mockups, explicitly asking for preview images only, not implementation code.

1. The first two screens (tool selection; installation and activation) were generated directly in the parent conversation with the built-in image generation tool. They appeared in the parent chat’s native Canvas.
2. The user then requested three follow-up screens: automatic login, ready/start using, and account management. The assistant delegated these to isolated subagents, each using the same style reference and the built-in image generation tool.
3. All three PNGs were generated successfully, saved and inspected (1448 × 1086 each). This was not an image-generation failure or missing-file problem.
4. The parent assistant returned those files as local/Markdown image previews. They could be displayed in the conversation, but the user reported that the parent Canvas still did not contain the three new screens and supplied a screenshot.
5. The assistant then loaded the exact existing PNGs and re-emitted them in the parent via generatedImage({image_url, output_hint}), without regenerating them. The user explicitly confirmed that the Canvas was still not updated.
6. The assistant searched available tools and documentation for an import/adopt/merge route, but did not find a supported way to add the existing child-generated originals to the parent Canvas. This is limited to the interfaces available in this session, not proof that no such feature exists anywhere.

The assistant’s initial recovery attempt conflated displaying an image with registering it in Canvas. The user’s observation established that the attempt did not work. Regenerating the images in the parent was suggested, but was NOT performed because it would consume additional usage and could alter already-approved pixels.

Suggested reproduction steps

1. Generate image A directly in a parent chat and confirm it appears in Canvas.
2. Delegate image B to a subagent using the built-in image generation tool.
3. Return B to the parent and embed its local file as an image.
4. Inspect the parent Canvas for B.
5. Read the existing B file and re-emit it via generatedImage in the parent; inspect Canvas again.

Actual result

The three follow-up image files exist and can be displayed, but remain absent from the parent Canvas according to the user. One logical set of mockups is fragmented across generation contexts. Re-displaying existing originals did not repair the Canvas collection.

Expected result

Provide a supported, lossless way for the parent chat to adopt delegated generated images into its Canvas, preserving exact pixels, provenance and file association, without having to generate them again. If automatic inclusion is intentionally out of scope, an explicit Add to current Canvas / Adopt subagent image operation would address the workflow.

Interpretation and documentation

The documentation describes Canvas as showing images generated in the same chat: https://learn.chatgpt.com/docs/image-generation

Therefore, this may be intended conversation scoping rather than a storage failure. The suspected boundary between parent and child generation records is a hypothesis, not a confirmed root cause. Please clarify the intended behavior and investigate the missing integration/recovery path.

Impact and requested improvements

• The user cannot review, select and iterate on the full design set in one Canvas.
• The assistant can mistake successful image display for successful Canvas inclusion.
• Regeneration solely to populate Canvas adds latency and usage, and may change an approved design.
• Please expose an explicit add/adopt operation with deduplication and a clear success result.
• Please document whether generatedImage only displays media or also registers it for Canvas.
• If delegated images cannot be included, an upfront capability warning would prevent this workflow failure.

The user supplied a screenshot confirming the in-app feedback upload and authorized attaching the feedback ID above. Full chat history, account credentials, local user paths and unrelated project details are intentionally not included in this public issue.

The report names the Codex desktop app, native image Canvas, delegated subagents, and generatedImage, but no repository files or tests. Start by tracing how parent and subagent image-generation records reach Canvas, then verify whether re-emitting an existing image registers it or only displays it. Done means delegated images can be adopted losslessly with provenance and file association, or the intended limitation is clearly documented.