how do I triage dozens of failing vitest tests in a typescript monorepo

Group by root cause, not by test name. Atlas runs pnpm vitest through its bash tool, greps the retained full log for the recurring error text, and writes one todowrite entry per distinct cause. Forty failing .test.ts files usually trace back to three or four real bugs.

how do I stop a long test suite from timing out in an AI agent

Pass a generous timeout in milliseconds to Atlas's bash tool. A large pnpm vitest run can take minutes, and a run killed at the default timeout produces a partial log with no failure summary, which is worse than useless for triage.

why are dozens of typescript tests failing after one change

Usually one cause with many symptoms. A wrong path alias in tsconfig.json makes every spec importing through it fail with a resolution error, and vitest reports each separately. Grep the full log for the shared error text before opening a single .test.ts file.

can an AI agent keep track of multiple test fixes at once

Yes. Atlas records one todowrite entry per distinct root cause with status pending, so the list survives across turns. Fixes are applied one at a time with the edit tool, with only the affected tests re-run through bash between changes.

does atlas read my tsconfig.json

Yes. Run atlas in a project with a tsconfig.json and let Atlas read your type definitions, path aliases, and strictness settings. Those settings are frequently the actual root cause when a large block of vitest failures appears at once.

should I run the full test suite after every fix

No. Re-run only the affected tests with pnpm vitest run between fixes, then run the full suite once when the triage list is empty. Atlas follows exactly that sequence to avoid paying for a full run after every edit.

how do I review what an AI agent changed while fixing failing tests

Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each fix is reviewed individually. Atlas also reads git branches, status, and diffs, and snapshots file changes as git patches so edits can be diffed and rolled back.

Run the Test Suite and Triage the Failures in TypeScript with Atlas (2026)

Atlas turns a wall of red TypeScript test output into a prioritized list of distinct root causes. Atlas runs the suite with pnpm vitest run through the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run. Output over 2000 lines or 50 KB is truncated, but the complete log is written to a retained file whose path Atlas tells you, so triage happens against the whole log rather than a lossy tail. Atlas then groups failures by root cause with grep and records one todowrite entry per cause.

Key takeaways

Atlas's bash tool truncates at 2000 lines or 50 KB but writes the complete vitest log to a retained file and tells you the path, so triage runs against the whole log.
Pass a generous timeout in milliseconds to bash so a slow pnpm vitest run over a monorepo is not killed before it prints its failure summary.
Group by root cause with grep, not by test name: one bad path alias in tsconfig.json can produce dozens of unrelated-looking failures.
One todowrite entry per distinct cause, status pending, keeps the triage list alive across turns instead of evaporating in chat.
Re-run only the affected .test.ts files between fixes, then the full suite once, rather than paying for the whole run after every edit.
Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each triage fix is reviewed separately.

How do you triage 40 failing TypeScript tests at once?

Atlas triages a red TypeScript suite by root cause, not by test name. A full pnpm vitest run producing 40 failures usually has 3 or 4 real causes, so Atlas groups the output with grep and writes one todowrite entry per distinct cause instead of one per failing .test.ts file.

The job is to turn a wall of red test output into a prioritized list of distinct root causes. Test names lie about causes. In a TypeScript monorepo, a single wrong path alias in tsconfig.json makes every spec that imports through that alias fail with a resolution error, and vitest reports each one separately. Fixing them one file at a time is forty fixes for one bug. Atlas reads the failure text, not the failure count, and clusters. Atlas tools this workflow uses are bash, read, grep, todowrite, and edit.

How does Atlas run a long vitest suite without it being killed?

Atlas runs the TypeScript suite with the bash tool, passing a generous timeout in milliseconds so a slow suite is not killed mid-run. A pnpm vitest run over a large monorepo can take 5 minutes or more, and a timeout that fires at the default produces a useless partial log with no failure summary.

