Feature hasn't been suggested before.
I'm aware of related issues and PRs:
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:
| File type |
Current behavior |
Problem |
| Image |
Embedded as binary [Image 1] |
Path is lost — agent can't reference or copy the original file (#17488, #23801) |
| PDF |
Embedded as binary attachment |
Path is lost — same problem |
| Text / code |
Embedded inline as content |
Path is lost, and the full content bloats the context window |
| Other formats |
Rejected ("Unsupported attachment") |
Can't use the file at all (#18143) |
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:
| Interaction |
Behavior |
| Drag + Drop (default) |
Current behavior — embed as attachment/content |
| Drag + Alt/Option + Drop |
Insert file path as a readable reference |
In "path mode", the dropped file would be inserted as a path reference (similar to @file mention), not as embedded content. This means:
- The absolute file path is preserved — agent knows exactly where the file lives on disk
- No content bloat — path string only, agent reads the file when needed via its tools
- Works for any file type — .yaml, .toml, .env, .xlsx, .dll — no "unsupported attachment" rejection
- 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
Feature hasn't been suggested before.
I'm aware of related issues and PRs:
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:
[Image 1]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.yamlso the agent canReadit, the current behavior either: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
@filemention), not as embedded content. This means:The path should be inserted in a format the agent understands, e.g.:
/Users/me/Desktop/settings.yaml— plain path that maps toReadtool@mention if the file is within the project:@/path/to/fileAlternative 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
@mentions: The internal@filesystem already works this way — why should external files be different?Related Issues