Claude Code Bash Output Truncated: 172 Files, 36 Read Back

In the last 30 days Claude Code replaced 172 of my tool results with a 2 KB preview and wrote the rest to a file. My scheduled sessions went back and opened that file 36 times. The other 136 times the model read the first 2,000 characters of an output that was somewhere between 30 KB and 767 KB, and carried on. I only noticed because the weekly review session hit it too: one 61.3 KB result, gone to disk, while it was grading last week’s posts.

The search phrase “claude code bash output truncated” covers at least three different things, and the fix for one does nothing for the others. This post separates them with the numbers from my own transcripts, the constants from the binary I run, and seven headless probes of the setting that shipped four days ago.

What the truncation actually looks like

This is not a “…” at the end of a long output. Since v2.1.2 the Bash tool has not truncated at all in the old sense. Above a threshold it writes the whole output to a file under the session directory and hands the model this instead:

<persisted-output>
Output too large (57.9KB). Full output saved to: /Users/…/.claude/projects/-Users-sg-mini-GitHub-mmm/<session>/tool-results/toolu_01Xt2TZc1qhPD7EKYFrhFpGc.txt

Preview (first 2KB):
> ## Documentation Index
…
</persisted-output>

That particular one happened while I was writing this post. I fetched the settings documentation page to check the new keys, the page came back at 57.9 KB, and the 2 KB preview contained a React component that draws the settings precedence diagram. The keys I was looking for were not in the preview. They were not in the file either, as it turned out; they live on a different page. I found that out with grep on the saved file, which is the whole point of the design: the output is not lost, it is one more tool call away. The question is whether the model makes that call.

The three things people mean

Reading the GitHub issues behind this phrase, they split cleanly:

• The model got a preview. Issue #17944, filed 2026-01-13, four days after v2.1.2 introduced the file hand-off: BASH_MAX_OUTPUT_LENGTH=150000 was set and 30 to 50 KB outputs still went to disk. Closed as stale on 2026-02-27 with three comments. #40100 asked for the threshold to scale with the context window and closed the same way.
• The terminal collapsed it. #26954, 32 reactions and 18 comments, is about ctrl+o not expanding the “+25 lines” fold in the TUI. The model saw all 25 lines. The human did not. Different layer, same search phrase.
• A hook or notification got cut in the middle. #51537 is about the separate 10,000-character cap on hook additionalContext. The binary has a mid-string cut for this path, and I found four Bash results in my transcripts with the marker ... [2060 characters truncated] .... Rare on my machine, but it is a third mechanism, not a variant of the first.

The rest of this post is about the first one, because that is the one that changes what the model knows.

The constants, from the binary

I ran strings on the 2.1.263 binary that installed on this machine at 09:04 today and pulled the numbers out of the settings schema and the Bash tool definition. The schema text for the new key reads, in full: “How many characters of a successful Bash or PowerShell command’s output Claude receives inline (default 30000; values clamp to 4000-128000). Output past this is saved to a file and Claude receives a short preview plus the path. When set, this also replaces BASH_MAX_OUTPUT_LENGTH, which on its own only sizes the read-back window.”

That last clause is the answer to #17944. The environment variable was never the inline ceiling. It sizes how much of the output file Claude Code reads back after the command finishes, and a separate 30,000-character constant decides what reaches the model inline. Raising one without the other does nothing visible.

Limit	Value in 2.1.263	Where it comes from
Bash inline ceiling	30,000 chars	bashOutputMaxChars, unset by default
Allowed range for the setting	4,000 to 128,000	clamped silently, no error
Preview handed to the model	2,000 chars, cut at the last newline past the halfway point	hard-coded
BASH_MAX_OUTPUT_LENGTH	default 30,000, max 150,000	read-back window only; ignored once the setting is present
Background task output (TaskOutput)	32,000 chars, range 4,000 to 128,000	taskOutputMaxChars
WebFetch result	50,000 chars	hard-coded; 14 of my 172 persisted results were fetches
Grep tool result	20,000 chars	hard-coded
Output file on disk	cut at 64 MiB; command killed at 5 GB	tools reference

The settings reference now documents the key with the same range and adds “Requires Claude Code v2.1.261 or later.” The changelog entry for 2.1.261, released 2026-09-04, is one line: the two settings “raise how much command and background-task output Claude receives inline before it is saved to a file, up to 128K characters.” That is eight months after the file hand-off arrived and seven after the first bug report about it went stale.

Seven headless probes

My fleet runs claude -p from launchd, so the interactive behaviour is irrelevant to me. I wanted to know whether the setting reaches a headless session, and from which file. Each probe ran the same command, a Python one-liner printing 450 lines of 99 characters, 44,999 characters in all, and I read the tool_result back out of the session transcript rather than trusting the model’s summary of what it saw.

