Skip to content

[BUG][Desktop vs Terminal] Pasting local file path has inconsistent behavior and no way to paste as plain text #34006

Closed as duplicate

Description

@coinwh

Description

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).

Activity

  1. dsy122 commented on Jun 26, 2026

    @dsy122

    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.

  2. coinwh commented on Jun 26, 2026

    @coinwh
    Author

    YEEE!!!

  3. ametel01 commented on Jun 26, 2026

    @ametel01

    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.

  4. immortalt commented on Jul 24, 2026

    @immortalt

    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.

  5. coinwh commented on Jul 25, 2026

    @coinwh
    Author

    Absolutely and why hasn't such an obvious flaw been fixed yet

  6. pingg02 commented on Jul 29, 2026

    @pingg02

    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.

    I also checked the related work:

    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.

  7. thanh-abaii commented on Aug 14, 2026

    @thanh-abaii

    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.

  8. morningD commented on Aug 24, 2026

    @morningD

    +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.

  9. neriousy commented on Oct 1, 2026

    @neriousy
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions