Codex Desktop on macOS: image-input turns take 130s cold / 45s warm before a trivial response

Open 💬 2 comments Opened Jul 14, 2026 by hug1997
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

  • Codex Desktop release: 26.707.72221
  • Bundled Codex CLI: 0.144.2

What platform is your computer?

  • macOS 26.5.2
  • Apple Silicon (arm64)

What issue are you seeing?

Image-input turns in Codex Desktop have very high time-to-first/final response, even when the prompt explicitly asks not to analyze the image and only return a fixed acknowledgement.

A controlled test used one PNG:

  • Dimensions: 1448 × 1086
  • File size: 1,200,858 bytes (~1.2 MB)
  • Prompt: 图片链路测试,不分析图片内容,只回复“附件接收成功”。
  • English: “Image-pipeline test. Do not analyze the image content. Only reply ‘Attachment received successfully.’”

Results in the same thread:

  1. First image turn immediately after fully restarting Codex:
  • Completed successfully
  • Duration: 130,737 ms
  1. Second turn with the same image and same prompt:
  • Completed successfully
  • Duration: 45,373 ms

The ~85-second reduction suggests a significant cold-start component, but the warmed request still taking ~45 seconds for a fixed one-line response is unexpectedly slow.

Test thread ID: 019f5ff5-113b-7091-be41-ae835789ef74

Local timing evidence

For the warmed second turn:

  • Desktop accepted turn/start in approximately 3 ms
  • The turn completed without an error
  • No tools were called
  • No unknown conversation error was logged for this test
  • The delay occurred after turn/start and before the final assistant response

This suggests the bottleneck is after local turn submission, likely in image upload/validation, multimodal preprocessing, upstream queueing, or time to first model output. The Desktop logs do not expose enough server-side phase timing to identify which stage dominates.

Text-only turns after the same restart responded normally.

What steps can reproduce the bug?

  1. Fully quit and restart Codex Desktop on macOS.
  2. Create a local task.
  3. Attach one ordinary PNG (~1.2 MB, 1448 × 1086).
  4. Use a trivial prompt that requests a fixed one-line acknowledgement and no image analysis.
  5. Measure the turn duration.
  6. Repeat the identical image/prompt in the same thread.

Observed: ~130.7 seconds on the cold request and ~45.4 seconds on the warmed request.

What is the expected behavior?

A small, single-image turn with a fixed acknowledgement should begin and complete promptly. If multimodal initialization or upstream queueing is slow, the UI should expose a phase-specific status instead of looking stuck.

Additional information

Possibly related to the broader pre-first-output observability problem described in #24260, but this report is specifically reproducible with image input on macOS and shows a large cold-versus-warm latency difference.

Useful diagnostics would include timestamps for:

  • local image accepted
  • upload started/completed
  • image validation/preprocessing started/completed
  • upstream request sent
  • response headers / first byte received
  • first model event received

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32394

Powered by Codex Action

hug1997 · 1 month ago

Additional reproducible hard-stall sample from the same macOS Codex Desktop installation (2026-07-15).

Thread ID: 019f6001-2db9-7730-8e1a-fdadce110ed2

Observed timeline (UTC):

  • 2026-07-15T02:27:30.680Z: task_started
  • 2026-07-15T02:27:31.448Z: user message persisted with one inline PNG input
  • 2026-07-15T02:27:31.464Z: user_message
  • At 2026-07-15T02:34:30Z (over 6 minutes later), the rollout still ended at that user_message event.

There were no subsequent reasoning items, assistant messages, tool calls, token-count events, task_complete, or turn/error records. The Desktop UI continued showing the task as thinking, so this is a pre-first-output hard stall rather than merely a slow completed image turn.

Sanitized payload-size evidence (image content was not inspected or uploaded):

  • input_image.image_url length: 1,828,030 characters
  • Encoding prefix: data:image/png;base64,...
  • Entire persisted user-message JSONL record: 1,828,787 characters
  • Session rollout size before this image turn: approximately 11.45 MB
  • Session rollout size after persisting the image turn: 13,281,063 bytes

This sample suggests image-input latency can become a hard stall when a large inline image is added to an already tool-heavy/large thread. It also strengthens the case for phase-specific diagnostics and for externalizing or capping inline image payloads before context assembly/persistence.

This is the input-image path, not the separate generated-image-result/C2PA issue reported in #33021. No screenshot contents, raw base64, project source, or filesystem paths are included here.