Codex Isn't Reading Images

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

• #>7766
• #>6974
• #>8508

Powered by Codex Action

+1 on Mac Terminal.

Steps:

1. Capture a screenshot into clipboard
2. Paste into Codex CLI
3. It can't read it.

<img width="1170" height="52" alt="Image" src="https://github.com/user-attachments/assets/8b6fb072-0a9e-40d4-914c-be937c1971e5" />

Yes, same issue here!

019b65db-3054-75b3-8e03-23a115a417ae

@ae-openai @aibrahim-oai

@InderdeepBajwa @toorusr I have a temporary fix that works well for me. Keep in mind, i'm on Linux and unsure how this would work on other platforms.

Obviously this will depend where your clipboard images are stored, and if they're accessible by the agent. In a container, they won't be.

Put this in the .codex/AGENTS.md:

## Clipboard Screenshots
- Pasted images named `codex-clipboard-*.png` are saved in root `/tmp` (e.g., `[codex-clipboard-mWiFoN.png 443x658]`).

Same here. I have to tell Codex to search in /tmp.

!Image

Ubuntu 25.10. Codex 0.77. gpt-codex 5.2.

+1, macos 26.2, Codex CLI 0.77

codex can only see the clipboard string, but cannot find the image

Same here. I have to tell Codex to search in /tmp. !Image Ubuntu 25.10. Codex 0.77. gpt-codex 5.2.

Use my instructions in base agents.md

Tell it to look for clipboard images in ROOT /tmp

Running into the same issue with 0.77.0 on MacOS in terminal. gpt-5.2-codex

For fellow MacOS users, you can put in the following into your AGENTS.md to get it to locate your screenshots

## Clipboard Screenshots
- Pasted images named `codex-clipboard-*.png` are saved under the filesystem root at: `/private/var/folders/*/*/T/` (e.g., `[codex-clipboard-mWiFoN.png 443x658]`).

For fellow MacOS users, you can put in the following into your AGENTS.md to get it to locate your screenshots `` ## Clipboard Screenshots - Pasted images named codex-clipboard-.png are saved under the filesystem root at: /private/var/folders//*/T/ (e.g., [codex-clipboard-mWiFoN.png 443x658]). ``

Good stuff brother

Now if any windows users can confirm their clipboard locations we'll have them all covered.

It's important you tell the agent the images are in ROOT.

Sorry for the slow response on this. On it

Sorry for the slow response on this. On it

All good! Thank you!

Same on Fedora 43 (codex-cli 0.79.0). Codex wasn't searching `` /tmp/agents/Screenshot-From-2026-01-09-18-11-01.png ` at all but instead was looking for ` /home/user/.codex/attachments/Screenshot-From-2026-01-09-18-11-01.png ` You don't have control over weather ` /tmp/agents/Screenshot-From-2026-01-09-18-11-01.png ` becomes ` [Screenshot-From-2026-01-09-18-11-01.png 252x650] ` from the TUI, nor what that points to. There is no ~/.codex/attachments/ directory. A confirmation of viewing the image, instead of a null response and changing CSS anyway, sure would have been helpful. I've updated AGENTS.md to make him substitute ` s^/home/user/.codex/attachments/^/tmp/agents/^ `` and acknowledge the location each time.

simply tell codex where to look (the right directory) in your AGENTS.md file in .codex (global) and it will almost always be able to find it.

If you're still having trouble, I created a free tool that will turn your screenshots into markdown. You can use free models on Openrouter, or you can use Gemini 2.5 flash and it'll work exactly the same way:

https://github.com/am-will/snag

Merged a PR to improve this behavior (based on our testing it seems to greatly reduce the model's tendency to look for the image in the filesystem), will close this issue for now. Please follow up if you notice this in the future!

Thank you @charley-oai

Thank you so much for fixing this @charley-oai!!

@charley-oai Thanks a lot!

seems to be working better 👍

Despite the positive reports, I still run into cases where Codex doesn’t recognize screenshots—either pasted or dragged from Finder.

It seems related to chat length. Image handling works reliably in a new chat, but at some point in longer conversations it breaks.

When this happens, Codex responds with:

• I can help, but I need two things first:

  1. The actual file path to the image (so I can view it in this environment).

This suggests the image isn’t being attached or recognized at all, rather than a permissions issue. The same actions work immediately in a fresh thread.

System Details

• macOS 26.2 (25C56)
• OpenAI Codex (v0.87.0)
• gpt-5.2-codex (current)

Let me know if there’s any additional logging or repro steps that would help.

@bikrrr, if you see this again, please use the /feedback slash command to upload your logs and session details, then create a new bug report and include the thread ID.