Iris Is a Camera for Coding Agents, and the Waiting Is the Hard Part
Watch on TikTok
A coding agent that cannot see the page it just built is guessing, and Iris closes that gap with a single command that returns one trustworthy image. The video is a 39-second slow scroll through the GitHub README for brijr/iris in Chrome. It lingers on the hero card, which reads "A fast screenshot tool for coding agents, written in Rust, CLI + MCP," then on the usage block, then on a full-page capture of bridger.to produced by iris --full. The tool is small. What makes it worth attention is not the screenshot, it is everything Iris does before pressing the shutter.
One Command, One Image
The README opens with eight example invocations and no prose, which is a reasonable way to describe a tool this narrow. iris example.com writes example.com.png at 1440x900 at 2x. iris --size iphone stripe.com renders at 390x844 at 3x with a mobile user agent. iris --selector '#hero' --padding 24 app.dev crops to the first matching element with tight framing. Batch mode takes several URLs or reads them from stdin, captures them concurrently in one browser process, and derives filenames from the URLs. A failed URL prints an X and never kills the batch, though the run exits 1 if anything failed.
Installation is a curl pipe to install.sh, or cargo install iris-screenshot if you have a Rust toolchain. The crate name and the command name differ, which is worth knowing before you go looking for a binary called iris-screenshot. The only runtime dependency is a Chrome-family browser you already have installed. Iris drives it over the DevTools Protocol rather than shipping its own headless runtime.
The Waits Are the Actual Product
Anyone can call the Chrome DevTools screenshot API. The reason that approach produces garbage is timing. A naive capture fires while webfonts are still swapping, hero images are still decoding, and entrance animations are mid-transition, so you get a picture of a page that never existed for a real user.
Iris waits for fonts, image loads, and entrance animations before it captures. On --full it scrolls the page first to trigger lazy-loaded content, then returns to capture. With --selector it scrolls the target element into view and lets newly visible content settle before framing it. Those behaviors are the difference between a screenshot tool and a reliable one, and they are the part a developer would otherwise rebuild badly in a Puppeteer script with a hardcoded sleep(2000).
Retina output is the default at 2x. Full pages taller than Chrome's roughly 16,000 pixel render limit fall back to 1x automatically, and the capture report tells you which one you got. That last clause matters more than it looks: a silent quality downgrade in an automated pipeline is a bug you find three weeks later.
The MCP Server Is Why Agents Care
The same binary serves a local stdio MCP server. codex mcp add iris -- iris mcp registers it, or you point any MCP client at command iris with args ["mcp"]. It exposes exactly one tool, capture, taking a URL plus optional selector, padding, size, dark mode, format, and timeout.
Two design choices make it work for agents specifically. First, capture returns the image inline with structured metadata, so the agent receives pixels in its context rather than a file path it then has to go read. Second, it writes nothing to disk unless you pass output, which keeps an agent's exploratory captures from littering the working tree. Bare localhost, .localhost, and loopback addresses resolve over HTTP automatically while other bare hosts use HTTPS, so pointing an agent at its own dev server does not require typing a scheme.
There is also a performance reason to prefer the MCP path in a loop. The CLI starts a fresh Chrome process per invocation, while the MCP server keeps one alive for its lifetime. The README's reference numbers on an M2 Max put the one-shot CLI at about 1.00 second median and subsequent MCP captures at 366 milliseconds median. Those are the author's own measurements on a local fixture, published with the exact hardware, Chrome version, and command, which is a more honest way to report benchmarks than most projects manage.
The Limits Are Stated Up Front
Iris captures the first CSS selector match in document order. Capturing every match is not supported, and neither are cross-origin iframe contents. --selector conflicts with --full, and --padding requires a selector. Browser interaction scripting, visual diffs, and review workflows are all declared out of scope in the README rather than listed as roadmap items.
That restraint is the interesting call. The obvious next features for a screenshot tool are diffing and a review UI, and refusing them keeps Iris something an agent can call without learning a workflow. The tool does one verb. Everything else stays in the agent's hands.
Where It Actually Stands
The README includes a setup prompt written for the agent rather than the human, instructing it to install Iris, register the MCP server, run a CLI smoke test, and then separately prove the MCP path works. It explicitly warns the agent not to claim MCP success from the CLI test alone, which suggests the author watched an agent do exactly that.
Be realistic about maturity. As of September 2026 the repository sits at 347 stars with 17 forks, first commit in mid-August 2026, latest release v0.4.1 on August 18, and roughly 100 downloads on crates.io. It is MIT licensed, written in Rust, and requires Rust 1.88 or newer to build from source. This is a well-designed month-old project, not a dependency with a track record.
Key Takeaways
- The value in a screenshot tool for agents is the waiting logic, not the capture call. Fonts, image decode, entrance animations, and lazy-load scroll triggers are what separate a usable image from a picture of a half-rendered page.
- Returning the image inline through MCP instead of writing a file and handing back a path removes a step the agent would otherwise have to get right, and skipping disk writes by default keeps the repo clean.
- Keep one Chrome process alive if you are capturing in a loop. The published gap between CLI one-shot and warm MCP capture is roughly 1.00 second versus 366 milliseconds median.
- Automatic quality fallbacks should be reported, not silent. Iris dropping to 1x above Chrome's 16k pixel limit is fine because the capture report says so.
- Declaring diffs, interaction scripting, and review workflows out of scope is what keeps the tool callable without a workflow to learn.
- Version 0.4.1 at 347 stars and about a month old. Worth trying in a local agent loop, worth pinning before anything depends on it.
Resources
- brijr/iris - the repository, Rust, MIT licensed
- iris-screenshot on crates.io - the published crate, installs the
iriscommand - install.sh - the script behind the curl install line
- Model Context Protocol - the standard behind
iris mcpand thecapturetool - Chrome DevTools Protocol - how Iris drives your installed browser
- hyperfine - the benchmarking tool the README uses for reproducible CLI timings
Published September 12, 2026. Writeup generated from a favorited TikTok.