[Bug] Image attach broken on Windows (v0.33.2): backslash unescape + darwin-gated clipboard + prefix-text breaks attach

[tardigrade1001]

Summary

On Windows, the only way to attach an image is an undocumented gesture — paste a bare forward-slash path, alone, on an empty prompt (e.g. F:/path/to/x.jpg), which registers as [Image #1]. Every other input method fails silently: the model receives the path as plain text, calls a read/shell tool, and reports file metadata instead of seeing the image. Vision itself works fine on the Go plan once an image actually attaches — the problem is purely the attach pipeline on Windows.

Heads-up: I dug into the installed dist/index.mjs and ran a few isolated repros to pin down the line-level causes below (used Claude to help read through the bundle).

Expected Behavior

Standard Windows image-attach gestures should attach the image (register as [Image #N]) so a vision-capable model can see it:

• Drag-dropping an image file into the terminal
• Pasting a Windows path (C:\Users\me\x.jpg)
• A bare path plus a question on the same line ("describe this. F:/x.jpg")
• Ctrl+V of a clipboard image (e.g. a Win+Shift+S snip)

Actual Behavior

Only one gesture works: pasting a bare forward-slash path, alone, on an empty prompt. Everything else fails silently (path is treated as text → model reports metadata):

• Drag-drop a file → produces a backslash path → not attached
• Typed/pasted Windows C:\...\x.jpg → not attached
• "Sentence + path" on one line → not attached
• Ctrl+V a clipboard image (Win+Shift+S snip) → not attached
• Ask the agent to read the file → Read tool returns binary metadata, never an image block

Root cause (from the v0.33.2 bundle):

Bug 1 — backslash path mangling (main one). detectDroppedImageFile() runs:

t = t.replace(/\\(.)/g, "$1");

Correct for macOS/Linux shell-escaped drag-drop, but on Windows it deletes every \ separator: C:\Users\uddip\Pictures\image_0.jpg → C:UsersuddipPicturesimage_0.jpg → existsSync() false → no attachment.
Fix: if (process.platform !== "win32") t = t.replace(/\\(.)/g, "$1"); (or only unescape \ space-escapes — cross-platform safe).

Bug 2 — clipboard image handler is macOS-gated. The Ctrl/Cmd+V clipboard-image path is gated on "darwin" === process.platform, so pasting an image (not a path) never attaches on Windows.
Fix: ungate for win32 — the installed @crosscopy/clipboard hasImage()/getImageBase64() is already cross-platform.

Bug 3 — whole-buffer path check (minor UX). detectDroppedImageFile() treats the entire pasted buffer as the candidate path, so any prefix text breaks existsSync(). This is why a bare path works but "sentence + path" doesn't.

Both fixes verified locally by patching the bundle: after skipping the unescape on win32, a dragged / \-path image attaches; after adding a win32 clipboard branch, Win+Shift+S → Ctrl+V attaches a snip — and plain text paste still works.

Steps to reproduce the issue

1. On Windows, launch Command Code (cmdc; note the cmd alias is shadowed by Windows' own cmd.exe).
2. Drag an image into the terminal, OR paste a Windows path C:\Users\me\pic.jpg, OR Ctrl+V a clipboard screenshot, then ask "describe this image."
3. Observe: no [Image #N] attaches; the model reports file size/metadata or says it received no image.
4. Now paste only a bare forward-slash path on an empty prompt (C:/Users/me/pic.jpg), press enter, then ask "describe this image" — it attaches as [Image #1] and the model describes it correctly.

Command Code Version

0.33.2

Operating System

Windows

Terminal/IDE

Windows Terminal (PowerShell)

Shell

PowerShell

Additional context

• Env: Command Code v0.33.2 · Windows 11 (10.0.26100) · Node v24.14.0 · Go plan (tardigrade1001).