How to Increase Claude Code Tool Output Limits

The short answer

The two controls arrived in Claude Code 2.1.261 on September 4, 2026. They solve a narrow problem: a command ran, the evidence exists, but too little of it reached the model inline.

These are character limits, not token limits. Think of them as the width of a delivery hatch. Opening the hatch gives Claude more of the log at once, but every extra line that passes through also occupies room in the session.

First recover the missing output

A larger limit is not the first move. Recover the full log, locate the missing evidence, and only then decide whether that class of command deserves more inline room.

For a successful command, Claude Code sends roughly 30,000 characters inline by default. If the output is longer, Claude gets a short preview from the start and a path to the saved output file in the session directory. Ask Claude to read or search that path. That usually costs less context than pushing the entire log into every similar turn.

A failed command behaves differently. Claude receives a roughly 10,000-character head-and-tail excerpt when the output is too long, with no saved-file path in the result. If the missing stack trace sits in the middle, rerun while writing the complete output to a known file:

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

The file .claude/logs/test-full.log is now the source of truth. Ask Claude to search it for failed test names, exceptions, and stack traces instead of pasting the whole file into chat. This also preserves the original exit code as visible evidence.

Background commands already report the file they are writing to when they move into the background. Anthropic now marks TaskOutput as deprecated and recommends Read on that output path, which is often the cleaner recovery route.

Make the smallest useful change

If the same successful command routinely needs more than the default window, raise only bashOutputMaxChars. A 60,000-character starting point roughly doubles the default inline allowance without accepting the full 128,000-character ceiling:

{
  "bashOutputMaxChars": 60000
}

Put that object in the scope that matches the problem:

Run /status to confirm which file Claude Code loaded. Then rerun the same command and compare its wc -c count with the number you chose. If the log is still larger, Claude Code should again provide a preview and saved-file path for a successful result.

For a background task, use taskOutputMaxChars instead. The same 4,000 to 128,000 character range applies. When a finished background task still exceeds the limit, Claude receives the most recent characters, so the output file remains the reliable place to inspect the full history.

Both settings override their older environment-variable counterparts. When bashOutputMaxChars is present, Claude Code ignores BASH_MAX_OUTPUT_LENGTH. When taskOutputMaxChars is present, it ignores TASK_MAX_OUTPUT_LENGTH. Mixing both controls makes troubleshooting harder, so keep one source of truth.

The context bill moves, it does not disappear

Moving a successful command from the roughly 30,000-character default to 60,000 can remove a separate file-reading step when the complete result fits. It can also place up to roughly 30,000 more characters into the session immediately. At 128,000, the allowed window is a little more than four times the default successful-command window.

There is no honest fixed conversion from that character increase to tokens or dollars. Source code, JSON, prose, and Unicode tokenize differently, and your billing or allowance depends on the model and account path. The practical budget is simpler:

• Raise a limit when the omitted middle contains evidence Claude repeatedly needs.
• Keep the default when one targeted search of the saved file answers the question.
• Lower a project exception after the noisy investigation ends.
• Do not raise both settings because one command was clipped once.

This is the complement to reducing Claude Code skill context cost. Skill metadata occupies context before work begins. Tool output arrives during the work. Fixing one does not fix the other.

Seven workflows that benefit, ranked

1. Monorepo test summaries

A release engineer running a large test suite can get a successful result whose package summaries and warnings exceed the default inline window. Raising bashOutputMaxChars for that repository can keep the complete summary in the first result. The payoff is fewer follow-up reads during every release check, provided the output actually fits the chosen limit.

2. Background integration environments

A platform team may leave a local server, emulator, or integration environment running as a background task while Claude works elsewhere. Raising taskOutputMaxChars lets Claude receive more recent output when it checks that task. The full task file still matters because the setting favors the latest characters after overflow.

3. Compiler and linter warning sweeps

