You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG][Desktop vs Terminal] Pasting local file path has inconsistent behavior and no way to paste as plain text #34006
When pasting a local file path (e.g. C:\Users\user\Desktop\image.png) into opencode, the behavior differs between Desktop and Terminal, and neither mode allows pasting the path as plain text.
Desktop App Behavior
Pasting a local file path like C:\Users\user\Desktop\image.png automatically converts it to a file link (attachment reference). The path string itself is never sent to the model.
Terminal (CLI) Behavior
Pasting the same path automatically reads the file and embeds it as an image. The path string is again lost — the model receives the image content instead.
Problem
For users who use non-vision models (models that cannot process images), there is no way to paste a local file path as plain text. The intent is to let the AI see the path string itself (e.g., to ask it to copy the file, reference it in code, or describe what the filename means), not to embed the file content or create a link.
Expected Behavior
There should be a way to paste a local file path as plain text — for example:
A modifier key (Ctrl+Shift+V / Alt+V) to paste as raw text
A right-click context menu option "Paste as path"
Or auto-detection: paths wrapped in quotes or backticks are treated as text
Environment
opencode Desktop (Windows)
opencode Terminal (Windows)
Both exhibit different behavior but neither supports plain-text path pasting
Additional Context
This is a combination of a bug (inconsistent Desktop vs Terminal behavior) and a feature request (need for a "paste as plain text" mode for file paths). The existing issue #32014 only covers the CLI side, but does not address the Desktop app or the inconsistency between the two.
Related: #19892 (CLI only), #23458 (Ctrl+Shift+V works as plain text paste on Linux TUI but not documented/consistent).
I read the code and tested on my machine. I can confirm some of the inconsistency described in this issue.
Root Cause Analysis
TUI:
pasteInputText() calls pastedFilepath() to detect file paths from pasted text. When a valid path is found, it passes it to readLocalAttachment(), which reads the file content and embeds it as [Image N] / [PDF N]. The path string itself is consumed and never sent to the model.
Desktop:
Pasting a plain text string like C:\Users\...\image.png into the Desktop app does not trigger attachment conversion — plain text is inserted normally (tested on Windows 10). The attachment behavior only occurs when an actual file is copied from the OS (the clipboard contains file items, not text). In that case, handlePaste() in attachments.ts detects kind === "file" items in clipboardData.items and converts them to attachments.
Why Ctrl+Shift+V Behavior Is Inconsistent
When running opencode in Windows Terminal with PowerShell, Ctrl+Shift+V still goes through bracketed paste, triggering file detection and consuming the path. On Linux, GNOME Terminal may intercept Ctrl+Shift+V and injects text as individual keystrokes, bypassing file detection. This is terminal-level behavior and unreliable across platforms.
Proposed Approach
TUI-only fix. Add a new Ctrl+Alt+V keybinding (avoiding Ctrl+Shift+V due to inconsistent terminal interception) that pastes clipboard text without file path detection or content embedding. A new prompt.paste-plain command would read clipboard text and insert it directly via input.insertText(), bypassing pastedFilepath() / readLocalAttachment().
The Desktop app is left for now — plain text path pasting works correctly there, and what users expect when copying actual files can be discussed separately.
If this direction looks good, I'll open a PR for the TUI side.
My proposed scope is a small TUI-only fix: add an explicit plain-text paste command/keybinding that reads clipboard text and inserts it directly into the prompt, bypassing the current local-file attachment detection path. I would leave the existing Ctrl+V behavior unchanged, and likely use a separate default such as Ctrl+Alt+V because Ctrl+Shift+V is intercepted inconsistently by terminals.
I would not change Desktop behavior in the same PR unless maintainers prefer that, since pasting actual file clipboard items as attachments appears to be separate from pasting a plain text path.
I meet the same issue. This should be considered as a BUG.
We should at least have a configuration option to disable this feature.
By default, I would prefer this feature to be disabled.
I reproduced this on the current dev branch (e8b09927889ba4b5b7fc74bbab5b864d205406ca) on Windows.
The TUI path is still: onPaste -> pasteInputText() -> pastedFilepath() -> readLocalAttachment() -> pasteAttachment().
For a valid local PNG/JPG/PDF path, the file is read from disk, converted to base64, and stored as a FilePart; the literal path is not inserted as text. If the selected model does not support the corresponding modality, ProviderTransform.unsupportedParts() later replaces the attachment with an error message, so the model still never sees the path itself.
Would maintainers prefer a small explicit plain-text paste command/keybinding (reviving the scope of #34123), or a persistent TUI/config toggle that bypasses local-path attachment detection? For the toggle approach, I can keep user preference separate from model capability: attach only when enabled and the selected model supports that MIME type; otherwise insert the path verbatim.
I can work on the preferred scope and include focused tests for Windows paths, quoted paths, PNG/JPG, and PDF.
Environment: Windows 11, opencode 1.18.18 (VS Code extension + Windows Terminal).
I use "Copy as path" then paste into the prompt, and it's immediately converted to [image 1] instead of the text path. My model doesn't support image input, so I have no way to reference the file path as text.
Please add an option to paste a file path as plain text.
+1 — Hitting this daily: valid local file paths get auto-materialized as attachments, so non-multimodal contexts never receive the path text. The proposed Ctrl+Alt+V plain-text paste (or a config toggle to disable auto-attach on paste) would fully solve it. Still reproducible on v1.18.21, macOS + Ghostty.
Closing as a duplicate of #19892, which tracks pasted file paths always becoming attachments with no way to paste them as plain text. Please add your Desktop vs Terminal details and 👍 there.
Activity
dsy122 commentedon Jun 26, 2026
I read the code and tested on my machine. I can confirm some of the inconsistency described in this issue.
Root Cause Analysis
TUI:
pasteInputText()callspastedFilepath()to detect file paths from pasted text. When a valid path is found, it passes it toreadLocalAttachment(), which reads the file content and embeds it as[Image N]/[PDF N]. The path string itself is consumed and never sent to the model.Desktop:
Pasting a plain text string like
C:\Users\...\image.pnginto the Desktop app does not trigger attachment conversion — plain text is inserted normally (tested on Windows 10). The attachment behavior only occurs when an actual file is copied from the OS (the clipboard contains file items, not text). In that case,handlePaste()inattachments.tsdetectskind === "file"items inclipboardData.itemsand converts them to attachments.Why Ctrl+Shift+V Behavior Is Inconsistent
When running opencode in Windows Terminal with PowerShell, Ctrl+Shift+V still goes through bracketed paste, triggering file detection and consuming the path. On Linux, GNOME Terminal may intercept Ctrl+Shift+V and injects text as individual keystrokes, bypassing file detection. This is terminal-level behavior and unreliable across platforms.
Proposed Approach
TUI-only fix. Add a new
Ctrl+Alt+Vkeybinding (avoidingCtrl+Shift+Vdue to inconsistent terminal interception) that pastes clipboard text without file path detection or content embedding. A newprompt.paste-plaincommand would read clipboard text and insert it directly viainput.insertText(), bypassingpastedFilepath()/readLocalAttachment().The Desktop app is left for now — plain text path pasting works correctly there, and what users expect when copying actual files can be discussed separately.
If this direction looks good, I'll open a PR for the TUI side.
coinwh commentedon Jun 26, 2026
YEEE!!!
ametel01 commentedon Jun 26, 2026
I would like to work on this.
My proposed scope is a small TUI-only fix: add an explicit plain-text paste command/keybinding that reads clipboard text and inserts it directly into the prompt, bypassing the current local-file attachment detection path. I would leave the existing Ctrl+V behavior unchanged, and likely use a separate default such as Ctrl+Alt+V because Ctrl+Shift+V is intercepted inconsistently by terminals.
I would not change Desktop behavior in the same PR unless maintainers prefer that, since pasting actual file clipboard items as attachments appears to be separate from pasting a plain text path.
immortalt commentedon Jul 24, 2026
I meet the same issue. This should be considered as a BUG.
We should at least have a configuration option to disable this feature.
By default, I would prefer this feature to be disabled.
coinwh commentedon Jul 25, 2026
Absolutely and why hasn't such an obvious flaw been fixed yet
pingg02 commentedon Jul 29, 2026
I reproduced this on the current
devbranch (e8b09927889ba4b5b7fc74bbab5b864d205406ca) on Windows.The TUI path is still:
onPaste->pasteInputText()->pastedFilepath()->readLocalAttachment()->pasteAttachment().For a valid local PNG/JPG/PDF path, the file is read from disk, converted to base64, and stored as a
FilePart; the literal path is not inserted as text. If the selected model does not support the corresponding modality,ProviderTransform.unsupportedParts()later replaces the attachment with an error message, so the model still never sees the path itself.I also checked the related work:
prompt.paste_plain/ Ctrl+Alt+V, but it was closed by automated PR cleanup and was not merged.experimental.disable_paste_attachment, but there is no linked implementation and that option is not present on currentdev.Would maintainers prefer a small explicit plain-text paste command/keybinding (reviving the scope of #34123), or a persistent TUI/config toggle that bypasses local-path attachment detection? For the toggle approach, I can keep user preference separate from model capability: attach only when enabled and the selected model supports that MIME type; otherwise insert the path verbatim.
I can work on the preferred scope and include focused tests for Windows paths, quoted paths, PNG/JPG, and PDF.
thanh-abaii commentedon Aug 14, 2026
Same issue here.
Environment: Windows 11, opencode 1.18.18 (VS Code extension + Windows Terminal).
I use "Copy as path" then paste into the prompt, and it's immediately converted to [image 1] instead of the text path. My model doesn't support image input, so I have no way to reference the file path as text.
Please add an option to paste a file path as plain text.
morningD commentedon Aug 24, 2026
+1 — Hitting this daily: valid local file paths get auto-materialized as attachments, so non-multimodal contexts never receive the path text. The proposed Ctrl+Alt+V plain-text paste (or a config toggle to disable auto-attach on paste) would fully solve it. Still reproducible on v1.18.21, macOS + Ghostty.
neriousy commentedon Oct 1, 2026
Closing as a duplicate of #19892, which tracks pasted file paths always becoming attachments with no way to paste them as plain text. Please add your Desktop vs Terminal details and 👍 there.