codex - 💡(How to fix) Fix Codex App shows stale local image when Markdown path is reused

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

This made an iterative image/video workflow look like the agent had not modified or rerendered the image. Rendering to a new filename immediately showed the updated bitmap, which strongly suggests the stale result was caused by client-side image caching keyed only by the path/URL.

Code Example

![frame](/tmp/codex-local-image-cache-demo.png)

---

![frame](/tmp/codex-local-image-cache-demo.png)

---

![frame](/tmp/codex-local-image-cache-demo-v2.png)
RAW_BUFFERClick to expand / collapse

What issue are you seeing?

Codex App appears to cache local images rendered from assistant Markdown by filesystem path. When an assistant message displays a local image with the same absolute path after the file has been regenerated, the UI may keep showing the previous bitmap even though the file on disk has changed.

This made an iterative image/video workflow look like the agent had not modified or rerendered the image. Rendering to a new filename immediately showed the updated bitmap, which strongly suggests the stale result was caused by client-side image caching keyed only by the path/URL.

What steps can reproduce the bug?

  1. In Codex App, have the assistant render a local image in Markdown, for example:

    ![frame](/tmp/codex-local-image-cache-demo.png)
  2. Replace /tmp/codex-local-image-cache-demo.png on disk with a visibly different image while keeping the exact same filename/path.

  3. Have the assistant send the same Markdown image tag again:

    ![frame](/tmp/codex-local-image-cache-demo.png)
  4. Observe that the displayed image can remain the old bitmap.

  5. Render the same updated image to a unique filename, for example:

    ![frame](/tmp/codex-local-image-cache-demo-v2.png)
  6. Observe that the newly named file displays correctly.

What is the expected behavior?

When a local image path is shown in a later assistant message, Codex App should not serve a stale bitmap if the underlying file has changed.

Possible fixes:

  • include file metadata such as mtime/size/content hash in the local image cache key;
  • append an internal cache-busting query/token when resolving local file images;
  • invalidate cached local image entries when the same path is re-rendered in a later message.

Additional information

Environment:

  • Codex App: 26.519.41501 (3044)
  • Bundle ID: com.openai.codex
  • Platform: macOS 26.4.1, Darwin 25.4.0, arm64

Why this matters:

This affects workflows that repeatedly regenerate a deterministic output path, such as Remotion still frames, design screenshots, and visual QA loops. The stale preview can make users think the agent failed to modify code or rerender, even when the output file on disk is updated.

I looked for the relevant UI code in the public openai/codex repository but did not find the Codex App frontend/image-rendering layer, so I am filing this as an App bug rather than a code PR.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING