Save
opacity 0Save✓ Saved
under a toastSave
Save
off-screenControls a person can’t use
Buttons in the page but invisible, covered by a toast or a sticky header, cut off by their container, or pushed off-screen.
v0.3Claude Code & Codex plugin · MCP server · CLI
QA that tests your app like a person would
An open-source AI QA testing plugin for Claude Code and Codex. blindqa drives your web app in a real browser with Playwright — scrolling, clicking, signing in as every role — and reports the bugs your users would actually hit. After the first run, it re-tests only what your code changes touch.
> /plugin marketplace add DevZonayed/blindqa> /plugin install blindqa@blindqa
Then ask your agent: “Set up blindqa for this repo.” Node.js 20+ and git required.
Board
12 tasks · 3 due this week
New task
Open tasks
12
Due this week
3
Overdue
1
Done this month
27
Backlog 2
+
Onboarding flow
design
API docs
docs
In progress 2
+
Settings migration
backend
Contrast audit
a11y
Done 2
+
Weekly digest
email
Error tracking
infra
Due this weekAssignee · Due · Status
Invite teammates stepAdaTueIn progress
Bulk update route docsAlanWedBacklog
Rollback planKatherineThuBlocked
Archive done tasks
Task saved
blindqa crawl ADMIN · read-only · writes blockedscreen 3/12 · 2 findings
A crawl flags what a person couldn’t use — even when it’s in the DOM and a DOM test would pass.
What it finds
The bugs your users hit — and DOM tests don’t
A test can pass while a person sees nothing. blindqa checks what a person can actually see, reach and use — for every role, at desktop and phone width.
clipped
overflow: hidden left on body
Scroll-locked pages
A dialog closes but the page stays locked, so the rest of the form can’t be reached.
REVIEWERPOST /invoices/:id/approve403
AUDITORPATCH /clients/:id/status403
STAFFGET /settings/roles403
Buttons the server refuses
A role sees a button the API rejects — and every role’s forbidden actions are sent straight to the server too.
Quantity−3✓ saved
VAT numberGB12✓ saved
Due datebefore issue date✓ saved
Forms that accept nonsense
Negative quantities, invalid tax numbers, a due date before the issue date — saved without a word.
taxCode: Not a valid PAYE tax code
Errors nobody can read
Developer-speak shown to users, or the error rendered behind the dialog that caused it.
OWNERADMINMANAGERREVIEWERSTAFFCONTRACTORAUDITORCLIENT
390×844
Every role, desktop and phone
Signs in as each role (password, authenticator or emailed codes, magic links) and crawls every screen it can reach — then again at 390 px through the ☰ menu.
How it works
Scripts do the work. Your agent does the thinking.
No AI model in the test loop: every check and every judgment call is code, so runs cost zero tokens and the same screen always gets the same verdict. Your coding agent only sets things up, writes journeys and verifies what’s new.
machine time
Scripts that drive
Drive the browser, check visibility, scrolling, contrast and size, block writes, catch console and HTTP errors, index your code, work out what a change touches, compare runs.
machine time
Scripts that judge
The calls a tester makes: is this an error or blank screen, do raw ids leak to users, can a screen reader tell these buttons apart, what will this control do, did that submit work.
tokens — only here
Your coding agent
Claude Code, Codex or any MCP client: sets up the project, writes journeys, verifies new high-severity findings, writes the report. Never watches a run.
Crawl
Read-only. One top-to-bottom pass per page for a role: every control audited, menus and dropdowns opened, “New/Add” forms checked with an empty submit. Every write request is blocked.
Journeys
Short scripts for real workflows — sign in, create data, switch roles, check the figures — written once, reused on every run and every re-test.
Act mode
Uses every option on every screen with valid data and records what each one really did. For test environments only.
Re-test only what changed
Change a file. Re‑test one screen, not the whole app.
The first full run is paid once. After that, a change costs minutes of machine time and one short report.
01Index once
A script reads every file: pages, visible labels, API routes and their permission checks, API calls, imports. 3,312 files in about half a second.
02See what changed
Against the indexed commit or any git ref — which labels, pages and endpoints changed, file by file.
03Follow the impact
Through imports to the pages that render a change, and from a server change to the screens that call its endpoints. Global files mean a full re-test.
04Re-run just that
Only the affected crawls and journeys, compared with the last run on the screens they re-visited: NEW, FIXED, STILL.
Commits since: 1 — Board: new empty text, hide add button modified src/components/Board.tsx — labels +1/-1Affected page routes: 1 — /▶ crawl USER — landing page ✔ 7 new, 0 fixed, 1 still▶ journey taskflow-smoke — passes / ✔ 0 new, 0 fixed, 1 stillNEW high not-humanly-visible: “Add task to Backlog” can’t be used by a person — effectively transparent (opacity 0.00)Real output from a demo app: one component edit, one re-crawled screen, the new bug found.
Any machine, any browser
One browser setting per machine.
Projects move between machines; browsers don’t. Each machine keeps its own mode in ~/.blindqa/machine.json —blindqa machine detect suggests one.
Claude Code
plugin
Codex
plugin
CLI / MCP
any agent
blindqa
the robot
local
headless
cdp
n.eko
O
orca
- local
- A desktop: one visible Chromium window that stays open, robot cursor included.
- headless
- CI and servers without a display.
- cdp
- Your own Chrome, Browserless, any Chromium with remote debugging — in an isolated context, your cookies untouched.
- neko
- A shared browser in an n.eko container your team watches live. Compose template included.
- orca
- Orca’s built-in browser (experimental) — or simply run blindqa in an Orca terminal in local mode.
Safe by default
Your QA data never reaches a git remote.
Logins, saved sessions, screenshots and reports live in one .blindqa/ folder. blindqa never edits your tracked files, crawls are read-only, and repos it clones for testing can’t push at all.
1.blindqa/.gitignore*
The folder ignores itself — this file included. Nothing in your repo’s own .gitignore changes.
2.git/info/exclude/.blindqa/
Git’s per-clone ignore list. Local to this machine, never committed.
3.git/hooks/pre-pushrefuse
Refuses any push whose commits contain a .blindqa/ path — even after git add -f.
$ git push
blindqa guard: push to refs/heads/main refused — these commits contain local QA files:
.blindqa/credentials.json
blindqa guard: push to refs/heads/main refused — these commits contain local QA files:
.blindqa/credentials.json
Proven in CI against a real local remote on every commit.
FAQ
Questions people ask
Install the blindqa plugin with the two commands above, then ask your agent to "set up blindqa for this repo". The setup skill walks through the browser, the project folder, roles and logins.
It is an AI QA tool for the agent you already use: Claude Code or Codex sets it up, decides what to run and checks what it finds. The testing itself is deterministic Playwright scripts, so two runs on the same app give the same results and a run costs no model tokens.
No. Crawls, journeys, act mode and re-tests run locally as scripts. Your coding agent reads only the short summaries and the screenshots it chooses to verify.
Playwright MCP hands your agent a browser, so every click and page read costs tokens and can vary between runs. blindqa runs the browser by script and gives the agent finished reports, and adds what a person would notice: visibility, scroll locks, every role, every menu, and re-tests of only what changed.
Playwright tests check what you thought to assert. blindqa explores like a person — every screen, every role, every menu — and judges what a person can see and use, so it finds problems nobody wrote a test for. The journeys you write are still plain Playwright, with human-like helpers.
No. Crawls and journeys work on any running web app. With the source, blindqa also builds a code index to re-test only what changed and to point each finding at its file.
Crawls are read-only: every write request is blocked at the network level and logged. Journeys and act mode change data, so run those against local or test environments.
No. Everything it writes stays in .blindqa/, which ignores itself, is listed in .git/info/exclude, and is guarded by a pre-push hook that refuses any push containing it. blindqa never changes your tracked files.
Only for setup, writing journeys and verifying new findings. Running crawls, journeys and re-tests costs no model tokens; your agent reads one short summary per run.
It checks what a person meets: unlabeled controls, button names a screen reader can't tell apart, low text contrast (WCAG ratio), tiny tap targets and menus that won't close with Escape. It is not a full WCAG audit, so pair it with axe or Lighthouse for that.
Yes. Use headless mode, and run "blindqa retest --run-tests --headless" on pull requests to re-test only what the change touches.
Routes from Next.js (app and pages router), React Router, SvelteKit, Nuxt, Remix and single-page apps; endpoints from NestJS, Express, Fastify, Hono-style routers and Next.js route handlers; imports through tsconfig aliases and monorepo packages. Anything else is still crawled — impact just falls back to wider re-tests.
Test your app the way your users use it.
Two commands in Claude Code or Codex. MIT licensed, open source — a star helps other developers find it.
> /plugin marketplace add DevZonayed/blindqa> /plugin install blindqa@blindqa