An application team can finish a build successfully while producing thousands of warnings. A wider successful-command window can expose warnings from packages that would otherwise sit beyond the preview. That pays when the team is cleaning a warning backlog and needs the complete result more than it needs a lean session.

4. Database migration dry runs

A data engineer can run a successful dry run that prints every proposed schema action. Keeping a bounded plan inline lets Claude compare related changes in one result. The benefit is review continuity, but only after secrets and production identifiers are excluded from the log.

5. Dependency and license audits

A security engineer can receive a long successful inventory with findings spread across the middle. A repository-scoped Bash limit can make the whole bounded report available for one audit session. The payoff is less chance that a package disappears merely because it was outside the preview.

6. Flaky test investigations

A QA engineer needs the exact sequence around a sporadic failure, yet the failed-command result exposes only a head-and-tail excerpt. Raising the Bash setting does not remove that failure behavior. Saving the rerun to a known file, then searching a narrow time or test-name range, preserves the evidence without filling the session.

7. Verbose code generators

A developer running a generator may need its complete success report once, perhaps to verify every created or skipped file. A temporary local setting can widen that result for the investigation, then be removed. The payoff is a cleaner audit of generated changes without turning a one-off exception into a permanent team default.

If you are new to the settings layout, the broader Claude Code setup guide explains where the tool fits before you tune this edge case.

What is worth building

Best opportunity: a context-aware log broker

Build a local command wrapper for AI coding teams that always stores the raw log, measures its character count, indexes important ranges, and returns a compact manifest with paths. It should recommend a per-command inline limit only when the same evidence is repeatedly retrieved.

The adjacent demand is small but commercially sharp. US keyword data estimates 320 monthly searches for log analyzer, with transactional intent and a $60.95 cost per click. Existing observability budgets confirm that log handling already has buyers: Better Stack lists a 40 GB logs, traces, and metrics bundle at $25 per month billed yearly, plus AI SRE chat at $5 per million tokens. Those products cover a wider job, but the spend is evidence that teams pay to find signal in logs.

The smallest sellable version is a cross-platform wrapper, a local log directory, a character counter, a failure index, and a report Claude can read selectively. The catch is trust. Build logs can contain credentials, customer data, and proprietary paths, so local-first storage and clear redaction rules are part of the product, not polish. This is the strongest opportunity because it solves the recurring decision behind the setting, not just the JSON edit.

Niche opportunity: a test-evidence packer

Build an adapter that runs common test frameworks, preserves the untouched log, and gives Claude a short evidence map containing failed test names, stack-trace ranges, and the file path for deeper inspection. QA and developer-experience teams would pay when one noisy suite creates the same triage work every day.

The query test failure analysis draws an estimated 20 US searches a month, with low competition and keyword difficulty 11. That is not enough demand for a broad standalone SaaS pitch. It is enough to justify a focused feature inside the log broker or a paid tool for teams with expensive test suites.

An MVP needs two or three runner adapters, deterministic raw-log storage, and a side-by-side view of extracted evidence versus source lines. The catch is fragmentation: Jest, Pytest, Gradle, and custom runners format failures differently, and an overconfident extractor can remove the clue Claude needed. The raw file must always remain one read away.

Where this setting does not help

This control does not buy more Claude messages, raise a weekly allowance, expand a model's context window, or bypass a tool-use cap. It only changes inline character handling for two local Claude Code result paths.

It also does not make unlimited output safe. Successful command output saved by Claude Code is truncated past 64 MiB, and a command is killed if its streamed output passes 5 GB. More importantly, a 128,000-character inline result can crowd out useful conversation context. The maximum is a guardrail, not a recommendation.

Cloud sessions add one scope trap. They read a committed .claude/settings.json, but not the user or local settings files on your machine. Only server-managed organization settings reach those sessions. If a value appears ignored, check /status before changing it again.

If you want a context-aware developer workflow built around your own test and log systems, AI production systems is the right place to start.