Today, attaching an image means picking a pre-existing file (or using a separate OS screenshot → save/copy → paste/drag/@path flow). I’d like the Image import control to also offer a capture path: either an embedded screenshot tool, or a one-click handoff to the OS native snipping tool, with the result attached directly as image context.
Problem
When I’m debugging UI, logs, or desktop/app behavior, the visual I need usually doesn’t exist as a file yet. The current loop is:
Leave Cursor / switch focus
Run the OS screenshot tool (e.g. macOS Cmd+Shift+4 / Cmd+Ctrl+Shift+4, Windows Win+Shift+S)
Save a file or copy to clipboard
Come back and paste, drag-drop, or @path the image
That adds friction and fails more often than file-pick (clipboard paste gaps, drag-drop quirks in some layouts, desktop screenshot clutter). The Image button only covers “import what I already have,” not “capture what I’m looking at now.”
Proposed solution
Extend the Image import UI with a second action, e.g.:
Upload / Choose file (existing)
Take screenshot (new)
Preferred behavior for Take screenshot:
User clicks Image → Take screenshot (or a dedicated capture affordance next to it)
Cursor either:
A) Opens a built-in region/window/fullscreen capture UI, or
B) Invokes the OS native snipping tool (preferred if simpler / more familiar)
On capture complete, the image is attached to the current prompt the same way a file import would — no manual paste/drag/@path step
User can still cancel without attaching anything
Scope I’d value most:
Cursor Agent CLI Image import (primary)
IDE Agent / Composer chat image attach (same UX if possible)
The capture path would kill real friction, the save/copy/paste/@pathpath dance is genuinely annoying.
One thing it won’t fix: whatever gets captured still gets resized before the model reads it. On a tall screenshot that’s brutal, I measured one going from 3066x28800 to 276x2600 on the way in. So built-in capture is better UX, but the image is still the lossy part.
What survives is the text and element positions sent as text. Might be worth the capture path emitting that alongside the pixels, not just the image.
Instead of downscaling the whole canvas to one tiny image tile it, and give the model a layout map.
How it could work
User captures (or selects) a large region as usual.
Before attach, Cursor slices that image into ordered high-res tiles (rows for tall shots, a grid for wide ones), ideally with a little overlap so text/UI isn’t bisected on a cut.
Each tile is attached as its own image at a size that stays readable under the normal per-image limit.
Alongside the tiles, Cursor injects a short stitching/layout context in text, e.g.:
original dimensions
tile grid (e.g. 1×11, top→bottom)
tile size + overlap
reading order / coordinates so tile N is known to sit directly under tile N−1
The model doesn’t need to literally reassemble pixels. It needs enough structure to treat the set as one screenshot: “this error is in tile 3; the button above it is in tile 2.”
Why this is better than one compressed image
Local detail survives. Text and small controls stay sharp inside each tile.
Global structure survives in text. The layout map is cheap, lossless, and doesn’t depend on the vision resize path.
Fits the existing multi-image attach path in chat/CLI better than inventing a new image format.
Pairs well with your point about text/element positions. Tiles preserve pixels; the map (and, where available, DOM/a11y labels + boxes) preserves meaning when pixels still aren’t enough.
You’ve basically spec’d what I ended up building, overlap-so-text-isn’t-cut included. One thing from actually shipping it: cut at the quietest horizontal row, a band of near-uniform pixels, instead of a fixed height. The seam lands between rows of content instead of through one. Fixed-height tiles bisect text about half the time.
For the layout map, normalized coordinates per tile (0 to 1 over the full height) plus each tile’s pixel offset is enough for the model to say “error is in tile 3, the button above it is in tile 2” without reassembling anything.
I do this in a Mac capture tool (slimsnap.ai) and the JSON is an open MIT schema (github.com/bickov/slimsnap-schema). If Cursor builds this, adopting an existing open schema beats inventing a format, since then the same capture works across Cursor, Claude Code, Codex instead of being Cursor-only.