# Diagnose a Hanging or Long-Running Command in Rust with Atlas (2026) > When a cargo command hangs, Atlas tells you whether it is genuinely slow or blocked on interactive input, because a Rust build waiting on stdin never resolves by waiting longer. Atlas diagnoses a hanging Rust command by racing it against a timeout in the bash tool and telling you exactly what happened when the timeout expires: 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 cargo build blocked on stdin is the most common cause of an apparent hang, and it never resolves by waiting, so distinguishing a genuinely slow cargo test run from a blocked one is the whole job. ## Key takeaways - A cargo command blocked on stdin never resolves by waiting; a slow cargo build does, and Atlas tells you which you have. - The shell_metadata block carries the verdict on a killed command, not the partial Compiling output. - Re-run a blocked Rust command with -y, --no-input, or CI mode so it errors instead of hanging. - A genuinely slow cargo test workspace run just needs a larger timeout value in milliseconds. - User aborted the command means you interrupted it, so re-run rather than start diagnosing a hang that did not happen. ## Why does my cargo build hang forever under an AI agent? A cargo build that appears to hang in 2026 is usually blocked on stdin, not slow. Atlas races every command through the bash tool against a timeout and, when the timeout expires, explicitly calls out the interactive-input case, because a Rust build waiting for a credential prompt will still be waiting an hour later. The classic Rust version of this is a cargo build that needs to fetch a private git dependency listed in Cargo.toml and stops dead at a credential prompt no one can see. From the outside it looks identical to a slow release build of a large crate graph. Waiting longer fixes one and not the other, which is why Atlas does not just report a timeout. The message names the possibility so the next action is a decision rather than a guess. ## What is in the shell_metadata block when a Rust command is killed? The shell_metadata block is where the Atlas bash tool records what actually happened to a killed cargo command, and it separates 2 outcomes: a timeout, which tells you to retry with a larger timeout in milliseconds, and User aborted the command, which means you interrupted the run yourself. Partial output from a killed cargo test run is misleading on its own: you see Compiling for 30 crates and then nothing, which tells you the build was progressing but not why it stopped. The shell_metadata block carries the verdict. If the command hit the timeout, 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. If you interrupted it yourself, the metadata says User aborted the command, which is a completely different situation from a hang. ## How do I stop cargo from prompting for input inside an agent session? Atlas re-runs a blocked Rust command with 3 non-interactive levers, -y, --no-input, or CI mode, so the cargo invocation cannot prompt at all. A command with no way to ask a question either succeeds or fails with a real error, which is strictly more useful than hanging. Turning a hang into an error is the point. A cargo command that would have waited forever on a credential prompt instead exits with an authentication failure you can read and act on, by fixing the credential helper or by vendoring the dependency. The non-interactive flags are the lever: -y, --no-input, or CI mode, depending on what the tool supports. Every bash call is permission-gated against allow, ask, and deny rules before it runs, so the re-run with different flags is something you approve explicitly. ## How do I run a genuinely slow cargo test suite without it being killed? Atlas retries a genuinely slow Rust command with a larger timeout value in milliseconds, exactly as the shell_metadata message instructs. A cargo test run over a large workspace in 2026, or a cold cargo build of a release profile, can legitimately exceed a default timeout without anything being wrong. Rust makes this common. A cold cargo build compiles every crate in the dependency graph, and a workspace with heavy proc macros can spend many minutes doing legitimate work. Killing that run and concluding the build is broken is a wasted afternoon. Atlas passes a larger timeout in milliseconds and lets the compile finish. The distinction from the blocked case is what the shell_metadata message helps you make: slow means wait longer, blocked means never wait, and Atlas gives you the information to tell them apart. ## What does User aborted the command mean in Atlas? User aborted the command is the Atlas bash metadata telling you that you interrupted the cargo run yourself, not that it timed out. Of the 2 ways a command ends early in Atlas, only the timeout carries diagnostic signal, so an abort means re-run rather than start diagnosing a hang. Without that distinction, an agent chasing a slow Rust build can spiral: you cancel a cargo test run because you got impatient, the agent reads the truncated output, concludes the suite is hanging, and starts investigating a problem that does not exist. Atlas labels your interrupt as your interrupt. The correct follow-up to User aborted the command is simply to re-run, possibly with a larger timeout, rather than to start diagnosing a hang. Atlas reads the metadata, not just the output, on every bash call. ## How does Atlas keep a hanging Rust command from doing damage? Every Atlas tool call is permission-gated against 3 rule types, allow, ask, and deny, before it runs, so a cargo command that hangs is one you approved in a crate you pointed Atlas at. Atlas also drafts a plan in a read-only plan agent and asks before switching to a build agent. A hang is an inconvenience, but the commands that hang, a cargo build fetching remote dependencies, a script waiting on a credential, are exactly the ones with network and filesystem reach. The permission gate is what keeps them inside the boundary you set. Start atlas in a crate with a Cargo.toml and it reads your modules, traits, and cargo workspace. rustfmt and clippy run under the same rules, and Atlas snapshots file changes as git patches so any edit made while unsticking a build can be diffed and rolled back. ## Steps 1. Run atlas in a crate with a Cargo.toml and let Atlas read your modules, traits, and cargo workspace. 2. Run the cargo command through the bash tool and read the shell_metadata block in the output when it is killed. 3. Decide from the message whether the cargo command is slow or blocked: Atlas explicitly calls out the interactive-input case. 4. If it is blocked, re-run with the tool's non-interactive flags (-y, --no-input, CI mode) so the command cannot prompt for stdin. 5. If it is genuinely slow, for example a cold cargo build or a large cargo test workspace run, retry with a larger timeout value in milliseconds as the message instructs. 6. If you aborted it yourself, the metadata says User aborted the command, which distinguishes your interrupt from a timeout; re-run rather than diagnose a hang. 7. Once cargo test completes, run rustfmt over any files you touched while unsticking the build. 8. Review the unified diff Atlas surfaces for any edit before it writes, and let cargo build confirm the crate still compiles. ## FAQ ### why does cargo build hang forever when run by an AI agent Usually because it is blocked on interactive input, such as a credential prompt for a private git dependency in Cargo.toml, not because it is slow. Atlas races the command against a timeout and explicitly calls out the interactive-input case in its message. ### how do I tell if a Rust command is slow or stuck Read the shell_metadata block the Atlas bash tool returns when the command is killed. 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. That second clause is the diagnosis. ### how do I stop a command from prompting for stdin in an agent session Re-run it with the tool's non-interactive flags: -y, --no-input, or CI mode. A command that cannot prompt either succeeds or fails with a real error, which is strictly more useful than hanging indefinitely. ### what timeout should I give a slow cargo test run Large enough that a cold cargo build of the full workspace can finish. Atlas passes a timeout value in milliseconds to the bash tool, and when a run is killed the message instructs you to retry with a larger value if the command is expected to take longer. ### what does User aborted the command mean It means you interrupted the run yourself. The Atlas bash metadata reports it distinctly from a timeout, so an aborted cargo build is not mistaken for a hang. The right response is to re-run, possibly with a larger timeout, not to start diagnosing. ### does Atlas work with cargo and rustfmt Yes. Start atlas in a crate with a Cargo.toml and it reads your modules, traits, and cargo workspace. It runs cargo test, cargo build, and rustfmt through the bash tool, which is a real shell, and can fix borrow-checker errors and clippy warnings. ### can Atlas run a cargo command without my approval No. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. Atlas also drafts a plan in a read-only plan agent and asks before switching to a build agent that can change files. --- Canonical HTML: https://runatlas.sh/resources/stacks/diagnose-a-hanging-or-long-running-command-in-rust Source of truth: aeo_pages row `/resources/stacks/diagnose-a-hanging-or-long-running-command-in-rust` (segment: Stacks) (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.