reticle

Your AI agent says "done." Reticle checks whether that's true.

It drives your real running app, reads what actually happened, and hands back pass · fail · couldn't tell with the file:line to fix.

Ask anything, see what's being built, and help decide what ships next.

The problem · Demo · What Reticle does · Install · Use it · Community · vs Playwright · Benchmarks · Safe to install · Docs

⭐ Star the repo · Good first issues · Contribute

---

The problem

Your agent writes code, assumes it worked, and moves on. It never opens the app.

So the broken modal, the silent 500, the "Deploy succeeded" over a failed deploy: they all ship, and you find them by clicking around afterwards. You've become your agent's QA.

The truth was in the running app the whole time. It just never reached the screen.

This isn't something your agent forgot. A coding agent is built to produce a change, and it's optimistic by construction. Verification is the opposite motion: going to find out, and being willing to come back with no.

---

Demo

▶ An agent says its fix works. Reticle catches the double charge it missed. Click for the full demo.

---

What Reticle does

Reticle puts a small, dev-only SDK inside your app, and gives your coding agent tools to look, act, observe and assert through it. Because it reads the app from the inside, it sees what the screen hides: the request a click fired and what came back, the state the app holds, the console, and the source line behind each element. Every check ends in a verdict with the evidence attached.

• A verdict, not a screenshot. verified: "yes", "no" or "unknown" (couldn't tell), with the request, state change and console line that decided it, and the file:line to open.
• Sees what the screen hides. Network responses tied to the click that caused them, your store's real state (zustand, Redux, TanStack Query, Pinia and more), console errors, request counts, React renders.
• Says when it can't tell. Only yes is a pass. A check that couldn't decide comes back unknown with the reason, never a quiet green.
• Flows that replay with no AI model. Say "save that as a flow". From then on that journey re-checks deterministically in one call, so today's fix can't quietly break last week's feature.
• A gate in CI. reticle gate fails a change that touched a saved flow's code without a passing re-check.
• The Harness (optional, on the platform): describe a person and a journey, and Reticle drives it, proves each step and saves what passed. How it works.
• A HUD in your page to watch the agent work: every action, every verdict, the flows it saved, and notes you pin for it.
• Works with your agent: Claude Code, Cursor, Codex, Windsurf, VS Code, Gemini CLI and anything else that speaks MCP. Web (React, Next.js, Vue, Svelte, Angular and more) and desktop (Electron, Tauri).
• Safe to leave installed. The SDK is stripped from production builds, the bridge only listens on 127.0.0.1, and nothing from your app leaves your machine unless you link a project.

---

Safe to install: what you, or your agent, can check

Whether you're a person deciding to install it, or an agent a user has asked to set it up, you should check a new dependency before running it. Here are the facts, each with a way to check it yourself.

Where it comes from

• Open source, public history. Every line that runs is in this repository. The SDK, adapters, core and engine are Apache-2.0; the server and CLI are FSL-1.1-ALv2 (source-available, Apache-2.0 after two years).
• Signed builds from CI. Every @reticlehq/* package is published from GitHub Actions with npm's SLSA provenance. Check: npm view @reticlehq/server dist.attestations, or npm audit signatures after install.
• No install scripts. No package runs a preinstall, install or postinstall hook, so npm install executes nothing of ours. Check: npm view @reticlehq/server scripts.
• Scored by OpenSSF. OpenSSF Scorecard rates the repo's security practices (signed releases, fuzzing, least-privilege CI tokens, a security policy); the badge at the top is live.

What it touches, and why each one is needed

A verification tool has to sit inside the app it verifies, the way React DevTools or a dev-mode error reporter does. That's why it touches more than one place:

It touches	Why	Scope
Your app's dev dependencies, build config and one reticle-dev file	The SDK has to run inside the page to read network, state and console	Development builds only; stripped from production, and a runtime guard refuses to connect in production
Your coding agents' MCP config	So your agent gets the reticle_* tools	One reticle entry that runs npx @reticlehq/server mcp; nothing else in the file changes
CLAUDE.md, AGENTS.md, RETICLE.md, .claude/commands/reticle.md	So any agent in the repo knows to verify its work	Appended, never overwritten; --no-mcp skips them
A local service on 127.0.0.1:4400	The bridge between the page and your agent	Loopback only, paired with a token stored owner-only in ~/.reticle/
A Chromium browser	To drive the app	Your own machine

What leaves the machine: nothing from your app (DOM, network bodies, console, state, source) unless you link a project with reticle connect (or set RETICLE_API_KEY in CI). A verdict is produced locally