[FEATURE]: Drag-and-drop external files should offer Insert Path mode — reference files by path instead of inlining content #31939

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

I'm aware of related issues and PRs:

• Drag-dropped images lose absolute file path, preventing tools from accessing them #17488 — drag-dropped images lose their path (bug)
• Pasted images lose their original file path #23801 — pasted images don't carry their path (bug)
• Drag and Drop assets should be also dropped as path, not only as binary #25391 — requested path+binary dual-mode for drag-drop, but was closed as not planned
• feat(tui): improve clipboard paste and drag-and-drop file handling on Linux #14552 — improved Linux TUI drag-drop handling
• feat(app): drag-n-drop to @mention file #12569 — drag-n-drop to @mention file from file tree

This request is different from all of the above. The existing issues treat path preservation as a bug (it was lost accidentally). This request treats it as a first-class feature: for non-image files especially, inserting the path is often more useful than attaching the content, because the agent can read the file on demand via its tools.

Problem

When I drag a file from my desktop (Finder / Explorer / Nautilus) into the OpenCode prompt, the current behavior depends on the file type:

In all cases, the file path — which is the most compact and useful reference — is either lost or never inserted in the first place.

This is a workflow problem, not just a bug. OpenCode agents have Read, Grep, and file access tools. For most interactions, I want the agent to know where the file is so it can read it on demand, not have the entire content dumped into the chat.

Example scenario: I'm working with a 500-line config file on my desktop. I drag it into OpenCode. Instead of pasting the path /Users/me/Desktop/settings.yaml so the agent can Read it, the current behavior either:

• embeds the entire 500 lines inline (wasting context), or
• rejects it entirely ("unsupported attachment"), or
• converts it to a binary blob that loses the path entirely.

What I actually want is the path, so I can say "check this config file" and the agent reads it with its tools.

Proposed Solution

Add a "path reference" mode to drag-and-drop, toggled by a modifier key:

In "path mode", the dropped file would be inserted as a path reference (similar to @file mention), not as embedded content. This means:

1. The absolute file path is preserved — agent knows exactly where the file lives on disk
2. No content bloat — path string only, agent reads the file when needed via its tools
3. Works for any file type — .yaml, .toml, .env, .xlsx, .dll — no "unsupported attachment" rejection
4. Agent can reference the file later — "copy this file to the project", "edit line 42", etc.

The path should be inserted in a format the agent understands, e.g.:

• /Users/me/Desktop/settings.yaml — plain path that maps to Read tool
• Or as an @ mention if the file is within the project: @/path/to/file

Alternative Considered: Always insert path alongside attachment

An alternative approach: when a file is dropped, also insert a comment or metadata with the source path:

[File: settings.yaml] (source: /Users/me/Desktop/settings.yaml)

This preserves the path for reference even when the content is embedded. However, this still bloats context unnecessarily for large files. The modifier-key approach is cleaner because it gives the user control.

Why this matters

• Context efficiency: A 50-character path vs. a 500-line file — the difference is massive for the context window
• Agent capability alignment: OpenCode agents are designed to read files by path. Forcing inline content subverts this capability
• Desktop-to-agent workflow: When I drag a file from my desktop, I'm pointing the agent at the file, not feeding it the content. The path IS the semantic intent.
• Parity with @ mentions: The internal @file system already works this way — why should external files be different?

Related Issues

• Drag-dropped images lose absolute file path, preventing tools from accessing them #17488 — drag-dropped images lose absolute path
• Pasted images lose their original file path #23801 — pasted images lose path
• Drag and Drop assets should be also dropped as path, not only as binary #25391 — similar request but closed as not planned (this issue makes a stronger case with specific UX proposal)
• [FEATURE]: Desktop should accept more dropped file types in prompt input #18143 — Desktop rejects many dropped file types
• [FEATURE]:Copy File or Directory Path from File Tree - OpenCode desktop application #16019 — Copy Path from file tree (related workflow)
• feat(tui): improve clipboard paste and drag-and-drop file handling on Linux #14552 — TUI drag-drop improvements on Linux