jberthom

Thanks! Yeah Claude Code’s native browser is getting better. ProofShot is agent-agnostic though — works with Cursor, Codex, any agent that can run shell commands. And the proof bundle you get at the end (viewer.html with video + timeline + errors) is what I actually review, not the raw screenshots.

yep adding soon, agree it is the most recurring question

Thanks! Web only for now, runs headless Chromium. Desktop is the #1 request, likely through accessibility APIs or OS-level screenshots. On the roadmap.

Web only for now since it runs headless Chromium. For Flutter web builds it’d work, but native Flutter apps would need emulator integration which is on the roadmap. Feel free to open an issue on the repo.

Fair point, clearly the first question everyone has. Will add a comparison section to the README.

ProofShot isn’t a Playwright alternative, it’s built on agent-browser (from Vercel Labs), which is a different runtime. The value isn’t “can control a browser” — playwright does that fine, and in fact agent-browser is built on top of Playwright, hence so is ProofShot :) The value is bundling video + screenshots + console errors + server logs + action timeline into a single viewer.html and uploading it to the PR. That’s what saves me review time. If your workflow doesn’t need that bundle, playwright-cli works great.

Web only for now. It runs headless Chromium under the hood. Desktop and mobile are the #1 request. Mobile path would be iOS Simulator or Android emulator integration. Desktop would need accessibility APIs or OS-level screenshot capture. It’s on the roadmap. Feel free to leave an issue on the repo if that's critical for you

Right now agent-browser launches a fresh Chromium instance each time, so no persisted auth. For apps behind login, you’d need to either hit a page that doesn’t require auth, or script the login as part of your proofshot exec steps (type email, type password, click submit). Cookie/session injection is something I want to add, would make the auth flow much smoother for sure.

interesting, which model were you using for the vision part? In my experience Claude Sonnet and Opus handle UI screenshots reasonably well, not perfect but good enough that the agent can catch obvious layout issues and iterate. Definitely not at the “pixel perfect design implementation” stage yet though. But for testing features it's ok. The goal is for the agent to test that the UX/UI flow works, not that one pixel is correctly aligned with others in that case

agent-browser runs locally (it’s a Rust CLI + Node daemon on your machine), so there’s no cloud dependency on Vercel, it’s just built by the Vercel Labs team. Everything stays local :)

Simon’s tools are really great. Showboat is more for static screenshots though. ProofShot is the full session: recording, error capture, action timeline, PR upload. Different scope i'd say.

The agent drives interactions through proofshot exec — clicks, typing, navigation and each action gets logged with timestamps synced to the video. So in the viewer you can scrub through and click on action markers to jump to specific moments. It captures what happened during interaction, not just what the page looked like at rest. I had recordings where the agent struggled (for instance when having to click toggle buttons). It was fascinating to watch, the agent just tried again and again like a toddler figuring out how to use a keyboard and after 3 tries figured it out on his/her own (trying not to misgender the babies of future AGI).

ah feel your pain.. Codex interaction is exactly the pain point. “I fixed it” / “no you didn’t” five times in a row, you feel gaslighted by your own agent in a way. That’s the loop I wanted to kill. I didnt' know about Mozilla screenshot regression actually

Thanks! Yeah the before/after PR thing is exactly what proofshot pr is built for.

DevTools MCP is great for live debugging in the moment. ProofShot is more about generating a proof bundle after the fact, something you can review on a PR without having been there when the agent ran. Different use cases I think.

yes as saintfire said :)

ProofShot is just a CLI, not tied to any IDE. If you’re in Antigravity or VSCode and their built-in preview works for you, great. This is for people using Claude Code, Codex, or any terminal-based agent where there’s no IDE doing it for you. The main thing is really the PR artifact workflow - the agent records proof, you review it async on the PR.

Yes for now focused on web but accessibility tree dumps seems like a good alternative to screenshots for native apps. For web, agent-browser already uses compact element refs, but for mobile the a11y approach could be way more efficient. Would you be open to sharing more about how you set that up?

