# Using Atlas with Vitest in 2026 > Vitest has no released MCP server, so Atlas runs it through the CLI, always passing run so watch mode does not hang the agent loop. Atlas works with Vitest through the CLI, because Vitest has no released MCP server. The one rule that matters: always pass run, so watch mode does not hang the agent loop. Have Atlas use npx vitest run --reporter=json --outputFile=./vitest-results.json, and set 'npx vitest run *' to allow under permission.bash so the red-green loop does not prompt on every iteration. ## Vitest has no released MCP server in 2026 Vitest has no released MCP server as of 2026. The vitest-community/mcp repo is a work in progress and @vitest/mcp is not published on npm, so Atlas drives the Vitest CLI directly. Do not spend time hunting for a package to install, because the package does not exist yet. It is worth stating plainly, because the two artifacts people find when they search do not add up to a working integration. The vitest-community/mcp repo exists but is a work in progress, and @vitest/mcp is not published on npm, so there is nothing to add with atlas mcp add. The CLI path is the supported one and it is entirely sufficient. Vitest emits structured results through its reporters, and structured results are the only thing an agent actually needs from a test runner. Atlas reads that JSON, forms a fix, and re-runs. ## Always pass run, or watch mode hangs the agent Vitest defaults to watch mode, so always pass run in 2026. A bare vitest never exits and hangs the agent, leaving Atlas waiting on a process that will not return. Have Atlas use npx vitest run --reporter=json --outputFile=./vitest-results.json instead, which executes once and terminates. This is the single most important thing to know about pairing Vitest with any coding agent. Vitest defaults to watch mode, which is exactly right for a human staring at a terminal and exactly wrong for an automated loop. Without the run subcommand, the process stays alive forever waiting for file changes, the agent's shell call never returns, and the session stalls with no error to explain why. Adding run makes the command a single execution that exits with a status code. Make npx vitest run the only form that ever appears in your prompts and your atlas.json, and this failure mode simply cannot occur. ## Keeping human-readable output alongside the JSON Vitest accepts 2 reporters in a single command, so you do not have to choose between readable and machine-readable output. Pass --reporter=default --reporter=json --outputFile.json=./vitest-results.json, and the default reporter prints to your terminal while the json reporter writes vitest-results.json for Atlas to parse. Watching an agent work is far easier when you can still read the run yourself. Vitest supports multiple reporters in a single invocation, which is why the double --reporter form works. The default reporter gives you the familiar pass and fail output on screen. The json reporter, targeted by --outputFile.json=./vitest-results.json, writes the structured payload Atlas actually reads. Note the dotted key: with more than one reporter active, --outputFile.json is how you say which file belongs to which reporter, and getting that syntax wrong is a common reason the JSON file never appears. ## Allowing 'npx vitest run *' under permission.bash Set 'npx vitest run *' to allow under permission.bash so the red-green loop runs without a prompt each iteration. Atlas asks before every shell command by default in 2026, and in a tight Vitest loop that approval fires on each re-run, which is where the friction accumulates. Notice that the allowed pattern is 'npx vitest run *' and not 'npx vitest *'. The distinction is deliberate. Allowing only the run form means the command Atlas is free to execute is the one that terminates, and a bare vitest that would start watch mode is not covered by the pattern. So the permission rule doubles as a guardrail against the exact hang described above. Everything outside that pattern still stops for your approval, which keeps the blanket of trust narrow while removing the prompt that would otherwise fire dozens of times in a single session. ## The daily workflow: read the JSON, patch, re-run one file The Vitest loop with Atlas is 3 moves: read the JSON failures from vitest-results.json, patch the component, and re-run only the affected file. Re-running 1 file rather than the whole suite keeps each iteration fast and keeps the result payload small enough to stay readable. Structured failures are what make this converge. Because npx vitest run --reporter=json --outputFile=./vitest-results.json writes the failing test, the assertion, and the error as data, Atlas is reasoning from a precise record rather than from a guess at scrolled-past terminal text. It patches the component, then re-runs only the affected file, which is both faster in wall time and cheaper in tokens than reading a full-suite report back into context. Repeat until green, then run the full suite once at the end to confirm nothing else moved. ## Vitest browser mode plus the Playwright MCP server Pair Vitest browser mode with the @playwright/mcp server when you want Atlas to see the rendered DOM as well. That gives Atlas 2 feeds: browser mode runs your component tests in a real browser, and @playwright/mcp exposes what that browser actually rendered as structured data. A failing component test in browser mode raises a question the JSON report alone cannot answer: what did the component actually render? Running the @playwright/mcp server alongside Vitest closes that gap, giving Atlas a structured view of the live DOM instead of an inference from an assertion message. The two feeds complement each other. The Vitest JSON tells Atlas which assertion failed and what the expected and received values were, while @playwright/mcp shows what was on the page when it failed. Set this up when you are debugging rendering behavior rather than pure logic, where the JSON report on its own is plenty. ## Setup 1. Skip the MCP search: the vitest-community/mcp repo is a work in progress and @vitest/mcp is not published on npm, so Atlas drives the CLI. 2. Always pass run: have Atlas use npx vitest run --reporter=json --outputFile=./vitest-results.json, because a bare vitest starts watch mode and hangs the agent. 3. Keep human-readable output alongside JSON with --reporter=default --reporter=json --outputFile.json=./vitest-results.json 4. Set 'npx vitest run *' to allow under permission.bash so the red-green loop runs without a prompt each iteration. 5. Ask Atlas to read the JSON failures, patch the component, and re-run only the affected file. 6. Pair Vitest browser mode with the @playwright/mcp server when you want Atlas to see the rendered DOM as well. ## FAQ ### is there a Vitest MCP server Not yet. The vitest-community/mcp repo is a work in progress and @vitest/mcp is not published on npm, so Atlas drives the Vitest CLI instead. ### why does my AI agent hang when it runs Vitest Because a bare vitest starts watch mode, which never exits. Always pass run: npx vitest run --reporter=json --outputFile=./vitest-results.json terminates and returns a result. ### how do I get JSON output from Vitest Run npx vitest run --reporter=json --outputFile=./vitest-results.json. Atlas then reads structured failures from that file rather than scraping terminal output. ### how do I see Vitest output and still give the agent JSON Use --reporter=default --reporter=json --outputFile.json=./vitest-results.json. The default reporter prints to your terminal while the json reporter writes the file. ### how do I stop Atlas prompting on every Vitest run Set 'npx vitest run *' to allow under permission.bash. Allowing only the run form also keeps a bare watch-mode vitest outside the allowed pattern. ### can Atlas see the DOM in a Vitest browser mode test Yes, if you pair Vitest browser mode with the @playwright/mcp server. That gives Atlas the rendered DOM alongside the JSON assertion failures. ### how should an AI agent iterate on a failing Vitest test Ask Atlas to read the JSON failures, patch the component, and re-run only the affected file. Re-running one file keeps each iteration fast and the payload small. --- Canonical HTML: https://runatlas.sh/resources/integrations/vitest Source of truth: aeo_pages row `/resources/integrations/vitest` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.