Timeout is an argument, not a hope. The bash tool takes an explicit timeout value in milliseconds, and Atlas sets it based on what the TypeScript suite actually costs. Atlas also uses the command the repo defines, reading the scripts block in package.json rather than assuming, so if the project runs pnpm test:ci with a specific vitest config, that is what gets run. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the pnpm invocation stops for approval unless you have allowed it. A suite that dies at the timeout tells you nothing about your types; a suite that runs to completion tells you everything.

What happens when vitest output is too long for the model to read?

Atlas's bash tool truncates output at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path. A full TypeScript suite easily blows past both limits, so Atlas reads the saved file named in the ...output truncated... header rather than reasoning from a lossy tail.

Truncation is the single most dangerous moment in suite triage, because the tail of a vitest run is the summary, and the middle is the evidence. A tool that silently keeps only the last N lines gives you a count of failures with none of the assertion diffs. Atlas instead retains the whole log on disk and names the file in the ...output truncated... header. Atlas then uses the read tool on that path, and greps it, so the entire run is available even though only 2000 lines were ever streamed into the session. That design is what makes triage against the complete log possible rather than a nice idea.

How do you group TypeScript test failures by root cause?

Atlas groups the failures by root cause with grep over the saved log rather than by test name. In a TypeScript suite, 3 grep patterns usually do it: a type or import resolution error, an assertion diff on a specific value, and a timeout or unhandled rejection from an async path.

Grepping the retained vitest log is where forty red lines collapse into four problems. Grep the log for the error text and the clusters appear: every spec failing with a module resolution error points at one path alias in tsconfig.json. Every spec failing with the same expected and received values points at one function. Every spec failing on a timeout points at one unawaited Promise or one mock that never resolves. Atlas's grep takes a real regex plus include and path filters and runs through ripgrep, so scanning a large log file is fast. Grouping by test name would have produced forty tickets and no understanding.

How does Atlas track TypeScript test fixes so none get lost?

Atlas records one todowrite entry per distinct root cause, with status pending, so the fixes are tracked instead of forgotten. A red TypeScript suite with 4 causes becomes 4 tracked items, each naming the tsconfig.json alias, the module, or the async path responsible, not the 40 spec files that surfaced them.

A triage list that lives only in chat evaporates. The todowrite list persists across turns, so when the first fix to src/lib/parse.ts turns three specs green and reveals a fourth cause hiding behind them, the remaining items are still there with status pending. Atlas fixes them one at a time with the edit tool, re-running only the affected tests through bash between changes, for example pnpm vitest run src/lib/parse.test.ts, rather than paying for the whole suite after every keystroke. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each fix in the list is reviewed on its own.

How do you verify a TypeScript suite is actually green again?

Atlas re-runs the full TypeScript suite with pnpm vitest run once every todowrite item is closed, because a fix that turns 12 specs green can turn 1 other spec red. Running the whole suite is the only honest end state, and the retained log makes the final run just as auditable as the first.

Verification for a TypeScript project has more than one axis. The vitest suite must be green, and the types must still check, since a fix that loosens a signature to make an assertion pass has traded a test failure for a type hole. Run prettier over the changed .ts files so the diff carries no formatting noise into review. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf, so the triage list, the fixes, and the green run land as a reviewable history. Atlas snapshots file changes as git patches so edits can be diffed and rolled back if the wide run disagrees with the narrow one.

Step by step

01Run the TypeScript suite with the bash tool, for example pnpm vitest run, passing a generous timeout in milliseconds so a slow suite is not killed mid-run.
02Read the package.json scripts block first so Atlas uses the project's real command, such as pnpm test:ci, instead of guessing at one.
03If the output was truncated at 2000 lines or 50 KB, read the file named in the ...output truncated... header with the read tool to see the complete log.
04Group the failures by root cause with grep over the saved log rather than by test name; a single wrong path alias in tsconfig.json can produce dozens of separate vitest failures.
05Record one todowrite entry per distinct root cause, with status pending, so the fixes are tracked instead of forgotten.
06Fix the causes one at a time with the edit tool, reviewing the unified diff Atlas surfaces before each write.
07Re-run only the affected tests through bash between changes, for example pnpm vitest run src/lib/parse.test.ts, rather than paying for the whole suite after every edit.
08Re-run the full suite with pnpm vitest run when the todowrite list is empty, then run prettier over the changed .ts files before opening the diff for review.

