You work out whether a build or script is genuinely slow or silently blocked on input with Atlas by running it through the bash tool and reading the shell_metadata block when the command is killed. Atlas's bash tool races every 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, because a blocked-on-stdin command never resolves by waiting.
How do I tell if a command is hanging or just slow?
Atlas's bash tool races every command against a timeout and, when it expires, names the 2 possibilities and tells you 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.
The distinction between slow and blocked is the entire problem, because the two look identical from outside: no output, no exit, no progress. Atlas's bash tool does not leave you staring at a frozen terminal. It races the command against a timeout, and when the timeout expires it returns a message that names both possibilities and tells you how to distinguish them. A genuinely slow build resolves by raising the timeout. A command blocked on stdin never resolves by waiting, no matter how generous the timeout, because nothing is coming. Reading the message is what tells you which situation you are in.
What is the Atlas shell_metadata block?
The Atlas bash tool returns a shell_metadata block alongside the command output, and reading that block is step 1 when a command is killed. The shell_metadata block carries the structured facts about how the process ended, which is what separates an expired timeout from an abort you triggered yourself.
Command output alone is ambiguous when a command dies. A build that printed nothing and then stopped looks the same whether it timed out, was interrupted, or crashed. The Atlas bash tool attaches a shell_metadata block to the tool result, and that block is where the truth lives. When you run a suspect command through bash and it is killed, the shell_metadata block is the first thing to read, before you start theorizing about the build. The block distinguishes an expired timeout from a user abort, which are two completely different problems with two completely different fixes.
Why is my build waiting for interactive input?
Atlas explicitly calls out the interactive-input case when a command times out, because a blocked-on-stdin command never resolves by waiting. Re-run it through the Atlas bash tool with 1 of the tool's non-interactive flags, commonly -y, --no-input, or a CI mode, so the command cannot prompt and either completes or fails with a real error.
A command running inside an agent loop has no interactive human at the keyboard. When a tool decides to prompt, confirm this destructive action, choose a version, accept a license, the prompt goes nowhere and the process waits forever. Atlas names this case directly in the timeout message rather than making you infer it. The fix is not patience. Re-run the command through the bash tool with the tool's non-interactive flags, which commonly means -y, --no-input, or a CI mode, so the command cannot prompt and either completes or fails with a real error.
How do I fix a command that is genuinely slow in Atlas?
If a command is genuinely slow rather than blocked, the Atlas bash tool in 2026 takes its timeout in milliseconds, so the fix is to retry with a larger timeout value exactly as the timeout message instructs. A build that legitimately needs several minutes needs that number raised, not a different command.
A slow command is not a broken command. Large builds, full test suites, container image builds, and dependency resolution over a cold cache all take real time, and killing them at a default timeout produces a fake failure. Atlas's bash tool accepts an explicit timeout in milliseconds, and when the timeout message says the command may be expected to take longer, raising that value is the correct response. The important discipline is to raise the timeout only after the shell_metadata block and the timeout message have ruled out the interactive-input case, because raising a timeout on a blocked command just wastes more wall time.
How do I tell a timeout apart from a command I aborted myself?
Atlas distinguishes a timeout from your own interrupt in the shell_metadata block, which is the 1 place that record lives. If you aborted the command yourself, the metadata says User aborted the command, a different message from a timeout expiry and a different conclusion about whether the command was actually stuck.
Interrupting a command that felt stuck is a natural reflex, and it destroys evidence unless the system records who did the killing. Atlas's bash tool records it. When the metadata says User aborted the command, the command did not time out, it was stopped, and you learned nothing about whether it would have completed. That distinction keeps the diagnosis honest. If you want to know whether a command is slow or blocked, let the bash timeout expire and read the message, rather than aborting and then reasoning about a hang that Atlas never actually observed.
Where does the human approve when diagnosing a hanging command?
Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so each bash invocation used to diagnose a hanging command passes the permission check first. Diagnosing a hang uses only 2 tools, bash and read, so no file is modified and no diff is generated.
The diagnosis workflow in Atlas is deliberately small: bash runs the command, and read opens whatever log the command left behind. Both are permission-gated tool calls, which means a repository can auto-allow its own build command while still prompting on the retry that adds a --no-input flag or an unfamiliar CI-mode invocation. Nothing in this workflow writes to a source file, so there is no unified diff to approve. If the diagnosis leads to a change, a corrected script or a pinned non-interactive flag in the build config, that change goes through the normal edit path with its own diff.
Step by step
- 01Run the suspect command through the Atlas bash tool and let the timeout expire rather than aborting it, so Atlas actually observes the hang.
- 02Read the shell_metadata block in the bash output when the command is killed. The block is where the structured facts about how the process ended live.
- 03Decide from the message whether the command is slow or blocked. Atlas explicitly calls out the interactive-input case, and its timeout message says to retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input.
- 04If the command is blocked on input, re-run it through bash with the tool's non-interactive flags, which commonly means -y, --no-input, or a CI mode, so it cannot prompt.
- 05If the command is genuinely slow, retry with a larger timeout value in milliseconds, as the timeout message instructs.
- 06If the metadata says User aborted the command, recognize that you interrupted it, not the timeout, and re-run it to get a real diagnosis.
- 07Read any log file the command left behind with the read tool to confirm where it stopped.
Frequently asked questions
- why is my build hanging with no output
- It is either genuinely slow or blocked waiting for interactive input. Atlas's bash tool races the command against a timeout and, when it expires, explicitly calls out the interactive-input case, so you can tell the two apart instead of guessing.
- how do I fix a command that is waiting for input in an AI agent
- Re-run it through Atlas's bash tool with the tool's non-interactive flags, commonly -y, --no-input, or a CI mode, so the command cannot prompt. Waiting will not help, because a blocked-on-stdin command never resolves on its own.
- how do I increase the command timeout in Atlas
- Retry with a larger timeout value in milliseconds, as the bash timeout message instructs. Do that only after the message and the shell_metadata block have ruled out the command waiting for interactive input.
- what is the shell_metadata block in Atlas bash output
- The shell_metadata block is the structured record the Atlas bash tool attaches to a command result. Read it when a command is killed: it distinguishes an expired timeout from an abort you triggered yourself.
- does an AI agent know the difference between a slow build and a stuck build
- Atlas does. Its bash tool races every command against a timeout and the expiry message names both possibilities, telling you to retry with a larger timeout only if the command is expected to take longer and is not waiting for interactive input.
- what does User aborted the command mean in Atlas
- It means you interrupted the command yourself rather than the timeout expiring. Atlas records that in the shell_metadata block so your own interrupt is never mistaken for evidence that the command was stuck.
- should I raise the timeout on a hanging command
- Only if the command is genuinely slow. If Atlas's bash timeout message points at the interactive-input case, raising the timeout wastes wall time, because nothing is ever going to arrive on stdin. Use non-interactive flags instead.
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 in C# with Atlas (2026)
Work out whether a dotnet build is genuinely slow or silently blocked on input, using Atlas in 2026, and get NuGet restore and dotnet test unstuck for good.
Diagnose a Hanging or Long-Running Command in Apache Spark with Atlas in 2026
Quickly diagnose hanging or slow Apache Spark jobs in 2026 with Atlas. Identify if your PySpark script is blocked on input or genuinely slow, then unblock it using Atlas's terminal-native AI agent.
Diagnose a Hanging or Long-Running Command in Objective-C with Atlas in 2026
Objective-C developers in 2026 use Atlas to diagnose hanging `xcodebuild test` or `CocoaPods` commands. Atlas identifies if a process is genuinely slow or blocked on interactive input, providing clear steps to resolve
Diagnose a Hanging or Long-Running Pandas Command with Atlas in 2026
Quickly diagnose if your Pandas script is genuinely slow or silently blocked on input using Atlas. Get unstuck and optimize your DataFrame operations.
Diagnose a Hanging or Long-Running WebAssembly Command with Atlas in 2026
WebAssembly developers in 2026 use Atlas to diagnose hanging or long-running `wasm-pack` builds and scripts. Identify if your WebAssembly command is genuinely slow or silently blocked on input, and get it unstuck
Diagnose a Hanging or Long-Running Gin Command with Atlas in 2026
Gin developers in 2026 can use Atlas to diagnose hanging `go test` runs or slow `go mod` operations. Pinpoint if a command is genuinely slow or silently blocked on input, and get it unstuck quickly.
Diagnose a hanging or long-running Polars command with Atlas in 2026
Quickly diagnose hanging Polars scripts or builds with Atlas. Determine if your `uv` or `pytest` commands are genuinely slow or silently blocked on input, and get unstuck efficiently in 2026.
Diagnose a Hanging or Long-Running Command in COBOL with Atlas in 2026
Diagnose hanging COBOL commands in 2026 with Atlas. Identify if GnuCOBOL cobc builds or COBOL Check tests are slow or blocked on input, and unblock them using Atlas's AI agent.