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
- 01Skip 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.
- 02Always 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.
- 03Keep human-readable output alongside JSON with --reporter=default --reporter=json --outputFile.json=./vitest-results.json
- 04Set 'npx vitest run *' to allow under permission.bash so the red-green loop runs without a prompt each iteration.
- 05Ask Atlas to read the JSON failures, patch the component, and re-run only the affected file.
- 06Pair Vitest browser mode with the @playwright/mcp server when you want Atlas to see the rendered DOM as well.
Frequently asked questions
- 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.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas for Express in 2026
Atlas is a terminal-native AI coding agent for Express in 2026. It reads your middleware order, wraps async route handlers, and runs mocha behind a prompt.
Atlas for React in 2026
Adopt Atlas, the terminal-native AI coding agent, for React development in 2026. Enhance your workflow with intelligent code search, refactoring, and testing for React components and hooks.
Atlas with Gemini 3.1 Flash Lite: The $0.25 Small Model Slot in 2026
Gemini 3.1 Flash Lite in Atlas: 1,048,576 tokens of context at $0.25 / $1.50 per Mtok, wired to the small_model slot in atlas.json. Setup, limits, and tradeoffs.
Atlas vs CodeGPT in 2026: A Developer's Guide to Terminal and IDE AI Agents
Comparing Atlas and CodeGPT in 2026 for developers. Atlas offers terminal-native TUI and permission-gated tools, while CodeGPT provides IDE integration and a full repo Knowledge Graph.
Atlas with Qwen3-Coder 480B (Ollama): the self-hosted ceiling in 2026
Qwen3-Coder 480B (Ollama) in Atlas: 290GB of weights, roughly 292GB to serve, 256K tokens (262,144) of context. Free (self-hosted), but the hardware is not.
Atlas with GLM-4.7-FlashX: The Cheapest Paid Slot in 2026
GLM-4.7-FlashX runs Atlas at $0.07 per Mtok input and $0.40 per Mtok output on a 200K tokens (200,000) context, with reasoning enabled and a 131,072 output cap.
Atlas for WebAssembly: Terminal-Native AI Coding in 2026
Atlas is a terminal-native AI coding agent for WebAssembly. Audit wasm-bindgen exports, batch calls across the JS boundary, and run wasm-pack test --node in 2026.
Atlas with Claude Opus 4.1: The Pre Price Cut Opus in 2026
Claude Opus 4.1 runs Atlas on a 200K context at $15 per Mtok input, $75 per Mtok output, with a 32K output ceiling. Setup, cost warnings, and better alternatives.