To diagnose a hanging or long-running command in C++, Atlas races every bash command against a timeout and, when it expires, tells you exactly what happened and what to do: retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input. That second clause is the diagnosis. A CMake configure step or a GoogleTest via ctest run that is blocked on stdin will never resolve by waiting, while a genuinely slow vcpkg install just needs a bigger number.
Why does my C++ build hang when an AI agent runs it?
A C++ build hangs under an AI agent for 1 of 2 reasons: the command is genuinely slow, like a cold vcpkg install or a full CMake configure, or it is silently blocked waiting on stdin. Atlas's bash tool races every command against a timeout, and the message it returns names which of the 2 cases you hit.
C++ toolchains are full of prompts that never appear in CI: a vcpkg step asking to accept a license, a CMake toolchain script waiting on a choice, a package manager asking for confirmation. Under a normal shell you would see the prompt and answer it. Under an agent the process just sits there. Atlas's bash tool kills the command on timeout and returns a message that explicitly calls out the interactive-input case, so the difference between a 20 minute link step and a permanently blocked configure is stated rather than inferred.
How do I read the shell_metadata block after a C++ command times out?
Atlas returns a shell_metadata block with the output when a C++ command is killed, and reading that block is the diagnosis. The message tells you to retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input, which is the 1 sentence that splits slow from blocked.
The shell_metadata block is where the C++ debugging decision actually gets made. A ctest run that was killed at the timeout while still printing test names is slow. A CMake configure that produced no output for the entire window and then died is a strong candidate for being blocked on stdin. Atlas reads the block, not just the tail of the log, so the decision is based on the process state the bash tool recorded rather than on how the console text happens to end. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the retry is a deliberate act.
How do I stop a C++ command from blocking on interactive input?
Stop a blocked C++ command by re-running it with non-interactive flags, and Atlas names 3 of them: -y, --no-input, or CI mode, depending on the tool. A vcpkg step or a CMake driver that cannot prompt cannot hang on a prompt that nobody will ever answer.
Blocking on stdin is the most common cause of a hang in a C++ pipeline, and it never resolves by waiting, so raising the timeout is the wrong move. Atlas re-runs the command through bash with the tool's own non-interactive flags so it fails fast instead of prompting into a void. The same applies to GoogleTest via ctest when a test reads from standard input, which turns a test run into an indefinite wait. Making the command non-interactive turns a hang into an error message, which is a far more useful thing to debug.
How do I retry a genuinely slow C++ build with a larger timeout?
When a C++ command is genuinely slow rather than blocked, retry it through Atlas's bash tool with a larger timeout value expressed in milliseconds, exactly as the timeout message instructs. Only 1 number changes, the timeout itself, and the command stays the same. A cold vcpkg install or a full CMake build with heavy template instantiation is legitimately long, not stuck.
C++ has real reasons to be slow: a from-source vcpkg install of a large dependency, a link step over hundreds of translation units, an optimized rebuild after a header in include/ changed. Atlas raises the timeout in milliseconds for those, having first ruled out the interactive-input case from the shell_metadata block. Reading the CMakeLists.txt with the read tool often explains the cost, because a target's dependencies and compile options are declared there. The point is that the retry is justified by evidence rather than by hope that a second run behaves differently.
How does Atlas tell a timeout apart from a command I cancelled myself?
Atlas separates a timeout from your own interrupt in the bash metadata: when you abort a command yourself, the metadata says User aborted the command. Those are 2 different signals with 2 different next steps, so a ctest run you cancelled and a ctest run killed by the timeout never get confused in a C++ session.
Confusing your own interrupt with a hang sends the C++ debugging in the wrong direction, for example raising a timeout that was never reached. Because the bash tool reports User aborted the command when the abort came from you, an interrupted GoogleTest via ctest run is not misfiled as a stuck one. Atlas's bash tool is also a real shell, so once the correct diagnosis is in hand the usual C++ levers still apply: build a single target, run one ctest test, or run clang-format over changed sources before committing anything the investigation produced.
Step by step
- 01Run atlas in a C++ project with a CMakeLists.txt and let Atlas read your headers, translation units, and build targets.
- 02Run the suspect command, for example a CMake configure, a build, or GoogleTest via ctest, through the bash tool.
- 03Read the shell_metadata block in the output when the command is killed, rather than only the tail of the log.
- 04Decide from the message whether the command is slow or blocked: Atlas explicitly calls out the interactive-input case.
- 05If it is blocked, re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so vcpkg or CMake cannot prompt.
- 06If it is genuinely slow, for example a cold vcpkg install or a heavy template-instantiation build, retry with a larger timeout value in milliseconds as the message instructs.
- 07If you aborted the run yourself, note that the metadata says User aborted the command, which is not a timeout.
- 08Read CMakeLists.txt with the read tool to confirm which target is responsible, then run clang-format over any sources you changed.
Frequently asked questions
- why does my cmake build hang when an AI coding agent runs it
- The command is usually blocked on interactive input rather than slow. Atlas's bash tool races the command against a timeout and explicitly calls out the interactive-input case, so re-run with -y, --no-input, or CI mode.
- how do i increase the command timeout for a slow c++ build in atlas
- When the timeout message says to retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input, retry with a larger timeout value in milliseconds. Use that only after ruling out a stdin block.
- atlas ctest run timed out, is my test suite stuck
- Read the shell_metadata block in the bash output. A GoogleTest via ctest run still printing test names when killed is slow. One that produced no output and then died is a candidate for being blocked on stdin.
- what does User aborted the command mean in atlas
- That metadata means you interrupted the run yourself rather than the bash timeout killing it. A cancelled C++ build is not a hang, so raising the timeout is not the right response.
- why does vcpkg hang inside an AI agent session
- A vcpkg step that wants confirmation will wait on stdin forever inside an agent session, because nothing is there to answer it. Re-run it through Atlas's bash tool with the non-interactive flags so it cannot prompt.
- what does atlas need to work in a c++ project
- Run atlas in a project with a CMakeLists.txt. Atlas reads your headers, translation units, and build targets, and can modernize to smart pointers or add GoogleTest cases with the diff shown before writing.
- can atlas run clang-format on my c++ sources
- Yes. Atlas's bash tool is a real shell, so clang-format runs over the translation units you touched, and every tool call is permission-gated against allow, ask, and deny rules before it runs.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Diagnose a Hanging or Long-Running Command with Atlas in 2026
How to diagnose a hanging command with Atlas in 2026: the bash tool races every command against a timeout and tells you whether it is slow or blocked on input.
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
Upgrade a C++ Dependency and Fix Breakage with Atlas in 2026
In 2026, C++ developers use Atlas to efficiently upgrade major dependencies with vcpkg, automatically fixing compile and GoogleTest failures. Atlas streamlines the entire migration process.
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.
Locate Where a Behavior Is Implemented in C++ with Atlas (2026)
How Atlas finds the C++ file and symbol behind a behavior in 2026: codebase_search for meaning, ripgrep for exact text, and the lsp tool for the symbol graph.
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.
Run the test suite and triage the failures in C++ with Atlas (2026)
Triage a red C++ suite in 2026 with Atlas: run GoogleTest via ctest through bash, read the full saved log past the 2000 line truncation, and group causes in todowrite.
Trace a Runtime Bug From a Stack Trace in C++ With Atlas (2026)
How to trace a C++ runtime bug from a stack trace with Atlas in 2026: read each frame at its offset, grep for the error string, and prove the fix with GoogleTest.