Built for coding agents
Runtime verification for Claude Code, Codex, and Cursor.
Agent-verifiable runtime testing is a verification loop where an independent agent boots your app in an isolated VM, writes the tests, and hands your coding agent a structured verdict it can act on mid-task — not a green checkmark it has to take on faith.
$ npx @omea/cli run
> verdict for pr-184
{ "status": "fail",
"test": "checkout > applies discount code",
"trace": "https://omeahq.com/t/8f2c1e" }Why coding agents need this
Agents can't be trusted when they say tests pass.
"Claude will often just update the tests to no-op so tests passing isn't trustworthy."— jmvldz, Hacker News [1]
"it sat there “thinking”…then finally spit out the command echo "Test Passed!", executed it, read it from the terminal, and said it was done."— djeastm, Hacker News [2]
These aren't edge cases — they're the reason "tests passing" stopped being evidence. Omea's tests are written by a separate agent, run in an environment your coding agent doesn't control, against platform twins instead of production credentials. Teams don't have to give the coding agent the keys to find out whether it told the truth.
The other half of the problem
Run multiple Claude Code instances in parallel, and the environment fights back.
"Claude Code sessions crash at 3am from context compaction, agents silently block on permission prompts, and there's no good way to see which of your 8 running sessions actually needs attention."— Beefin, Show HN [4]
"when you're running 4-5 Codex/Claude Code sessions in parallel across worktrees, the port collision sucks."— isehgal, Hacker News [5]
Worktrees isolate code, not the environment — ports and databases still collide. Every Omea test run gets its own forked VM, so parallel agents verifying parallel changes never fight over the same port, database, or state.
What you get back
What npx @omea/cli run returns.
Pass/fail per test plus a trace link, shaped to be parsed by an agent — not only rendered for a person.
Syncs the dirty, uncommitted tree you're actually working on, not just the last commit.
Backed by plain @playwright/test files in your repo — exportable, no lock-in.
Ships as an installable skill with an AGENTS.md snippet, a Cursor rule, a CLAUDE.md snippet, and llms.txt — all generated from one source so they can't drift — so your agent writes our test format the way it already writes code.
Where this fits
Read next.
The full mechanics: connect, boot, author, cover, verify.
Service-wrapped human QA versus an agent-native verdict loop.
Plain-English authoring versus tests your repo already owns.
A sub-agent driving an already-running target versus booting the app from the repo.
Sources