Skip to content

v0.38.5 — Paste a screenshot onto an agent

Latest

Choose a tag to compare

@jpelaez-23blocks jpelaez-23blocks released this 04 Sep 23:51
2c3baa7

Closes #270, which asked for three things. The third — attachments in the messaging system — shipped in v0.38.0. These are the other two.

What was broken

navigator.clipboard.readText()   // text only

An image on the clipboard returns nothing, so pasting a screenshot produced silence — exactly as reported. Images arrive as files on the paste event and are now intercepted before xterm sees them; a text paste falls through untouched. Drag-and-drop works too, with a drop overlay.

A path, not the bytes

Agent CLIs read files from disk — Claude Code takes a path and opens it, as do Codex and Aider. Base64 into the pane would be enormous and wrong: a 1 MB screenshot becomes 1.3 MB of text typed one keystroke-batch at a time into a TUI that will mangle it.

Files land in ~/.aimaestro/uploads/<agentId>/, never the agent's working directory — that is usually a git repo someone is working in, where screenshots show up in git status, get committed by an agent tidying up, or collide with real files.

Cheap because of the rest of the week

Validation reuses lib/amp-attachments (filenames, blocked executables, magic bytes, 25 MB), and the prompt goes through sendChatMessage, which carries the bare-shell guard from v0.37.14. Without that, pasting into an agent whose program never started would type the path at a shell that would try to execute it.

Saved and announced are separate outcomes: a file can land while the agent cannot be told, and calling that success would be the same unearned claim removed everywhere else this cycle.

Verified

A real PNG posted to a live agent — byte-identical on disk, and the agent's pane shows it reading the file:

❯ I've attached a file for you at "/Users/…/uploads/70796e0d-…/shot.png" —
  ⎿  ~/.aimaestro/uploads/70796e0d-…/shot.png

An ELF binary named evil.pdf and a run.sh are both refused.


26 new tests, 1283 passing.