›_ Codex Issues
Codex Issues / #31112

Codex macOS app crops image previews, showing only the top portion

Open 💬 4 comments Opened Jul 4, 2026 by TidalPaladin

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

26.623.101652

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Image previews in the Codex macOS app are cropped vertically. Only the top portion of the image is visible, while the bottom is cut off.

This affects both:

  • inline image previews/thumbnails inside the thread
  • the opened image preview/viewer

The image itself appears to exist, but the preview container/viewer does not size or fit the image correctly.

<img width="727" height="327" alt="Image" src="https://github.com/user-attachments/assets/e5bef91f-c915-4e98-822c-56eebda848e8" />
<img width="474" height="351" alt="Image" src="https://github.com/user-attachments/assets/bc2d664c-2fa8-4eb2-acd1-2996f0be1074" />

What steps can reproduce the bug?

  1. Open Codex on macOS Apple Silicon.
  2. Use default app zoom.
  3. Open a thread that contains image previews, generated images, or image attachments.
  4. Observe the inline image preview.
  5. Click/open the image preview.
  6. Observe that only the top portion of the image is visible and the bottom is cropped.

This may be a function of image resolution / height in pixels but I'm unsure.

What is the expected behavior?

Inline previews and opened image previews should fit the available container or viewport so the full image is visible, with optional manual zoom/pan if needed.

Additional information

I found related reports, but none appear to be exact duplicates:

View original on GitHub ↗

4 Comments

MaxLinked · 1 month ago

I found that the PNG saved through Codex is truncated at exactly 524288 bytes (512 KiB) and is missing the final PNG IEND chunk, while the same remote file copied via scp is complete and opens normally.

matuscvengros · 1 month ago

Exactly the same issue here. Screenshots or even generated images in the Codex app thread preview are cropped, but when viewed directly, the images appear fine.

vibin-dirty · 1 month ago
Disclosure: This comment was generated and posted by OpenAI Codex at the user's request. The findings below are based on Codex's analysis of the locally installed Codex Desktop bundle, pixel-level comparison of the complete and cropped PNGs, and controlled protocol tests against the Codex app-server on the SSH host.

This is not macOS-only. Codex reproduced the same symptom on Windows 11 with Codex Desktop 26.707.9981.0, specifically when the task runs on a Linux host connected through Codex's SSH remote support. Local Windows tasks do not have the problem.

Observed behavior:

  • The image on the remote filesystem is complete and displays correctly when copied with scp/opened directly.
  • Inline preview and the opened viewer show only the top portion.
  • Electron's Copy image action also copies the partial image. In one sample, the copied PNG retained the full declared dimensions (1672x941), rows 0-666 were pixel-identical to the original, and the remaining rows were transparent.

Codex inspected the packaged desktop code and found a remote-only truncation path:

  1. Local images use the desktop app://fs / file:// path.
  2. For a Unix SSH remote, the desktop's execution-host readFile implementation runs cat <path> through app-server process/spawn.
  3. That request does not set outputBytesCap: null, so app-server applies its default stdout cap.
  4. The desktop client ignores capReached / stdoutCapReached, treats exit code 0 as a successful complete read, base64-encodes the received prefix, and supplies it to Chromium as an image data URL.
  5. Chromium can partially decode that truncated PNG prefix, producing the visible top portion and transparent/unrendered remainder.

Codex verified this directly against Codex app-server 0.144.4 on the SSH host:

process/spawn requested stdout: 3,000,000 bytes
outputBytesCap omitted:          1,048,576 bytes received, stdoutCapReached=true, exitCode=0
outputBytesCap: null:            3,000,000 bytes received, stdoutCapReached=false, exitCode=0

This also appears consistent with @MaxLinked's 512 KiB finding above; the exact cap can vary with the app-server version or execution path.

The fix belongs in the desktop client. For the Unix-remote cat read, it should either:

  • pass outputBytesCap: null, or preferably
  • use app-server's dedicated fs/readFile API, as the Windows-remote branch already does.

The client should additionally fail/retry any file read for which capReached is true instead of silently accepting incomplete bytes.

So the apparent preview cropping is a consequence of a truncated remote file transfer, not only a preview-container/CSS sizing problem.

FDoKE · 1 month ago

Annoying, same on windows. Trims images in previews and no way to look at them in codex