Fixing Roo Code Terminal Output Truncation on Long-Running Commands

The Problem

Roo Code runs a shell command that produces a lot of output — a full test suite, a verbose build, a large dependency install — and the command completes without error at the process level. But the output actually fed back into the agent's context is only a partial slice: the beginning is missing, a marker like "[...output truncated...]" appears somewhere in the middle, or only the tail end of a very long stream is visible. The agent then either misses the actual error entirely or has to re-run the same expensive command repeatedly, hoping the relevant line lands somewhere it can see this time.

Why It Happens

Terminal output capture is capped by design, not by accident

Roo Code, like other agentic coding tools, limits how much raw terminal output gets captured and fed into a single tool result. Passing an unbounded stream of text into the model's context would blow through the context window and cost a large number of tokens for very little benefit in the overwhelming majority of cases, so a fixed cap — commonly weighted toward the most recent lines — is applied. For short commands this limit is never reached and is completely invisible; it only becomes a practical problem once a command's output genuinely exceeds it.

The most useful line is often not near the end of the output

Test frameworks and build tools frequently print the actual failure — a stack trace, a compile error, a specific assertion failure — once, early or in the middle of a run, and then continue emitting progress indicators, per-file status, or summary noise for everything that follows. A capture strategy weighted toward the tail of the output can genuinely omit the single line the whole debugging session actually needs, while faithfully preserving thousands of lines of routine progress output that were never useful in the first place.

The Fix

1. Redirect noisy commands to a file instead of relying on live captured stdout

npm test > /tmp/test-output.log 2>&1

Once the full output exists as a file on disk, it's no longer subject to the tool's per-call capture limit at all — the command's actual output size stops being a constraint, and the file can be searched or read in targeted slices afterward instead of relying on whatever fit in the original captured window.

2. Grep for the actual signal instead of reading the file linearly

grep -n -iE "error|fail|exception" /tmp/test-output.log

Searching for known failure keywords across the entire redirected output finds the relevant lines regardless of where they landed in a multi-thousand-line log, rather than assuming the interesting content is near the beginning, middle, or end — a search is far more reliable than a positional guess about where a failure typically appears.

3. Reduce the command's own verbosity where a quiet or summary mode exists

# instead of a fully verbose run:
npm test --reporter=dot
# or a summary-only build:
./gradlew assembleRelease --quiet

Many test runners and build tools support a less verbose output mode specifically for CI or automated contexts — reducing noise at the source means the meaningful signal is more likely to fit within the captured window in the first place, rather than fighting truncation after an unnecessarily verbose run has already happened.

4. Don't blindly re-run an expensive command hoping to catch the error this time

Re-executing a slow test suite or build repeatedly, each time hoping the relevant error lands somewhere visible, wastes real time and doesn't reliably solve the underlying capture limitation anyway. Once a command's output has already been redirected to a file on a prior run, that file can simply be searched again rather than re-running the command itself.

Why This Works

Each fix routes around the same underlying constraint rather than fighting it directly: redirecting to a file removes the tool's capture limit from the equation entirely, since the constraint only applies to what gets returned from a single tool call, not to what a command can write to disk. Grepping instead of reading positionally treats the actual problem correctly — finding a specific line in a large body of text — rather than assuming a fixed location. And reducing source verbosity shrinks the problem before it ever needs a workaround.

Conclusion

Truncated terminal output in Roo Code on long-running commands is a deliberate, sensible limit on how much raw text gets fed into a single tool result — not a bug, and not something a repeated re-run reliably solves. Redirect noisy commands to a file and search it with grep for the actual failure rather than relying on live captured output, reduce a command's own verbosity where a quieter mode exists, and treat a truncated result as a signal to change approach rather than a reason to re-run the same expensive command again.