File drag-and-drop into Pi TUI is interpreted as a slash command

[allcounter]

Bug

When dragging a file (e.g. a screenshot from Desktop) into the Pi input field, the file path is interpreted as a slash command:

Error: Unknown command: /Users/name/Desktop/WireView Screenshot 2026-04-03 at 14.53.49.png
Type /help for available commands.

Expected behavior

The file path should either:

1. Attach the file (image) to the current message, or
2. Insert the path as plain text in the input field

It should not be parsed as a /command.

Context: this worked in GSD v1

In GSD v1 (Claude Code), drag-and-drop of images into Warp terminal worked — the image was attached to the message. This was a frequently used workflow: take a screenshot on iPhone → WireView mirrors it to Desktop → drag into CC → visual context for the agent.

The main friction was that screenshots are large in context (macOS Retina PNGs). I built a Raycast Script Command (compress-clipboard.raycast.sh) that:

1. Exports clipboard image
2. Converts PNG/HEIF → real JPEG (quality 80)
3. Downscales to max 1568px (Claude API's internal resize limit — anything above is wasted tokens)
4. Puts compressed JPEG back on clipboard

This gave ~70% filesize reduction and up to 75% token savings. But it only works for clipboard paste, not drag-and-drop. Never fully cracked the drag-and-drop compression pipeline.

Also broken: screenshot to clipboard paste

Copying a screenshot to clipboard on macOS (Cmd+Ctrl+Shift+4) and pasting into Pi with either Cmd+V or Ctrl+V doesn't work — the image is not recognized as an attachment. In GSD v1/Claude Code this worked (after the Raycast compression step).

Bonus feature request: It would be great if Pi could:

• Accept drag-and-drop files (especially images) as message attachments
• Accept pasted clipboard images (Cmd+V or Ctrl+V after screenshot-to-clipboard)
• Optionally auto-compress images before sending (downscale to 1568px, JPEG q80) to save context tokens
• This was the gsd command is an existing built-in alias for git svn dcommit #1 workflow improvement I wanted in GSD v1 but never fully solved

Repro

1. Take a screenshot or have any file on Desktop
2. Drag-and-drop it into the Pi TUI input → Error: Unknown command
3. Or: Cmd+Ctrl+Shift+4 → select area → Cmd+V or Ctrl+V in Pi → nothing happens

Environment

• Pi installed via npm (gsd-pi)
• macOS Sequoia
• Terminal: Warp
• Files with paths starting with / trigger the drag-drop issue

[mackinleysmith]

I'm experiencing this as well, also in macOS with Warp terminal.

[allcounter]

Updated issue with additional details:

• Clipboard paste (both Cmd+V and Ctrl+V) also doesn't work for images
• Added context about GSD v1 where this worked
• Added info about a Raycast compression script workaround (1568px downscale + JPEG q80 = 70% size reduction)
• Bonus feature request: auto-compress images on attach to save context tokens

[FrankThonig6]

Additional trigger for the observed issue

Typing a prompt that starts with an absolute path triggers the same error.

Steps to reproduce

1. Start a gsd session
2. Type a prompt beginning with a valid absolute file path, e.g. /valid/path
3. Press Enter

Result: Unknown command: /valid/path — input is cleared, LLM never receives the message.

Root cause

The isKnownSlashCommand guard blocks the input before session.prompt() is called. It rejects any prompt whose first token begins with a forward slash and is not one of the following:

• A builtin command
• An extension command
• A prompt template
• A skill:* token

A filesystem path matches none of these. The guard is present in these locations:

• controllers/input-controller.js — main submit path (Enter)
• interactive-mode.js → handleFollowUp() — Alt+Enter
• interactive-mode.js → queueCompactionMessage() — input during compaction

[NilsR0711]

Relationship to PR #2926

PR #2926 ("Show [Image #N] placeholder instead of file path when pasting images") partially addresses the image drag-and-drop case from this issue, though not intentionally — it's a side effect of the image detection it adds to handlePaste() in editor.ts:

private static readonly IMAGE_EXTENSIONS = /\.(png|jpe?g|gif|webp|bmp|tiff?|svg|heic|heif|avif)$/i;

private handlePaste(pastedText: string): void {
    const trimmed = pastedText.trim();
    if (this.onPasteImagePath && \!trimmed.includes("\n") && Editor.IMAGE_EXTENSIONS.test(trimmed)) {
        this.onPasteImagePath(trimmed);
        return; // ← intercepted before slash-command handling
    }
    // ...
}

For a dragged .png or .jpg file this would work. For everything else (.pdf, .txt, .zip, etc.) the path would still fall through — and in the current codebase it ends up sent as a plain text prompt to the model rather than showing the "Unknown command" error (which I think was from an older version).

What's still missing after #2926:

1. Non-image file drag-and-drop still inserts the raw path as text and sends it to the model on submit
2. There's no feedback to the user that a non-supported file type was dropped

Suggested follow-up after #2926 merges:

Extend the path interception in editor.ts to cover all absolute paths, not just image extensions. For non-image files, insert the path as plain text (making the behavior explicit and avoiding the slash-command confusion), or show a warning. The handlePastedImagePath callback in interactive-mode.ts already has a graceful fallback for unreadable files — that pattern could be extended.

The image attachment infrastructure from #2926 would be in place, so a follow-up PR touching only 2-3 lines in editor.ts should close this cleanly.