To turn a wall of red C++ output into a prioritized list of distinct root causes, run GoogleTest via ctest through Atlas's bash tool with a generous timeout in milliseconds, then triage against the complete log. A full C++ suite produces far more output than any model should read: Atlas's bash tool truncates at 2000 lines or 50 KB, writes the complete log to a retained file, and tells you the path, so grouping happens over the whole run rather than a lossy tail. Each distinct cause then becomes one todowrite entry with status pending.
How do I run a full C++ test suite from an AI coding agent without losing the output?
Run GoogleTest via ctest through Atlas's bash tool and pass a generous timeout in milliseconds so a slow C++ suite is not killed mid-run. Atlas truncates the displayed output at 2000 lines or 50 KB, writes the complete log to a retained file, and prints the path in an ...output truncated... header.
A C++ suite is the worst case for agent output. A single failing translation unit can emit hundreds of lines of template instantiation backtrace, and a link failure can bury a real assertion under a page of undefined symbol noise. If the agent only saw the last 200 lines, the first and most informative failure would be gone. Atlas's bash tool solves that by separating what the model reads from what is retained: 2000 lines or 50 KB in context, the full log on disk. The path in the ...output truncated... header is what you read next, and it is the log that triage actually runs against.
Why does a C++ suite need a bigger bash timeout than most languages?
A C++ run is 2 phases, a build and then a run, which is why it needs a bigger bash timeout than most languages. GoogleTest via ctest compiles translation units first, and a cold build against a large CMakeLists.txt with vcpkg dependencies can take many minutes, so pass a generous timeout in milliseconds.
Atlas's bash tool races every command against a timeout, which is exactly right for a hung script and exactly wrong for an honest C++ build that needs 8 minutes to compile before ctest even starts scheduling tests. The fix is to tell Atlas what a reasonable duration looks like: a timeout value in milliseconds that covers compile plus run. Get that wrong and you triage a killed build instead of a failing suite, which is a different and much less useful problem. Configure the timeout once, run GoogleTest via ctest, and let the compile finish.
How do I group C++ test failures by root cause instead of by test name?
Group by cause, not by name. Atlas greps the saved ctest log for the failure signatures rather than reading the failing test list, because in C++ one broken header or one changed constructor signature can turn 40 GoogleTest cases red while representing exactly 1 root cause.
Test names lie about cardinality in C++. A single change to a type in include/core/model.h can fail every test that includes it, and a fixture SetUp that throws will fail every case in that test suite. Grouping by the actual failure text is what collapses that back down. Atlas greps the retained log, which is the whole log rather than the truncated tail, for the recurring assertion messages, the undefined symbol lines, and the compiler diagnostics. Atlas grep runs through ripgrep and takes a real regex plus include and path filters, so pulling every distinct diagnostic out of a 40,000 line ctest log is one call. The output is a list of distinct causes, and it is almost always far shorter than the list of red tests.
How do I track the distinct causes so a C++ triage does not get forgotten?
Record one todowrite entry per distinct cause, with status pending. A C++ triage that finds 5 root causes behind 40 failing GoogleTest cases turns into 5 tracked items, which is what stops the third and fourth cause from being lost the moment the first fix compiles.
The todowrite list is the durable artifact of the triage. Each entry names a cause, not a test: a changed signature in src/core/model.cpp, a missing vcpkg dependency, a fixture that leaks a file handle, a header include ordering problem in include/core/. Working from that list, Atlas fixes them one at a time with the edit tool and re-runs only the affected tests via bash between changes, rather than paying for a full ctest cycle after every hunk. That is the loop: one cause, one edit, one narrow ctest run, mark the todowrite entry done, next cause.
How does Atlas review C++ edits made during triage?
Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each triage fix to src/core/model.cpp or include/core/model.h is reviewed as a diff. Atlas also snapshots file changes as git patches, so any 1 fix that makes the C++ build worse can be diffed and rolled back on its own.
Triage is where bad fixes get made, because the temptation is to change the assertion instead of the code. Reviewing every edit as a unified diff before it is written is the check on that. Every Atlas tool call is also permission-gated against allow, ask, and deny rules before it runs, so the bash call that runs GoogleTest via ctest and the edit that touches a header are both approved actions. Run clang-format after the fixes land so the diff shows the behavioral change and not a whitespace reflow, and let Atlas stage the result: Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf.
How do I set Atlas up on a C++ project before triaging the suite?
Setup takes 3 steps: run atlas in a project with a CMakeLists.txt, let Atlas read your headers, translation units, and build targets, then have Atlas modernize to smart pointers or add GoogleTest cases and review the diff. That reading is what maps a failure back to the .cpp file responsible.
The CMakeLists.txt is the map: it declares the targets ctest will run and the translation units they compile. With that loaded, Atlas can modernize to smart pointers or add GoogleTest cases and show you the diff to review, and the triage workflow uses the same understanding to group failures. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so when a triage step needs to find the declaration behind a failing assertion, codebase_search returns the actual function or class rather than a 40 line window. Manage the third-party dependencies through vcpkg so a red suite is never just a missing package.
Step by step
- 01Run atlas in a C++ project with a CMakeLists.txt so Atlas reads your headers, translation units, and build targets.
- 02Run the suite with the bash tool, invoking GoogleTest via ctest and passing a generous timeout in milliseconds so a slow compile plus run is not killed mid-way.
- 03If the output was truncated, read the file named in the ...output truncated... header to see the complete log; bash truncates the displayed output at 2000 lines or 50 KB.
- 04Group the failures by root cause with grep over the saved log rather than by test name, since one changed header can turn 40 GoogleTest cases red for a single reason.
- 05Record one todowrite entry per distinct 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 via bash between changes, rather than paying for a full ctest cycle after every hunk.
- 08Run clang-format so the diff shows behavior and not whitespace, confirm vcpkg dependencies resolve, then run the full GoogleTest via ctest suite one last time.
Frequently asked questions
- how do I triage a large number of failing C++ tests
- Run GoogleTest via ctest through Atlas's bash tool, then read the complete saved log rather than the truncated tail and group the failures by root cause with grep. One broken header or one changed signature commonly explains dozens of red GoogleTest cases. Record one todowrite entry per distinct cause.
- why does Atlas truncate my ctest output
- Atlas's bash tool truncates the displayed output at 2000 lines or 50 KB because a full C++ suite emits more than any model should read. The complete log is written to a retained file and the path is printed in the ...output truncated... header, so nothing is lost.
- how do I stop Atlas from killing a slow C++ build
- Pass a generous timeout in milliseconds to the bash tool. A C++ run through ctest usually compiles translation units first, and a cold build against a large CMakeLists.txt with vcpkg dependencies takes minutes. A killed build is not a failing suite, and triaging one for the other wastes the run.
- should I group C++ test failures by test name or by error
- By error. In C++ a single change to a header under include/ fails every translation unit that includes it, and a throwing fixture SetUp fails every case in that suite. Grep the saved ctest log for the recurring diagnostics and assertion messages to get the real cause count.
- what is todowrite in Atlas
- todowrite is the Atlas tool that records a tracked list of work items. During a C++ triage you write one entry per distinct root cause with status pending, then fix them one at a time with edit and re-run only the affected ctest tests between changes.
- does Atlas show me the diff before it edits a C++ header
- Yes. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and it snapshots file changes as git patches so edits can be diffed and rolled back. Every tool call is permission-gated against allow, ask, and deny rules before it runs.
- does Atlas understand CMake targets
- Run atlas in a project with a CMakeLists.txt and Atlas reads your headers, translation units, and build targets. That is what lets it map a failing GoogleTest case back to the .cpp file responsible instead of guessing from the test name.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated 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 C++ in 2026
In 2026, C++ developers adopt Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas offers secure, context-aware assistance for modern C++ projects, integrating with CMake and ensuring code quality
Migrate a Deprecated API Across Every C++ Callsite with Atlas (2026)
Move a C++ codebase off a deprecated function without missing a caller in 2026: Atlas enumerates with findReferences, patches with apply_patch, verifies with ctest.
Run Atlas Headless in CI for C++ Projects in 2026
In 2026, C++ developers can run Atlas headless in CI pipelines to automate code tasks. Get machine-readable output, integrate with vcpkg and GoogleTest via ctest, and ensure safety.
Review a C++ Pull Request with Atlas (2026)
How Atlas reviews a C++ pull request in 2026: get the diff with bash, read whole translation units, and use lsp findReferences to catch callers the diff never shows.
Audit a repo with parallel subagents in C++ with Atlas (2026)
Sweep a whole C++ repo for one class of defect in 2026 without blowing your context window. Atlas fans out read-only explore subagents across CMake targets and headers.
Automate GitHub Issue and Pull Request Triage in C++ with Atlas in 2026
Automate GitHub issue and pull request triage for C++ projects using Atlas. Safely respond to events, enforce permissions, and manage context overflow in 2026 with your existing C++ toolchain.
Add a regression test for a bug fix in C++ with Atlas (2026)
Red first, then green. Atlas proves a C++ bug with a failing GoogleTest case, applies the fix with edit, and re-runs ctest so the exit code makes the result unambiguous.