Atlas kills a bash command and reports "shell tool terminated command after exceeding timeout <n> ms" because the shell tool races the process against an Effect.sleep of timeout + 100 ms, and on expiry it kills the command, marks the run expired, and appends that metadata line to the output. The fix the message itself gives you is the right one: retry with a larger timeout value in milliseconds. Before you do, check whether the command is actually blocked waiting for interactive input, because the message calls that out for a reason. It is the common cause, and raising the timeout on a command that is waiting for a prompt just makes you wait longer.
Why does Atlas terminate a bash command after a timeout
Atlas terminates a bash command because the shell tool races the process against an Effect.sleep of timeout + 100 ms. When that sleep wins the race, Atlas kills the command, marks the run expired, and appends "shell tool terminated command after exceeding timeout <n> ms" to the shell_metadata block in the output.
The timeout is a hard ceiling, not a suggestion, and the 100 ms of slack exists so a command finishing right at the boundary is not killed by a rounding artifact. Everything past that boundary is terminated. The output you get back is whatever the command produced before it was killed, plus the metadata line explaining why it stopped, so a partially useful run is not thrown away. The design matters for an agent: without a ceiling, a hung command holds a tool call open indefinitely and the session stalls with no explanation. With one, you get a bounded failure and a message that names both the limit and the retry.
How to fix an Atlas bash timeout by raising the limit
Fix an Atlas bash timeout by re-running with a larger timeout value in milliseconds, exactly as the message instructs. The parameter is in ms, so a build that needs five minutes wants 300000, not 300. Raise the limit to fit the job rather than nudging it up in small increments.
Pick a number with the real work in mind. A test suite that takes four minutes on a cold cache and ninety seconds on a warm one needs headroom for the cold case, because the timeout is enforced against the run you actually get, not the run you usually get. Overshooting is cheap: the ceiling only fires if the command hangs. Undershooting costs you the whole run plus a retry. The one place to be careful is that a large timeout on a command that is genuinely stuck means you wait the full window before learning anything, which is why the interactive-input check comes first and the timeout increase comes second.
Is the Atlas bash command waiting for interactive input
Check whether the command is blocked waiting for interactive input before you raise the Atlas timeout. The message calls this out explicitly because it is the common cause: a command sitting at a confirmation prompt will consume any timeout you give it, whether that is 30000 ms or 300000 ms.
Interactive prompts are the classic trap for an agent-run shell. A package manager asking to confirm an install, a migration tool asking whether to proceed, a git operation dropping into an editor, a CLI asking for a password: none of these will ever complete, because there is nobody at the keyboard. The fix is to make the command non-interactive rather than to give it more time. Add -y, add --no-input, add the CI flags the tool provides. A command that cannot ask a question cannot hang on one. If you are not sure whether a command prompts, assume it might and pass the non-interactive flag anyway. The flag costs nothing when it is unnecessary.
How to run long jobs in Atlas without holding the tool call open
For genuinely long jobs in Atlas, run them in the background rather than holding the tool call open for the entire duration. A build that runs for 10 minutes does not need to block the agent's turn, and a background run sidesteps the timeout ceiling instead of fighting it.
The trade is between attention and throughput. A foreground bash call blocks the session until it returns, which is right for a fast command whose output you need before you can decide the next step. A long job that you will check on later is better off in the background, where it runs while the agent does something else. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so parallelism is already part of how the tool is meant to be used. Reserve high timeouts for commands you truly need to wait on, and push the rest into the background.
How to verify the Atlas timeout fix worked
Verify the Atlas bash timeout fix by re-running the command and checking the shell_metadata block: a successful run does not contain "shell tool terminated command after exceeding timeout <n> ms". If the line reappears at 300000 ms, the command is hanging rather than running slowly.
That distinction is the whole diagnosis. A command that genuinely needed more time completes once you give it more time, and the metadata line disappears. A command that hangs will burn any budget you hand it and produce the same termination line at 30000 ms, at 300000 ms, and at every value in between. When you see the second pattern, stop raising the number and go looking for the prompt. Add the non-interactive flag, or run the command with output you can inspect, and find out what it is waiting for. Raising a timeout twice and getting the same message twice is the signal to change tactics, not to raise it a third time.
How to fix it
- 01Re-run with a larger `timeout` (milliseconds) on the bash call, as the message instructs. The parameter is in ms, so 120000 is two minutes.
- 02Check whether the command is actually blocked waiting for interactive input. The message calls this out because it is the common cause, and a bigger timeout does not help a command sitting at a prompt.
- 03Make long-running commands non-interactive by adding -y, --no-input, or CI flags so they never stop to ask a question.
- 04For genuinely long jobs, run them in the background rather than holding the tool call open for the whole duration.
- 05Re-run and confirm the shell_metadata block no longer contains the terminated-after-timeout line.
Frequently asked questions
- what does shell tool terminated command after exceeding timeout mean in Atlas
- The Atlas shell tool races the process against an Effect.sleep of timeout + 100 ms. On expiry it kills the command, marks the run expired, and appends that line to the shell_metadata block. The command ran longer than its allotted window.
- how do I increase the bash timeout in Atlas
- Re-run with a larger `timeout` value on the bash call. The parameter is in milliseconds, so five minutes is 300000.
- why does my Atlas command time out even with a bigger timeout
- The command is probably blocked waiting for interactive input. Atlas calls this out in the message because it is the common cause, and a stuck command consumes any timeout you give it.
- how do I make a command non interactive for Atlas bash
- Add the tool's non-interactive flags, for example -y, --no-input, or its CI flags. A command that cannot stop to ask a question cannot hang on a prompt.
- is the Atlas bash timeout in seconds or milliseconds
- Milliseconds. The message itself says to retry with a larger timeout value in milliseconds, so passing seconds gives the command far less time than you intended.
- should I run a long build in the Atlas foreground
- No. For genuinely long jobs, run them in the background rather than holding the tool call open. That avoids the timeout ceiling and lets the agent keep working.
- how do I confirm my Atlas bash command is no longer timing out
- Re-run it and inspect the shell_metadata block. A successful run does not include the shell tool terminated command after exceeding timeout line.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with NVIDIA NIM: Free-Tier Open Weights and the Nemotron Home Turf in 2026
Run Atlas on NVIDIA NIM: most endpoints listed at $0/$0 per Mtok, Nemotron 3 Ultra 550B at 1,000,000 tokens for $0.50/$2.50. Setup, rate limits, and catalog noise.
Atlas for C in 2026
Atlas is a terminal-native AI coding agent for C in 2026. Run it in a project with a Makefile, have it find memory leaks or add Unity tests, and review the diff.
Atlas for WebAssembly: Terminal-Native AI Coding in 2026
Atlas is a terminal-native AI coding agent for WebAssembly. Audit wasm-bindgen exports, batch calls across the JS boundary, and run wasm-pack test --node in 2026.
Atlas with Snowflake Cortex in 2026: Claude Opus 4.8 Inside Your Snowflake Boundary
Atlas with Snowflake Cortex in 2026: Claude Opus 4.8 and Claude Fable 5 at a 1,000,000 token context, governed by Snowflake RBAC and billed in Snowflake credits.
Atlas with DeepSeek V3.1 (open weights): Togglable Thinking in 2026
Run Atlas on DeepSeek V3.1 (open weights) in 2026. One MIT-licensed checkpoint with thinking and non-thinking modes, $0.25 per Mtok in and $0.95 per Mtok out.
Atlas with GPT-5.1 Codex mini: Wide Subagent Fan Out in 2026
GPT-5.1 Codex mini in Atlas: an OpenAI fast tier at $0.25 per Mtok input, $2 per Mtok output, built for parallel subagents, bulk sweeps, and cheap summaries.
Atlas with Code Llama 34B (Ollama): The Practical Top of the Line in 2026
Code Llama 34B (Ollama) is 19GB, roughly 21GB to serve, with a 16K context and Free (self-hosted) pricing. Atlas setup, why 34B is the last sane size, for 2026.
Atlas with Qwen3-Coder 480B-A35B Instruct: The Open Frontier Coder in 2026
Qwen3-Coder 480B-A35B Instruct in Atlas: 480B total parameters, 35B active per token, 262,144 tokens of context, $1.50 per Mtok in and $7.50 per Mtok out.