I use AI agents to build UI features daily. The thing that kept annoying me: the agent writes code but never sees what it actually looks like in the browser. It can’t tell if the layout is broken or if the console is throwing errors.

So I built a CLI that lets the agent open a browser, interact with the page, record what happens, and collect any errors. Then it bundles everything — video, screenshots, logs — into a self-contained HTML file I can review in seconds.

proofshot start --run "npm run dev" --port 3000 # agent navigates, clicks, takes screenshots proofshot stop

It works with whatever agent you use (Claude Code, Cursor, Codex, etc.) — it’s just shell commands. It's packaged as a skill so your AI coding agent knows exactly how it works. It's built on agent-browser from Vercel Labs which is far better and faster than Playwright MCP.

It’s not a testing framework. The agent doesn’t decide pass/fail. It just gives me the evidence so I don’t have to open the browser myself every time.

Open source and completely free.

https://github.com/AmElmo/proofshot

  • Imustaskforhelp an hour ago |
    Great to see this but exe.dev (not sponsored but they are pretty cool and I use them quite often, if they wish to sponsor me that would be awesome haha :-]) actually has this functionality natively built in.

    but its great to see some other open source alternatives within this space as well.

  • Horos an hour ago |
    what about mcp cdp ?

    my claude drive his own brave autonomously, even for ui ?

  • VadimPR an hour ago |
    Looks nice! Does it work for desktop applications as well, or is this only web dev?
  • zkmon an hour ago |
    Taking screenshots and recording is not quite the same as "seeing". A camera doesn't see things. If the tool can identify issues and improvements to make, by analyzing the screenshot, that's I think useful.
    • jofzar an hour ago |
      > It’s not a testing framework. The agent doesn’t decide pass/fail. It just gives me the evidence so I don’t have to open the browser myself every time.

      From the OP, i don't think this is what is meant for what you are saying.

    • falcor84 37 minutes ago |
      I read it in the same vein as saying that a sub's sonar enables "seeing" its surroundings. The focus is on having a spatial sensor rather than on the qualia of how that sensation is afterwards processed/felt.
    • philipp-gayret 33 minutes ago |
      > If the tool can identify issues and improvements (...)

      Tools like Claude and the like can, and do. This is just a utility to make the process easier.

  • theshrike79 an hour ago |
    What does this do that playwright-cli doesn't?

    https://github.com/microsoft/playwright-cli

    • jofzar an hour ago |
      These aren't really comparable, OP's is something that records, captures and reproduces with steps.
      • mohsen1 35 minutes ago |
        playwright can do all of that too. I'm confused why this is necessary.

        If coding agents are given the Playwright access they can do it better actually because using Chrome Developer Tools Protocol they can interact with the browser and experiment with things without having to wait for all of this to complete before making moves. For instance I've seen Claude Code captures console messages from a running Chrome instance and uses that to debug things...

      • onion2k 21 minutes ago |
        That's exactly what Playwright does, but also something you don't really need in order to debug a problem.
  • lastdong an hour ago |
    This is basically what antigravity (Google’s Windsurf) ships with. Having more options to add this functionality to Open code / Claude code for local models is really awesome. MIT license too!
  • can16358p an hour ago |
    How would this play with mobile apps?

    I'd love to see an agent doing work, then launching app on iOS sim or Android emu to visually "use" the app to inspect whether things work as expected or not.

    • jillesvangurp 20 minutes ago |
      Something like OpenAIs agent mode where it drives a mouse and keyboard but against an emulator should be doable. That agent mode is BTW super useful for doing QA and executing elaborate test plans and reporting issues and UX problems. I've been meaning to do more with that after some impressive report I got with minimal prompting when I tried this a few months ago.

      That's very different from scripting together what is effectively a whitebox test against document ids which is what people do with things like playwright. Replacing manual QA like that could be valuable.

    • m00dy 18 minutes ago |
      try deepwalker, https://deepwalker.xyz
  • jofzar an hour ago |
    I'm going the opposite of everyone else is saying.

    This is sick OP based on what's in the document, it looks really useful when you need to quickly fix something and need to validate the changes to make sure nothing has changed in the UI/workflow except what you have asked.

    Also looks useful for PR's, have a before and after changed.

    • jillesvangurp 25 minutes ago |
      Exactly. We need more tools like this. With the right model, picking apart images and videos isn't that hard. Adding vision to your testing removes a lot of guess work from ai coding when it comes to fixing layout bugs.

      A few days ago I had a interaction with codex that roughly went as follows, "this chat window is scrolling off screen, fix", "I've fixed it", "No you didn't", "You are totally right, I'm fixing it now", "still broken", "please use a headless browser to look at the thing and then fix it", "....", "I see the problem now, I'm implementing a fix and verifying the fix with the browser", etc. This took a few tries and it eventually nailed it. And added the e2e test of course.

      I usually prompt codex with screenshots for layout issues as well. One of the nice things of their desktop app relative to the cli is that pasting screenshots works.

      A lot of our QA practices are still rooted in us checking stuff manually. We need to get ourselves out of the loop as much as possible. Tools like this make that easier.

      I think I recall Mozilla pioneering regression testing of their layout engine using screenshots about a quarter century ago. They had a lot of stuff landing in their browser that could trigger all sorts of weird regressions. If screenshots changed without good reason, that was a bug. Very simple mechanism and very effective. We can do better these days.

  • z3t4 44 minutes ago |
    I'm currently experimenting with running a web app "headless" in Node.JS by implementing some of the DOM JS functions myself. Then write mocks for keyboard input, etc. Then have the code agent run the headless client which also starts the tests. In my experience the coding agents are very bad at detecting UX issues, they can however write the tests for me if I explain what's wrong. So I'm the eye's and it's my taste, the agent writes the tests and the code.
  • onion2k 22 minutes ago |
    I use AI agents to build UI features daily. The thing that kept annoying me: the agent writes code but never sees what it actually looks like in the browser. It can’t tell if the layout is broken or if the console is throwing errors.

    I give agent either a simple browser or Playwright access to proper browsers to do this. It works quite well, to the point where I can ask Claude to debug GLSL shaders running in WebGL with it.

  • m00dy 19 minutes ago |
    Gemini on Antigravity is already doing this.
  • boomskats 17 minutes ago |
    I find the official Chrome DevTools MCP excellent for this. Lighter than Playwright, the loop is shorter, and easy to jam into Electron too.
  • alkonaut 16 minutes ago |
    This would be _extremely_ valuable for desktop dev when you don't have a DOM, no "accessibility" layer to interrogate. Think e.g. a drawing application. You want to test that after the user starts the "draw circle" command and clicks two points, there is actually a circle on the screen. No matter how many abstractions you make over your domain model, rendering you can't actually test that "the user sees a circle". You can verify your drawing contains a circle object. You can verify your renderer was told to draw a circle. But fifty things can go wrong before the user actually agrees he saw a circle (the color was set to transparent, the layer was hidden, the transform was incorrect, the renderer didn't swap buffers, ...).