Codex project threads hang after image2 writes huge C2PA/image payloads into turn events

Original report title

Codex 项目线程调用 image2 后写入超大结果，导致线程持续假死并消耗大量 token

Environment

• Codex Desktop release: 26.707.72221
• Bundled Codex CLI: 0.144.2
• macOS 26.5.2, Apple Silicon (arm64)
• Plan shown in local rate-limit telemetry: Plus

What issue are you seeing?

In local Codex Desktop project threads, the image-generation tool (referred to as image2 in the UI/workflow) successfully generates a website background image, but the completed result is then written into the turn/session event as a very large inline image payload.

The generated PNG bytes include C2PA/JUMBF manifest data. The resulting inline event/tool output is millions of serialized characters. After image generation reports completed, the thread stops making useful progress: it does not continue copying the image into the project, editing code, building, or returning a final response. The UI remains active / inProgress until the user interrupts it.

Reproduction evidence

Thread 1

Thread ID:

019f5f9e-81e0-7e81-8544-49fc5f31c2eb

• Image generation completed at 2026-07-14T08:10:27.814Z.
• Saved PNG size: 2,186,047 bytes.
• The PNG contains C2PA/JUMBF markers, including jumdc2pa, c2pa, a urn:c2pa:... manifest identifier, and c2pa.assertions.
• image_generation_end.payload.result serialized length: 2,914,732 characters.
• The following function/tool output serialized length: 2,915,306 characters and contained an inline image item.
• No normal post-generation project workflow completed. The thread was eventually interrupted.
• Local token telemetry reached 2,257,860 cumulative tokens in the thread after repeated continuation/polling calls; several later calls each reported roughly 89K input tokens.

Thread 2 / continuation thread

Thread ID:

019f5fbb-173f-7f22-93cc-46014e00fa7e

• The continuation thread attempted to inspect/reuse the already generated PNG.
• A single image tool output serialized to 2,914,891 characters.
• No final project action completed after that output.
• The turn remained stalled for about 6.5 minutes and was manually interrupted.

Thread 3

Thread ID:

019f5fc5-65c2-7df2-83ed-808c2e5159c3

• Image generation completed at 2026-07-14T08:41:34.784Z.
• Saved PNG size: 1,825,277 bytes.
• The PNG also contains C2PA/JUMBF markers and a C2PA manifest identifier.
• image_generation_end.payload.result serialized length: 2,433,704 characters.
• The following function/tool output serialized length: 2,434,278 characters and contained an inline image item.
• No subsequent tool action or final response completed for about 10 minutes.
• The turn was manually interrupted.
• Local token telemetry reached 428,669 cumulative tokens in this short continuation thread.

The raw serialized image-result sizes are approximately 2.43–2.92 million characters. Using a simple four-characters-per-token size comparison, that is roughly 0.61–0.73 million token-equivalent characters per image result. This is a size estimate, not a claim about the exact billable-token calculation. The separate local token_count records nevertheless show large and repeated input-token usage after the image payload entered the thread.

Steps to reproduce

1. Open a local Codex Desktop project thread.
2. Ask Codex to use image2 / the image-generation tool to create a website card background.
3. Wait for image generation to complete successfully.
4. Observe that the generated image result is embedded into the turn/event as a large inline image/base64-style payload, including PNG/C2PA data.
5. Observe that the thread remains active / inProgress but does not continue with the requested project work or return a final response.
6. Interrupt and start a continuation thread.
7. Attempt to inspect or reuse the generated image; the large inline image output is introduced again and the continuation thread can stall as well.

Impact

• The same project required multiple continuation threads.
• Threads appeared frozen or stopped before the requested code/build work.
• Repeated retries and polling caused substantial unnecessary token usage.
• The user lost task continuity even though image generation itself succeeded.

Expected behavior

• Image generation results should not inject the complete PNG binary, base64 representation, or C2PA payload into the project-thread model context or persisted event stream.
• The tool should return only a lightweight artifact reference, local saved path, content hash, dimensions, and small metadata summary.
• The generated artifact should be available to later tools by reference without replaying the full image bytes.
• If an image result exceeds a safe context/event limit, Codex should cap or externalize it and continue the requested workflow.
• The thread should proceed to copy the asset, edit code, build, and provide a final response.

Suggested safeguards

• Replace inline generated-image bytes in image_generation_end.payload.result and function/tool outputs with artifact references.
• Do not duplicate the same image bytes across event messages, tool output, persisted rollout JSONL, and context replay.
• Strip or externalize C2PA/JUMBF binary data from model-visible/session-visible payloads while preserving the original saved artifact.
• Add hard byte/token caps before image results enter model context.
• Add a clear recoverable error if the result exceeds the cap.
• Prevent repeated wait/polling continuation calls from replaying the full prior image payload.

Usage investigation and compensation request

Please investigate abnormal token/usage consumption associated with the three thread IDs above. The user requests review and compensation for usage consumed by the oversized image-result injection, repeated polling, and stalled continuation attempts.

If GitHub maintainers cannot handle account-level usage adjustments, please identify the correct support channel and the exact session/thread identifiers the user should provide.

Related reports

• #33018 — image-input turns taking 130 seconds cold / 45 seconds warm on the same macOS installation.
• #24676 — image-heavy session rollouts containing very large inline image payloads.

No private image content, project source code, local filesystem paths, or raw rollout records are attached to this report.