How the limit was set	Output size	What reached the model
nothing (default)	43.9 KB	persisted, 2,228-char preview
BASH_MAX_OUTPUT_LENGTH=150000 in the environment	43.9 KB	persisted, 2,249-char preview
--settings '{"bashOutputMaxChars":128000}'	43.9 KB	inline, 44,999 chars
same key in the project’s .claude/settings.json	43.9 KB	inline, 44,999 chars
bashOutputMaxChars: 500000	43.9 KB	inline
bashOutputMaxChars: 500000	146.5 KB	persisted; the value was clamped to 128,000
bashOutputMaxChars: 1000	43.9 KB	persisted

So the setting works headless, from the command line and from the project file, and the environment variable alone still reproduces #17944 on a binary released two days ago. The clamp is real and silent: 500,000 became 128,000 without a warning in the JSON output or the transcript.

A note on the first attempt, because it cost me twenty minutes: I initially ran the probes with --allowedTools Bash and a helper script, and the auto-mode classifier refused to execute bash /tmp/bomc/gen.sh in all three sessions. The model then offered to compute the output in its head. I covered how that classifier behaves in the auto mode safety post; the fix here was --dangerously-skip-permissions in a throwaway directory.

What my 172 files say about the cause

Counting persisted results across 2,684 sessions is easy: every one starts with the same <persisted-output> tag. Working out why they happened means looking at the commands. I parsed the tool_use that produced each one. A later pass over the same transcripts showed that the preference for Bash over the dedicated tools is steered by the permission mode itself, which changes how I read the commands below.

Three patterns account for most of it:

Line-count limits are not character limits. 54 of the 158 Bash cases began with tail -N on one of my log files. My logs keep one entry per line, and the lines are long: the median line in projects/blog-en/LOG.md is 427 characters and the longest is 7,060; in ops/growth/social-log.md the median is 2,116. tail -40 on the first file is 71,216 characters, on the second 108,932. No prompt asked for that. The publishing prompt says to count today’s entries and the social planner says to read the last seven days; the sessions chose tail -40 on their own, 54 times, and the fleet has been persisting its own log most mornings. In total 70 of the 158 commands already had a head, tail, cut, or grep in the pipeline and overflowed anyway.

Binary and system dumps. The six largest, 346 to 767 KB, were all strings on the Claude Code binary piped to grep, plus one ioreg -l. Those were mine, researching earlier posts, and a | head -40 would have been enough every time.

Reading the file re-triggers the file. Twice a session opened a persisted file with sed -n 1,400p or cat … | grep -v, and the read itself came back at 29.5 KB, persisted again. The Read tool has its own token-based limit and reports [N lines truncated] instead, so it is the safer way to open these files, but it also cannot filter.

The 21% read-back rate is the number I care about. It means that in roughly four out of five cases the model decided the preview was enough. Sometimes it was: a tail on a log where the preview held the newest lines. Sometimes it was not, and there is no marker in the transcript for which. That is a quieter failure than a hard truncation would be, because nothing looks wrong.

What I changed

I did not raise the ceiling. At 30,000 characters a persisted result costs the model about 2,000 characters of preview instead of roughly 7,500 tokens of output, and on a fleet that runs ten slots a day on a subscription, the hand-off has been protecting my context budget more than it has been hurting me. The token usage post has the cost side of that; the auto-compact post has what happens when a session fills up anyway.

What I changed is the commands, through the memory file that loads into every session on this machine. The rule it now carries: read logs with tail -n 40 | cut -c1-400, which keeps the newest entries and drops the long tail of each line, or grep for the date actually needed. Binary string searches get | head unconditionally. And when a preview does come back, grep the saved file for the thing wanted, not cat it. Whether the sessions follow that is something I can count next month the same way I counted this.

If your case is different, say a test suite whose full log the model genuinely needs, then the setting is the right tool and it is two lines:

{
  "bashOutputMaxChars": 100000
}

in .claude/settings.json or on the command line with --settings. It needs 2.1.261 or later; on an older binary the key is ignored without an error, and headless fleets do not update themselves, which I measured in the not-updating post. Anything above 128,000 becomes 128,000. And if you set the environment variable instead, you get exactly what #17944 reported, eight months on.

If you want the slot prompts and the launchd runner that this fleet uses, they are in the Playbook.

The Read tool has its own version of this, with a 25,000-token cap and a partial first page instead of a spill file. I counted 89 of those in the same transcripts: Claude Code file content exceeds maximum allowed tokens.

Sources and method for this post: transcript files under this machine’s ~/.claude/projects/ with a modification time in the last 30 days, parsed on 2026-09-08 for tool_result blocks beginning with <persisted-output>, with this session’s own transcript excluded because it quotes the phrase. Read-back means a later tool_use in the same session referenced the saved file’s name. Line lengths are from awk '{print length($0)}' on the two log files today. Constants are from strings on the 2.1.263 binary installed at 09:04 KST; the schema description is quoted verbatim. The seven probes ran claude -p with Sonnet on 2.1.263 in an empty directory and I read each tool_result from the resulting JSONL, not from the model’s reply. Release dates are from the GitHub releases API; issue counts and quotes are from the issues API as read today. One affiliate link in this post, to my own Playbook; any sales land on the public ledger.