Repository navigation
tui: macOS screenshot thumbnail attachments fail after upgrading to 2.2.1 #60210
Description
Description
Dragging the floating macOS screenshot thumbnail into the TUI worked before upgrading from 2.2.0 to 2.2.1. Now the image attaches, but submitting the prompt fails with:
Unable to read attachment: file:///var/folders/<redacted>/T/TemporaryItems/NSIRD_screencaptureui_<redacted>/Screenshot%202026-10-29%20at%2013.26.26.png
Expected the image to send as it did before the upgrade.
This follows #59833, which replaces captured image bytes with a file URI for local servers. The temporary screenshot still exists, but the background server cannot read it. The fallback only handles a missing file.
Verified cause
Ran the released 2.2.1 promptFilesForServer against the affected path. existsSync returns true, so it sends file:// instead of the captured bytes. Reading that file from the background server fails with EPERM: operation not permitted. The path-replacement function is absent in 2.2.0 and still present on dev.
The TUI and background server run on the same machine but do not necessarily have the same macOS file access. Preserve the captured bytes when the server cannot read the attachment.
Plugins
None configured.
Screenrecording
Screen.Recording.2026-10-29.at.14.07.51.mov
OpenCode version
2.2.1, release channel. Previously working on 2.2.0.
Steps to reproduce
- Open the TUI using the default local background service on macOS.
- Take a screenshot with Cmd+Shift+4.
- Drag its floating thumbnail directly into the TUI, before saving it to a regular location.
- Submit a prompt with the attached image.
- Observe the attachment read error.
Screenshot
Operating System
macOS 27.0.1, arm64.
Terminal
Ghostty, zsh.
Activity
opencodejr commentedon Oct 29, 2026
Thanks for the detailed report and analysis. I couldn't reproduce this here. The failure depends on macOS file access for the temporary
screencaptureuiitem: the TUI can read the file, but the background service getsEPERM. My sandbox is Linux, so it can't set that up, and a maintainer on macOS will need to confirm it.Your analysis matches the code. On the latest
dev(726cf09),promptFilesForServerstill sends afile://URI whenever the file exists and the server is local, and it only falls back to the captured bytes when the file is missing. A file that exists but the server isn't allowed to read still ends up with the attachment read error. That function isn't in 2.2.0, which fits this being a regression from #59833.Until this is looked at, saving the screenshot somewhere normal (e.g. Desktop) before attaching it should avoid the error. Related: #59833 (the change that introduced this) and #46664 (capturing dropped temporary files at drop time).