When a TypeScript command hangs, the question is always the same: is it genuinely slow, or is it silently waiting for input that will never arrive? Atlas answers it. Atlas's bash tool races every command against a timeout and, when the timeout expires, tells you 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 pnpm install stalled on an auth prompt, or a vitest run sitting in watch mode waiting for a keypress, is blocked on stdin and will never resolve by waiting. A tsc build over a large tsconfig.json project genuinely needs more milliseconds. Atlas's shell_metadata block distinguishes the two, and it distinguishes both from the case where you aborted the command yourself.
Why does a pnpm or vitest command hang forever instead of finishing?
A pnpm or vitest command hangs for 1 of 2 reasons. Either it is genuinely slow, like a tsc build over a large tsconfig.json project, or it is blocked on stdin, like a pnpm install waiting on a registry auth prompt. Waiting fixes the first and never fixes the second.
The blocked-on-stdin case is the most common cause of an apparently hung TypeScript command, and it is the one that never resolves by waiting. A pnpm command can prompt for a registry token. A vitest run started without a run mode can drop into watch and sit waiting for a keypress. A prettier invocation reading from stdin with no piped input will simply block. Every one of these looks identical from the outside: no output, no exit, no error. The distinction only becomes visible when something tells you which of the two you are looking at, and that is precisely what Atlas's bash timeout message does.
What does Atlas's bash tool do when a TypeScript command times out?
Atlas's bash tool races every command against a timeout given in milliseconds, so 120000 gives a pnpm build 2 minutes. When the timeout expires Atlas kills the process and returns a shell_metadata block whose message says to retry with a larger timeout if the command is expected to take longer and is not waiting for interactive input.
The message is written as a diagnosis, not just a notice. "If the command is expected to take longer and is not waiting for interactive input" is a conditional the reader has to evaluate, and evaluating it is the whole triage step. For a TypeScript project, ask: does this pnpm script genuinely need more than the timeout allowed, or is it sitting on a prompt? A tsc type-check across a monorepo's tsconfig.json references legitimately takes minutes. A pnpm install waiting on a token takes forever. Atlas surfaces the shell_metadata block in the bash output, and reading it is step one of the workflow.
How do you unstick a TypeScript command that is blocked on interactive input?
Atlas's documented fix is to re-run the blocked TypeScript command with non-interactive flags so it cannot prompt. The 3 named options are -y, --no-input, and CI mode, which is exactly how you stop a pnpm install or a vitest watch session from waiting on a keypress that never comes.
Once the diagnosis says blocked, the fix is to remove the prompt rather than extend the wait. Most TypeScript tooling exposes a non-interactive mode: a CI environment variable, a -y flag, a --no-input flag. Running the command that way turns a silent hang into either a clean run or a loud failure, and a loud failure is strictly more useful. Atlas's bash tool is a real shell, so setting CI=true or passing -y works exactly as it does in your own terminal, and every bash call is permission-gated against allow, ask, and deny rules before it runs, so you see the flags before the command executes.
How do you give a slow TypeScript build a longer timeout in Atlas?
Atlas takes the timeout as a millisecond value, so retry a genuinely slow command with a larger one, for example 600000 for a 10 minute ceiling. A pnpm build running tsc across a monorepo, or a full vitest suite with integration specs, can exceed a modest default without being blocked on anything.
Extending the timeout is the correct response to real slowness and the wrong response to a blocked command, which is why the diagnosis has to come first. Atlas's bash tool takes the timeout in milliseconds, so a long pnpm build gets a value sized to the work. Once the run completes, the ordinary rules apply: output over the limit is truncated with the full log saved to a file you can read, so a verbose tsc or vitest run does not flood context. prettier, being fast, almost never needs this treatment, which itself is a signal: if prettier is hanging, it is blocked, not slow.
How do you tell a timeout from a command you aborted yourself?
Atlas distinguishes the 2 cases in the metadata. If you interrupted a running pnpm or vitest command, the shell_metadata says User aborted the command, which is a different message from the timeout message. Reading the metadata rather than guessing from the absence of output is what keeps the diagnosis honest.
Three outcomes look similar from the terminal: the command timed out, the command is still blocked, or you hit interrupt. Atlas's bash tool tells them apart explicitly. "User aborted the command" in the metadata means your interrupt ended it, and nothing is wrong with the command itself. The timeout message means Atlas killed it after the allotted milliseconds and hands you the slow-versus-blocked question. Reading the shell_metadata block, with the read tool if the full log was saved to a file, is how a TypeScript developer gets a real answer instead of re-running the same pnpm command and hoping.
Step by step
- 01Run atlas in a TypeScript project that has a tsconfig.json, so Atlas can read your type definitions, path aliases, and strictness settings.
- 02Run the suspect command through the bash tool, for example a pnpm script, a tsc build, or a vitest run, and read the shell_metadata block in the output when it is killed.
- 03Decide from the message whether the command is slow or blocked: Atlas explicitly calls out the interactive-input case in its timeout message.
- 04If the metadata says "User aborted the command", your own interrupt ended it, which is a different situation from a timeout and needs no fix.
- 05If the TypeScript command is blocked, re-run it with the tool's non-interactive flags, such as -y, --no-input, or CI mode, so pnpm or vitest cannot prompt for input.
- 06If the command is genuinely slow, such as a tsc build across a large tsconfig.json project, retry with a larger timeout value in milliseconds as the message instructs.
- 07Read the saved log file with the read tool if the output was truncated, so you triage against the complete pnpm or vitest output rather than a tail.
- 08Once the command completes, run prettier over any files you changed and re-run the vitest suite to confirm the project is back in a known good state.
Frequently asked questions
- why does my pnpm install hang forever in a terminal AI agent
- Most likely it is blocked on stdin, waiting for a registry auth prompt that will never be answered. Atlas's bash tool times the command out and its message explicitly calls out the interactive-input case. Re-run with a non-interactive flag such as -y or CI mode rather than a longer timeout.
- how do i know if a tsc build is slow or actually stuck
- Read the shell_metadata block Atlas returns when the bash timeout expires. The message tells you to retry with a larger timeout only if the command is expected to take longer and is not waiting for interactive input. A large tsconfig.json project is slow; a prompt is stuck.
- vitest never finishes when run by an AI agent, what is wrong
- A vitest run started without a run mode can drop into watch and wait for a keypress, which looks identical to a hang. That is the blocked-on-stdin case. Re-run with the non-interactive option or CI mode so vitest cannot wait for input.
- how do i increase the command timeout in atlas
- Atlas's bash tool takes a timeout in milliseconds, and the timeout message instructs you to retry with a larger value when the command is genuinely slow and not waiting for interactive input. Size the value to the work, for example a full tsc build across a monorepo.
- what does User aborted the command mean in atlas
- It means your own interrupt ended the process, not a timeout. Atlas's bash metadata reports it explicitly so you can tell an interrupt apart from a killed-on-timeout run, and so you do not go looking for a bug in a pnpm or vitest command that was fine.
- atlas bash output was truncated, where is the full log
- The complete log is written to a retained file and the path appears in the truncation header. Read it with Atlas's read tool so you triage against the whole tsc or vitest output rather than the last few lines, which are usually the least informative.
- can atlas run pnpm scripts from a typescript project
- Yes. Atlas's bash tool is a real shell, so pnpm scripts, tsc, vitest, and prettier all run exactly as they do in your own terminal. Every bash call is permission-gated against allow, ask, and deny rules before it runs, so you see the command first.
- does atlas need my tsconfig to work on a typescript project
- Atlas's documented TypeScript setup is to run atlas in a project with a tsconfig.json and let it read your type definitions, path aliases, and strictness settings. That context is what lets it reason about a build that is timing out across project references.
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 TypeScript in 2026
In 2026, TypeScript developers leverage Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas understands your types, ensures code quality, and offers robust safety features.
Migrate a Deprecated API Across Every TypeScript Callsite With Atlas (2026)
Move a TypeScript codebase off a deprecated function without missing a caller: Atlas enumerates with lsp findReferences, tracks with todowrite, patches with apply_patch.
Research a Third-Party API Before Integrating It in TypeScript with Atlas (2026)
Atlas fetches live API documentation with webfetch, then generates typed TypeScript clients from the real response shapes instead of inferring interfaces from memory.
Extract a Shared Helper From Duplicated Code in TypeScript With Atlas (2026)
How to extract a shared helper from duplicated TypeScript code with Atlas in 2026: codebase_search finds the copies, apply_patch swaps them, vitest proves it.
Debug a Single Failing Test in TypeScript with Atlas (2026)
Fix one failing TypeScript test in 2026 without loosening the assertion: Atlas isolates it with pnpm vitest, follows the types with lsp, and edits the module, not the expectation.
Audit a Repo With Parallel Subagents in TypeScript with Atlas (2026)
How to audit a TypeScript monorepo with parallel Atlas subagents in 2026: fan out read-only explore tasks per package, merge findings into todowrite, then run vitest.
Plan a Multi-File Change Before Editing in TypeScript with Atlas (2026)
Atlas plans multi-file TypeScript changes in a read-only plan agent that denies every edit tool, so you approve the design before pnpm, vitest, or prettier ever run.