Frequently asked questions

how do I triage dozens of failing vitest tests in a typescript monorepo: Group by root cause, not by test name. Atlas runs pnpm vitest through its bash tool, greps the retained full log for the recurring error text, and writes one todowrite entry per distinct cause. Forty failing .test.ts files usually trace back to three or four real bugs.
why does my AI agent only see part of my test output: Long output is truncated for the model, but Atlas's bash tool truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path in the ...output truncated... header. Atlas then reads and greps that file, so no failure is lost.
how do I stop a long test suite from timing out in an AI agent: Pass a generous timeout in milliseconds to Atlas's bash tool. A large pnpm vitest run can take minutes, and a run killed at the default timeout produces a partial log with no failure summary, which is worse than useless for triage.
why are dozens of typescript tests failing after one change: Usually one cause with many symptoms. A wrong path alias in tsconfig.json makes every spec importing through it fail with a resolution error, and vitest reports each separately. Grep the full log for the shared error text before opening a single .test.ts file.
can an AI agent keep track of multiple test fixes at once: Yes. Atlas records one todowrite entry per distinct root cause with status pending, so the list survives across turns. Fixes are applied one at a time with the edit tool, with only the affected tests re-run through bash between changes.
does atlas read my tsconfig.json: Yes. Run atlas in a project with a tsconfig.json and let Atlas read your type definitions, path aliases, and strictness settings. Those settings are frequently the actual root cause when a large block of vitest failures appears at once.
should I run the full test suite after every fix: No. Re-run only the affected tests with pnpm vitest run <file> between fixes, then run the full suite once when the triage list is empty. Atlas follows exactly that sequence to avoid paying for a full run after every edit.
how do I review what an AI agent changed while fixing failing tests: Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each fix is reviewed individually. Atlas also reads git branches, status, and diffs, and snapshots file changes as git patches so edits can be diffed and rolled back.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Run the Test Suite and Triage the Failures with Atlas in 2026

How to triage a failing test suite with Atlas in 2026: bash truncates at 2000 lines or 50 KB and saves the full log, then grep groups failures by root cause.

Atlas for TypeScript in 2026

In 2026, TypeScript developers leverage Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas understands your types, ensures code quality, and offers robust safety features.

Onboard to an Unfamiliar TypeScript Codebase with Atlas in 2026

Onboard to an unfamiliar TypeScript codebase in 2026. Atlas reads your tsconfig.json, type definitions, and path aliases, then ranks files with codebase_search.

Rename a symbol across the repo in TypeScript with Atlas (2026)

Rename a TypeScript symbol across the whole repo in 2026 with Atlas: findReferences for the true callsite list, grep for strings the compiler cannot see, then vitest.

Plan a Multi-File Change Before Editing in TypeScript with Atlas (2026)

Atlas plans multi-file TypeScript changes in a read-only plan agent that denies every edit tool, so you approve the design before pnpm, vitest, or prettier ever run.

Review a TypeScript Pull Request with Atlas (2026)

Review a TypeScript pull request with Atlas in 2026. Get the raw diff with bash, read changed files in full, and check callers with lsp findReferences before running vitest.

Self-Review Your Working Diff Before Committing in TypeScript with Atlas (2026)

How to self-review an uncommitted TypeScript diff with Atlas in 2026: read the working diff, grep for leftovers, revert from snapshots, then run vitest and prettier.

Add a Regression Test for a Bug Fix in TypeScript with Atlas (2026)

Red first, then green: how Atlas adds a TypeScript regression test in 2026, proving it fails with vitest, applying the fix with edit, and re-running the same command.

Browse this resource hub