Codex App shows stale local image when Markdown path is reused
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?
- In Codex App, have the assistant render a local image in Markdown, for example:
``markdown``
- Replace
/tmp/codex-local-image-cache-demo.pngon disk with a visibly different image while keeping the exact same filename/path. - Have the assistant send the same Markdown image tag again:
``markdown``
- Observe that the displayed image can remain the old bitmap.
- Render the same updated image to a unique filename, for example:
``markdown``
- 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
+1. This is really frustrating for visual work because it means the rendered Codex response cannot be trusted as proof of the current output. When screenshots or generated images are stale, the app can make a correct rerender look wrong, which breaks visual QA and forces users to verify the file outside Codex.
I am hitting this again in current Codex App sessions, and it is severe enough that it breaks visual QA workflows.
Current environment:
Screenshot 2026-06-24 at 13.30.49.png, 526,953 bytes, sha256 prefix3ca58aec2dd33b9fFailure mode:
This is especially painful for iterative screenshot/design/image-generation workflows because it makes the Codex conversation itself untrustworthy as evidence of the current file contents. The workaround is to constantly generate hash/versioned filenames, but the app should not require that.
Expected behavior: