Atlas prints "...output truncated..." and "Full output saved to: <path>" because Truncate caps tool output at MAX_LINES 2000 and MAX_BYTES 50 KB, and your command produced more than one of those limits allows. Nothing is lost: when the output exceeds either limit, Atlas writes the full text into the truncation directory and prefixes the preview with the saved path. The fix is to read the file named in the message with the read tool to see the full output. The better long-term fix is to narrow the command itself, by adding filters, grep, or --quiet, so the useful part fits inside the preview.
Why does Atlas truncate bash output
Atlas truncates bash output because Truncate caps tool output at MAX_LINES 2000 and MAX_BYTES 50 KB. When a command exceeds either limit, Atlas writes the full text into the truncation directory, prints "Full output saved to: <path>", and shows only the tail of the run in the conversation.
Two limits, either one triggers. A verbose build that emits 5000 short lines hits MAX_LINES 2000 first. A command that emits a single enormous JSON blob hits MAX_BYTES 50 KB first, even if it is only a handful of lines. Both cases produce the same "...output truncated..." prefix and the same saved path. The cap exists to protect the model context: a 4 MB test log would consume the entire window and leave no room for the reasoning that log was supposed to inform. Truncation is not data loss, it is a decision about what goes into context versus what stays on disk until you ask for it.
How to see the full Atlas output after truncation
To see the full output in Atlas, read the file named in the message with the read tool. The truncation notice prints "Full output saved to: <path>", and that path holds the complete text of the run, written to disk before the preview was cut down to the tail at MAX_LINES 2000.
Reading the saved file is the direct answer, but be deliberate about it. If the file is a 3 MB build log, reading the whole thing puts you right back in the situation the cap was preventing, just one step later. Use the read tool with an offset to page through the region you care about, or use grep to search inside large files without loading them. The saved file is a random-access resource, not something to slurp whole. The honest caveat on timing: truncation files are retained for 7 days (RETENTION in truncate.ts), then cleaned up. If you come back to a session from last month, the saved output is gone and you will need to re-run the command.
How to narrow a command so Atlas does not truncate it
Narrow the command so its output fits under MAX_LINES 2000 and MAX_BYTES 50 KB. Add filters, pipe through grep, or pass --quiet so the command emits only what matters. A test run that prints one line per passing test can usually be told to print only the failures instead.
Narrowing beats truncating because it changes what the agent sees, not just what it can retrieve. Truncated output leaves you with the tail of a run, and the tail is frequently the least informative part: the summary line, the exit code, the final stack frame. What you usually want is the first failure, which is buried in the middle of the discarded portion. Piping through grep for the error pattern, or passing the tool's quiet flag, puts the meaningful lines in the preview where the agent reads them immediately. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so once you have an error string, finding the code that produced it is a search away.
Should I redirect output to a file instead in Atlas
Redirecting noisy output to a file yourself is a good pattern in Atlas when you know a command is verbose. Redirect to a file, then read only the section you need, rather than letting Truncate cap the run at MAX_LINES 2000 and hand you back the tail with a saved path you then have to chase.
The difference is control. When Atlas truncates, you get the tail plus a pointer. When you redirect, you get a file you named, in a location you chose, that persists on your terms rather than under the 7 day RETENTION window in truncate.ts. That matters for a log you want to compare against a later run, or for output you plan to grep repeatedly across a long session. It costs one extra shell operator, and it turns a surprise truncation into a deliberate artifact. For a one-off command, letting Atlas truncate is fine. For anything you will look at more than once, redirect.
How to verify the Atlas truncation fix worked
Verify the fix in Atlas by re-running the narrowed command: output that fits under MAX_LINES 2000 and MAX_BYTES 50 KB comes back with no "...output truncated..." prefix and no "Full output saved to: <path>" line. Seeing the complete run inline is the confirmation.
If the truncation notice persists after narrowing, the filter is not tight enough, and the next question is which limit you are hitting. A command that still emits thousands of lines needs a stronger filter. A command that emits few lines but very long ones is hitting MAX_BYTES 50 KB instead, and the fix there is to cut the width of each line rather than the count. Check the shape of the output before you tighten again. And when the run truly must be enormous, stop fighting the cap: read the saved path, page through it with read, or grep inside it. The cap is not an obstacle to work around every time, it is a boundary that tells you when to switch from reading to searching.
How to fix it
- 01Read the file named in the message with the read tool to see the full output. The path appears after "Full output saved to:" in the truncation notice.
- 02Narrow the command itself (add filters, grep, or --quiet) so the useful part fits under MAX_LINES 2000 and MAX_BYTES 50 KB.
- 03Redirect noisy output to a file yourself and read only the section you need, rather than letting the tool truncate for you.
- 04Note that truncation files are retained for 7 days (RETENTION in truncate.ts), then cleaned up, so read the saved file within that window.
- 05Re-run the narrowed command and confirm the "...output truncated..." prefix no longer appears.
Frequently asked questions
- why does Atlas say output truncated
- Atlas's Truncate caps tool output at MAX_LINES 2000 and MAX_BYTES 50 KB. When output exceeds either limit, only the tail is shown and the full text is written to disk.
- where does Atlas save the full output
- Into the truncation directory. The path appears in the message as "Full output saved to: <path>", and you read that file with the read tool to see the complete run.
- how long does Atlas keep truncated output files
- Truncation files are retained for 7 days (RETENTION in truncate.ts), then cleaned up. Read the saved file within that window or you will need to re-run the command.
- what are the Atlas output truncation limits
- MAX_LINES 2000 and MAX_BYTES 50 KB. Either limit triggers truncation on its own, so a few very long lines can truncate just as a few thousand short ones can.
- how do I stop Atlas from truncating my bash output
- Narrow the command so the useful part fits: add filters, pipe through grep, or pass --quiet. A command that emits less output does not hit the 2000 line or 50 KB cap.
- should I read the whole saved output file in Atlas
- Usually not. A large saved file read in full puts you back in the situation the cap was preventing. Use read with an offset, or grep inside the file to find what you need.
- does truncation in Atlas mean I lost output
- No. Atlas writes the full text into the truncation directory and prefixes the preview with the saved path, so the complete run is on disk even though only the tail is shown.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Atlas with GPT-5 Nano: The Cheapest Model in the OpenAI Registry in 2026
GPT-5 Nano in Atlas: $0.05 per Mtok input and $0.40 per Mtok output, the cheapest model in the OpenAI registry, and the right pick for the small_model slot.
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 with Claude Opus 4.1: The Pre Price Cut Opus in 2026
Claude Opus 4.1 runs Atlas on a 200K context at $15 per Mtok input, $75 per Mtok output, with a 32K output ceiling. Setup, cost warnings, and better alternatives.
Atlas vs Amp: Terminal AI Coding Agents in 2026
Compare Atlas, a terminal-native AI coding agent with free core and local embeddings, against Amp, Sourcegraph's agent featuring Oracle and Orbs, for developers in 2026.
Upgrade a Dependency and Fix the Breakage with Atlas (2026 Workflow)
How to upgrade a dependency and fix the breakage with Atlas in 2026: bash drives the package manager, webfetch pulls the release notes, edit fixes each compiler error.
Atlas with Gemma 3 27B (local via Ollama): Setup, Cost, and Tradeoffs in 2026
Run Atlas on Gemma 3 27B (local via Ollama) in 2026: a 131,072 token context, Free (self-hosted) pricing, single-GPU inference, and the honest tradeoffs.
Atlas with GPT-OSS 20B (hosted): the cheap slot that can still think in 2026
Run Atlas on GPT-OSS 20B (hosted) in 2026: $0.03/$0.14 per Mtok on DeepInfra, a 131,072 token context, reasoning on, and $0.00/$0.00 locally in LM Studio.
Atlas for COBOL: Copybooks, PIC Clauses, and GnuCOBOL in 2026
Atlas is a terminal-native AI coding agent for COBOL in 2026. It reads your divisions and copybooks, explains a paragraph before touching it, and compiles with cobc under GnuCOBOL.