Codex macOS app fails to ingest dragged Xcode Simulator screenshot thumbnail because it keeps a temporary file path
What variant of Codex are you using?
App
What feature would you like to see?
Summary
Dragging the temporary screenshot thumbnail from iOS Simulator into the Codex macOS app creates an unusable image attachment. Codex later reports that it cannot read the local image because the temporary file no longer exists.
This feels like a Codex app drag-and-drop ingestion bug: other macOS apps accept the same Simulator screenshot thumbnail drag and materialize it as an image/file immediately, behaving as if the screenshot had been dragged from Finder.
Environment
- App: Codex macOS app
- Platform: macOS
- Source app: Apple Simulator
- Attachment type: Simulator screenshot thumbnail dragged immediately after capture
Steps To Reproduce
- Open an iOS app in Apple Simulator.
- Take a Simulator screenshot.
- While the temporary screenshot thumbnail is visible, drag that thumbnail directly into a Codex chat.
- Send a message asking Codex to inspect the image.
Actual Behavior
Codex receives a path like:
/var/folders/.../T/simulator_screenshot_<UUID>.png
But when the assistant tries to read it, the file is already gone:
No such file or directory (os error 2)
The image is therefore unavailable to the model.
Expected Behavior
Codex should eagerly ingest/materialize dragged file promises or temporary thumbnail items at drop time, copying the image bytes into Codex-owned attachment storage before the source temp file disappears.
The drag should work the same way it does in other macOS apps (including ChatGPT; both desktop and web), where dropping the Simulator thumbnail produces a durable image attachment that Codex can inspect later in the turn.
Why This Matters
This is a high-frequency workflow for iOS development. Simulator screenshots are often used to ask Codex about UI state, layout bugs, visual regressions, and implementation details. Requiring the user to wait for the file to save, find it in Finder/Desktop, or use a separate screenshot capture command slows down the tight development loop.
Suggested Fix
On drop, Codex should resolve NSItemProvider / promised-file drag items immediately and copy the underlying image data into its own attachment cache. It should not defer reading by retaining only the temporary source path.
If the dragged item is a file promise, Codex should complete the file promise transfer into app-controlled storage before sending the attachment to the agent runtime.
Workarounds
- Paste the screenshot image directly into chat.
- Drag the saved screenshot file from Finder/Desktop after it has fully materialized.
- Use an MCP/tool-based Simulator screenshot capture command instead of dragging the thumbnail.
These workarounds are slower than dragging the temporary Simulator screenshot thumbnail directly.
Additional information
_No response_