fix: preserve clipboard image paths for path-based MCP tools

[hb-0]

Issue for this PR

Closes #17771

Type of change

• Bug fix

What does this PR do?

Path-based MCP tools (e.g. image readers) need a file path to access pasted images. Pasted clipboard images either had no path or lost it, so the tools received an incorrect/missing path. This PR makes pasted images reliably carry a usable path and improves temp-file management.

Desktop (packages/desktop, packages/app):

• Clipboard images are persisted to a dedicated temp dir (opencode-clipboard-<uuid>) removed on will-quit, instead of scattering files in os.tmpdir() that were never cleaned up.
• randomUUID() filenames avoid collisions; write failures degrade gracefully (return the image without a path so the caller falls back) instead of throwing.

TUI (packages/tui):

• Pasting a copied file (Finder Cmd+C) lost the path: the clipboard carries public.file-url but no PNGf flavor, so the PNGf read failed and pbpaste returned only the bare filename, which readLocalAttachment resolved against the cwd and failed. readClipboardFilePath now reads the file URL via «class furl» (with an fs.access check to reject plain-text false positives) before trying PNGf.
• Bracketed paste only delivers the text flavor, so pasteInputText retries through clipboard.read() to recover the full path when readLocalAttachment fails on the pasted filename.
• Screenshots (in-memory PNGf) had their temp file deleted immediately after reading, leaving the attachment without a path. The temp file is now kept (unique name) and returned as path.
• The file part uses the source path as filename when available, so the model/path-based tools receive the real path instead of a bare filename the model had to guess.

How did you verify your code works?

• macOS, Finder Cmd+C an image file → paste into TUI prompt → [Image N] placeholder with the full path; an image-recognition MCP tool received the correct image_path.
• macOS, screenshot to clipboard → paste into TUI → [Image N] placeholder; the persisted temp path was passed to the MCP tool and read successfully.
• Desktop: pasted screenshots persist under the dedicated temp dir and are removed on quit; a failed write no longer crashes the paste.
• bun typecheck passes for packages/tui and packages/desktop.

Screenshots / recordings

N/A — no UI change; the [Image N] placeholder already existed for successful image attachments.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

If you do not follow this template your PR will be automatically rejected.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Found related PRs that may be duplicates or address similar issues:

1. fix: preserve attachment file paths #34234 - fix: preserve attachment file paths - Directly related to preserving file paths for attachments
2. fix(tui): add plain text paste #34123 - fix(tui): add plain text paste - Related to clipboard pasting functionality in TUI
3. fix(tui): save clipboard-pasted images to temp files for MCP tool access #21633 - fix(tui): save clipboard-pasted images to temp files for MCP tool access - Addresses the exact same problem of saving clipboard images to temp files for MCP tools

PR #21633 appears to be the most directly related — it targets the same issue (clipboard-pasted images need temp file paths for MCP tool access). You should check if this is already merged or if #36051 is a different iteration/fix on that work.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.