Yes agree. Web only for now since it runs on headless Chromium. Desktop and mobile are the #1 request though. For mobile the path would be driving an iOS Simulator or Android emulator. For native desktop, probably accessibility APIs or OS-level screenshots. Definitely on my radar, will see if anyone wants to contribute since I am doing this on my free time.

Yes agent-video is focused on high quality recording. ProofShot uses agent-browser’s recording under the hood but the value is really in everything else: error collection, server log capture, the interactive viewer with synced timeline, and the PR upload. It’s less about the video itself and more about bundling all the evidence together to generate the evidence the agent did the work.

ProofShot sits on top of agent-browser. agent-browser gives you the browser primitives (click, navigate, screenshot). ProofShot adds the session stuff: starts recording, pipes your server logs, collects console errors with pattern matching for 10+ languages, trims the video, syncs timestamps, and bundles it all into a standalone viewer HTML. There’s also proofshot pr which uploads everything to a GitHub PR comment. So it’s not an alternative tool, it's a layer on top of it :)

Maker here. Playwright is great, I use it too. The difference is really about who’s driving. ProofShot is meant for agents that just need shell commands, start to open the browser and begin recording, exec to interact with the page, stop to bundle everything up. You get video, screenshots, console errors, server logs, and an interactive HTML viewer in one artifacts folder you can drop on a PR with proofshot pr. With Playwright the agent needs to write a test script, run it, collect screenshots, parse output separately… it’s a lot of glue code. Also agent-browser’s element references are ~93% smaller than Playwright’s accessibility tree, which adds up when you’re paying per token.

Yes exactly. I'm actively maintaining it so if you miss anything just drop an issue on Github and I'll look into it

This is the first time I hear of this case as I think few people create distinct applications. We use Auth0 for authentication and we'll check with them as it seems the issue is on their side. I'll let you know when we've figured it out.

Yes we didn't dedicate efforts to integrating an ad blocker because we mostly integrate applications in which you shouldn't see ads but Twitter or Instagram are good examples of where it's needed. We are working hard to integrate more extensions in the future and Ad blockers rank high on the list.

Franz is all about handling messaging app while we handle all types of web applications. As for Rambox, indeed they are closer to what we do with a different type of interface though.

We do support self-hosted apps (any kind of custom apps) but as of today it requires a few weeks before it is added. In all honesty if that's a key factor for you, I would stay on Rambox and wait for us to have released the V.2 of custom applications before bothering to try it :)

Indeed PWA would be amazing especially for offline functionalities and push notifications.

1. Indeed we've removed it as it really made the interface distracting (with numbers on every app). We could imagine having this information on hover on the next version of the dock. We just want to make sure we don't make the dock too messy with information (once you add up notification number, profile icon, etc.) it starts looking really overwhelming.

2. Good point, that's something we'll keep in mind once we start focusing on notifications again.

Thanks for the feedback. We plan on insisting on the "Free" aspect on the V.2 of our website so it's clear that it is free for the individual user. Once we price for teams we'll have a dedicated page.

Thanks for your feedbacks! On some of your points: - we do allow you to use multiple Gmail accounts, back when you used it it might not have been obvious enough but you can use as many Google accounts as you'd like - indeed we are working hard on memory usage and performance at the moment. Since the TechCrunch cover you should definitely see a difference. Let us know in our community if this is not the case - we've fixed that since then, you can remove autostart in the settings and it works now

Front app is a centralized interface to access your various inboxes. Station unifies all of your web applications (e-mail, chat, tasks, notes etc.) in one single app. Front is closer to being an e-mail client handling various inboxed but in the cloud (and collaborative) while were are a better alternative to the browser for all your web applications. You could use Front in Station :)

We get Chromium updates when we upgrade to a new version of Electron. We rely on Electron integrating the new version (typically there is always a delay) to be up to date.