agent-labs-dev / bugpatrol
git clone https://github.com/agent-labs-dev/bugpatrol.git
v0.3.0 · 12d ago
Automated app testing from the future
+0
stars, 24h · #30,301
+~0
stars, 7 days · #30,776
+143
stars, 30 days · #3,709
143
★ total
14
forks · 2 open issues
Star history (as recorded here)
LanguageTypeScript
LicenseApache-2.0
Created2026-09-22 (1mo ago)
Last push5d ago
Watchers0
OwnerOrganization
Links
- GitHub: github.com/agent-labs-dev/bugpatrol
- Homepage: https://bugpatrol.vercel.app
- Releases · Issues · Hacker News mentions
README excerpt
Bugpatrol is a QA team made of agents. It uses your app the way a tester does, finds bugs, fixes them, checks each fix in the running app, and opens the pull requests and issues for your team. - An **explorer** agent runs the app, maps its screens, and reports what looks wrong. - A **judge** agent decides which reports are real bugs, and writes the issues. - A **fixer** agent writes a fix in its own git worktree. Then the explorer and the judge **retest** the fix in the running app. - Bugpatrol **publishes** to GitHub: a PR for each fix, and an issue for each major bug with no fix. It tests web apps, Electron and other desktop apps, iOS and Android apps, HTTP APIs and CLIs. It runs on your machine, and it can run all day as a patrol. The Nebula team uses Bugpatrol every day to test our own desktop and mobile apps. We made it open source, so that all teams can use it. [code] `npx bugpatrol` runs the patrol: the full cycle, again and again: explore, judge, fix, retest, publish, and make CI green. The fixer and GitHub stay off until you turn them on. ### How the patrol runs Three LLM agents do the work: the explorer, the judge, and the fixer. The explorer sees each screen, and also the console errors and the failed requests of the app. [code] How it works shows each step of the explore loop. - The patrol does not stop by itself. Every 30 minutes, it pulls the latest `origin/main`. - The patrol explores and judges only when `main` has new commits. On the same commit, it skips these two steps, but it still finishes the open work: fixes, retests, publish, CI checks, and the GitHub sync. So a patrol that runs all day costs little when nobody merges code, and a fix never waits for the next merge. - Bugpatrol keeps the last tested commit in `.bugpatrol/runs/`, so a restart also skips a commit that it tested before. To test again with no new commit, for example after a config change, use `npx bugpatrol --force`. - You can change the wait with `agents.patrol.intervalMinutes`. To stop after a number of cycles, set `agents.patrol.cycles`. To run one cycle only, use `npx bugpatrol --once`. - You can also run `npx bugpatrol --once` from cron, for example every 30 minutes. Each run tests only a new commit. If the last patrol still runs, the new run does not start. - To use a different branch, set `agents.patrol.pull`. - Let the patrol run all the time on a dedicated computer or a cloud VM. The patrol changes the checkout of the repo, so do not run it in the checkout where you work. When you turn on GitHub, the patrol opens GitHub issues and PRs automatically, in each cycle, with no approval step. It opens a PR for each fix, and an issue for each major bug with no fix. The PRs are drafts by default (`agents.github.pullRequests`). You can close any issue or PR: the patrol learns from it, and it does not open it again. GitHub tells more. ## Set up with your agent 1. Install the Bugpatrol skill in your repo: [code] The skills CLI installs the skill for Claude