Fixed bash output truncation bugPublic

Added inprogress to #2852 successfully.

Issue #2852

Title: When bash tool truncates by line count (but not by byte count), temp file isn't written

What I read

• Full issue body and comments via gh issue view 2852 --json title,body,comments,labels,state
• Linked issues/PRs via GraphQL timeline query
• Result: no comments, no linked issues, no linked PRs

Independent verification

I did not rely on the issue analysis. I traced the actual code path and checked the truncation behavior directly.

Relevant files read in full:

• packages/coding-agent/src/core/tools/bash.ts
• packages/coding-agent/src/core/tools/truncate.ts
• packages/coding-agent/src/core/bash-executor.ts
• packages/coding-agent/src/modes/interactive/components/bash-execution.ts

I also verified that output like seq 3000 is well under the byte threshold but over the line threshold:

• 3000 lines
• 13,892 bytes

So this is a valid reproduction case for line-based truncation without byte-based overflow.

Actual root cause

There are two independent truncation systems involved:

1. Temp file creation in bash execution

   • In packages/coding-agent/src/core/tools/bash.ts
   • Temp file starts only when:
     • totalBytes > DEFAULT_MAX_BYTES

2. Displayed output truncation

   • Final and partial output is truncated via truncateTail(fullText)
   • truncateTail() truncates on either:
     • maxLines default 2000
     • maxBytes default 50KB

These are not aligned.

Exact failure mode

In createBashToolDefinition().execute():

• handleData() increments totalBytes
• Temp file is created only if totalBytes > DEFAULT_MAX_BYTES
• Partial updates call truncateTail(fullText) unconditionally
• Final result also calls truncateTail(fullOutput) unconditionally

If output is:

• more than 2000 lines
• but less than 50KB

then:

• truncateTail() returns truncated: true, truncatedBy: "lines"
• tempFilePath is still undefined
• final message says Full output: undefined
• full output is not persisted anywhere
• some output is effectively lost to the agent/user

So the real bug is:

Full-output persistence is gated only by raw byte count, while displayed truncation is gated by line count or byte count.

That mismatch exists even if the issue description were wrong.

Additional finding

The same design bug also exists in:

• packages/coding-agent/src/core/bash-executor.ts

That path also:

• creates temp file only after totalBytes > DEFAULT_MAX_BYTES
• truncates final output with truncateTail(fullOutput)

So if this issue is fixed only in the tool implementation, the lower-level bash executor will still have the same line-truncation data loss behavior.

Proposed fix

Most concise correct approach

Create the temp file whenever output is known to be truncated and no temp file exists yet.

That means:

1. Keep the current early byte-threshold behavior for large output streaming
2. Add a helper like ensureTempFileFromBufferedOutput()
3. Call it in two places:
   • during partial updates, if truncateTail(fullText).truncated && !tempFilePath
   • before final resolve/reject, if final truncation is true and !tempFilePath

This fixes:

• line-based truncation under 50KB
• byte-based truncation safety if logic changes later
• partial and final consistency

Why this is better than only checking line counts incrementally

You could also track line count while streaming and create the temp file once lines exceed 2000. That works, but it is more error-prone because:

• chunk boundaries can split lines
• final truncation logic already exists and is authoritative
• you still need a final fallback

A final ensureTempFile... check is the minimal robust fix.

Affected files

Must change

• packages/coding-agent/src/core/tools/bash.ts

  • ensure temp file exists whenever truncateTail(...) reports truncation
  • avoid rendering Full output: undefined

• packages/coding-agent/src/core/bash-executor.ts

  • same fix for shared execution path

Likely test coverage to add

Search showed no focused tests for this behavior. Add regression tests around:

• line truncation under byte threshold
• byte truncation over threshold
• fullOutputPath presence when truncation occurs

Likely test targets:

• packages/coding-agent/test/... for tool behavior
• and/or executor-level tests if present nearby

Proposed implementation shape

In packages/coding-agent/src/core/tools/bash.ts

Add a small internal helper that:

• creates tempFilePath
• opens tempFileStream if needed
• writes all buffered chunks into it

Use it:

• in handleData() if truncateTail(fullText).truncated
• in final success path before building details
• in error path if truncated output is being returned

In packages/coding-agent/src/core/bash-executor.ts

Same idea:

• helper to create/write temp file from outputChunks
• call it if final truncateTail(fullOutput).truncated and no file exists

Expected result after fix

For commands like seq 3000:

• output remains truncated in the response
• fullOutputPath is always populated
• full output is recoverable from temp file
• no silent data loss

If you want, I can implement the fix and add regression tests.

No. It is not just display.

What is happening

The bash tool has two separate behaviors:

1. What it shows back to the model/UI

   • It truncates output to the last 2000 lines or 50KB.

2. What it saves to a temp file

   • It only starts saving once raw output exceeds 50KB.

So for output like seq 3000:

• output is truncated for display/context because it exceeds 2000 lines
• output is not saved to a temp file because it is only about 14KB
• the earlier lines are gone from the tool result
• there is no file to recover them from

Why that matters

If this were only a display issue, the full output would still exist somewhere and only the UI text would be wrong.

That is not the case here.

The tool returns only the truncated tail. The omitted lines are not persisted. So the agent cannot:

• inspect them later
• tell the user where to find them
• recover them from the reported temp file path, because there is none

In other words:

• display issue would mean "full data exists, but message is misleading"
• actual bug here is "full data is discarded when truncation happens by line count only"

Concrete example

seq 3000

• full command output: lines 1..3000
• tool returns: roughly lines 1001..3000
• lines 1..1000 are missing
• no temp file contains them

That is data loss, not just presentation.

One smaller display bug on top

There is also a display/message bug layered on top:

bash.ts can produce a notice like:

• Full output: undefined

So yes, there is a display problem too. But the underlying problem is that the missing output was never saved.

If you want, I can break down the exact code path in 10 lines.

Yes.

A clean fix is to make "truncated output" and "full output persisted" use the same condition.

Nice fix

Instead of creating the temp file only when:

• bytes > 50KB

create it whenever:

• the output will be truncated for any reason

That means:

• byte truncation
• line truncation

Minimal design

Add a small helper in the bash code:

• if temp file does not exist yet
• create it
• write all buffered output into it

Then call that helper whenever truncateTail(...) says truncation happened.

Where to apply it

1. packages/coding-agent/src/core/tools/bash.ts

This is the actual tool path.

Change behavior so that:

• partial updates that are truncated get a temp file
• final result that is truncated gets a temp file

2. packages/coding-agent/src/core/bash-executor.ts

This lower-level path has the same bug.

It should get the same treatment so behavior stays consistent across:

• tool execution
• interactive bash execution / other shared execution paths

Why this is the nice fix

Because it matches the user-facing contract:

• if output is truncated, full output is saved

Right now the code really implements:

• if output is over 50KB, full output is saved

Those are not the same thing.

Better than alternatives

A less nice fix would be:

• separately count lines while streaming
• create file after line 2000

That is possible, but not as robust:

• chunk boundaries do not align to lines
• you'd need extra state for partial lines
• you still want a final fallback based on actual truncation result

Using truncateTail(...) as the source of truth is simpler and more correct.

Expected behavior after fix

For seq 3000:

• displayed output is truncated
• temp file exists
• fullOutputPath is populated
• no data loss

For huge byte-heavy output:

• behavior stays the same

One extra cleanup

Also suppress any message that would print:

• Full output: undefined

That should never appear.

If you want, I can implement this now.

Potentially, yes. If you call truncateTail(fullText) on every chunk, it is not free.

What it costs

truncateTail() currently does work like:

• compute total bytes of the whole string
• split("\n") the whole string
• walk backward through lines

So if you call it repeatedly during streaming:

• each call is O(current buffered output size)
• many chunks can make that add up

In bash.ts, that already happens today for partial updates:

• every handleData() builds Buffer.concat(chunks)
• converts to string
• calls truncateTail(fullText)

So the current code already pays that cost. The issue fix does not introduce that pattern. It only changes what happens when truncation is detected.

Important distinction

There are two possible fixes:

Nice and simple

Use truncateTail(...) as the trigger for creating the temp file.

Pros:

• minimal code
• correct
• uses existing logic

Cons:

• if used on every chunk as the detection mechanism, it continues the current repeated full-buffer scan behavior

Nicer and more efficient

Track truncation state incrementally while streaming, then use truncateTail(...) only for rendering/final output.

That means tracking:

• totalBytes
• line count
• maybe whether a newline was seen across chunk boundaries

Then:

• create temp file as soon as either threshold is exceeded
• do not depend on repeated full-buffer truncation checks just to know whether to persist output

Best fix in my view

Use an incremental trigger for persistence:

• create temp file when totalBytes > DEFAULT_MAX_BYTES
• also create temp file when lineCount > DEFAULT_MAX_LINES

This avoids needing truncateTail(...) as the persistence trigger.

Then keep truncateTail(...) only for:

• partial displayed output
• final displayed output

That gives you:

• correct behavior
• no extra full rescans beyond what already exists for display
• clearer separation between persistence logic and display logic

One caveat

Counting lines incrementally has a small wrinkle:

• chunks can end in the middle of a line

So you need a tiny bit of state, for example:

• count \n occurrences in each chunk
• infer total logical lines carefully
• or keep a sawAnyOutput/endsWithNewline style state

Still straightforward.

Short answer

• Yes, truncateTail(...) is not especially cheap.
• But the code already calls it during streaming for display.
• For a clean and efficient fix, I would not use truncateTail(...) to decide when to create the temp file.
• I would track line overflow incrementally and create the temp file on either:
  • byte overflow
  • line overflow

That is the nicest fix if you care about performance and design.

Yes.

That is exactly what I mean.

Current state

In packages/coding-agent/src/core/tools/bash.ts, inside handleData() we already do this on every chunk:

• concatenate the rolling buffer
• convert it to text
• call truncateTail(fullText)
• send the truncated partial update

So if we changed the temp-file decision to also use that same truncation result, we would not need a second truncateTail(...) call in that path.

We could do:

• compute const truncation = truncateTail(fullText)
• if truncation.truncated && !tempFilePath, create temp file from buffered chunks
• use that same truncation for onUpdate(...)

So there is no extra truncation pass there.

But

That only applies to the path where we are already computing truncateTail(...).

There are still two places to think about:

1. Partial update path in bash.ts

No second call needed. Reuse the existing result.

2. Final result path in bash.ts

There is already one final truncateTail(fullOutput) call there too. Same story. Reuse that result for:

• output text
• deciding whether temp file must exist

Again, no second call needed.

So why did I mention incremental tracking?

Because even though we would not add a second truncateTail(...), the current approach is still somewhat expensive overall, since partial updates already recompute truncation repeatedly.

That is a separate optimization question.

For fixing this bug specifically:

• yes, we can reuse the existing truncateTail(...) result
• no, we do not need to call it twice

Cleanest bug fix without extra truncation work

In bash.ts:

• partial path: reuse current truncation
• final path: reuse current truncation

In bash-executor.ts:

• final path already computes truncateTail(fullOutput)
• reuse that result to decide whether to create the temp file before returning

So the bug can be fixed without introducing additional truncation calls.

If you want, I can now turn this into a concrete implementation plan file-by-file.

Implemented.

Changed files:

• packages/coding-agent/src/core/tools/bash.ts
• packages/coding-agent/src/core/bash-executor.ts
• packages/coding-agent/test/tools.test.ts

What changed:

• bash tool now ensures a temp file exists whenever output is truncated, not only when raw bytes exceed 50KB
• same fix applied to shared executeBash path in bash-executor.ts
• regression test added that instantiates the tool directly and runs seq 3000

Regression covered:

• line-count truncation under byte threshold
• fullOutputPath is populated
• temp file exists
• temp file contains the full output
• no Full output: undefined

Validation:

• cd packages/coding-agent && npx tsx ../../node_modules/vitest/dist/cli.js --run test/tools.test.ts
• npm run check

Both passed.

Not 100%, but close.

What is solid

• The reported bug is fixed in both relevant code paths:
  • packages/coding-agent/src/core/tools/bash.ts
  • packages/coding-agent/src/core/bash-executor.ts
• There is a regression test for the exact failure mode:
  • truncation by line count only
  • direct tool instantiation
  • verifies temp file exists and contains full output
• npm run check passes

What I am confident about

For the user-visible bug in the bash tool, yes, this is in a good place.

What is not fully covered

The new regression test covers the tool path, not executeBash() directly.

I did fix packages/coding-agent/src/core/bash-executor.ts too, but there is no dedicated regression test for that path yet.

So the honest answer is:

• tool path: very confident
• shared executor path: code looks correct, typecheck passes, but not specifically regression-tested yet

If you want higher confidence

I would add one more small test for executeBash("seq 3000") asserting:

• truncated === true
• fullOutputPath is defined
• temp file exists
• file contains full output

That would make me much more comfortable saying "yes, done".

Added the extra coverage.

Now covered by tests:

• direct bash tool invocation
• direct executeBash() invocation

Validation rerun:

• cd packages/coding-agent && npx tsx ../../node_modules/vitest/dist/cli.js --run test/tools.test.ts
• npm run check

Both passed.

So yes, this is now in a much better place. Still never "100% sure" in the absolute sense, but this is sufficient confidence for merge.

From the repo root:

1. Run pi from source

Use whatever local flow you normally use. For interactive TUI, the repo docs already suggest:

./pi-test.sh

Or in tmux if you want isolation:

tmux new-session -d -s pi-test -x 80 -y 24tmux send-keys -t pi-test "cd /Users/badlogic/workspaces/pi-mono && ./pi-test.sh" Entersleep 3tmux capture-pane -t pi-test -p

2. Trigger the bug case

Ask pi to run one of these:

run seq 3000

or directly in slash/bash mode if you use that:

!seq 3000

3. What you should see

The output should be truncated, but the result should also include a temp file path, something like:

[Showing lines ... Full output: /var/folders/.../pi-bash-....log]

The important part is:

• it must not say Full output: undefined
• it must include a real temp file path

4. Verify the temp file exists

Copy the path from the output and check it in another shell:

ls -l /path/from/output.log

Then inspect it:

tail -5 /path/from/output.loghead -5 /path/from/output.log

You should see:

• first lines: 1, 2, 3
• last lines: 2998, 2999, 3000

5. Optional byte-threshold sanity check

Also try something that exceeds bytes, not just lines:

run python - <<'PY'for i in range(400):    print(f"{i} " + "x"*200)PY

That should also:

• truncate
• produce a real temp file path

6. Direct non-agent check

If you want to validate the underlying shell behavior without going through the full agent UI, the tests already cover it, but a quick manual check is:

cd packages/coding-agentnpx tsx ../../node_modules/vitest/dist/cli.js --run test/tools.test.ts

If you want, I can also give you a very small one-off node -e snippet to invoke executeBash() directly from source.

Preview issue comment for #2852:

Fixed in main.

Root cause was that bash output persistence and bash output truncation used different thresholds. The tool only created a temp file after crossing the byte limit, but truncation also happens on line count. For outputs like seq 3000, the result was truncated while no temp file was written, so the omitted lines were lost.

Changes:

• make the bash tool persist full output whenever truncation happens, not only when bytes exceed 50KB
• apply the same fix to the shared executeBash() path
• add regression coverage for both direct tool invocation and direct executeBash() invocation

Manual check:

• run seq 3000
• output should be truncated
• a real Full output: /tmp/... path should be present
• the temp file should contain the complete output

Wrapped.

Done:

• added changelog entry in packages/coding-agent/CHANGELOG.md
• posted final issue comment on #2852
• committed only session files
• commit: 52d16d5a
• pushed main

Commit message:

• fix(coding-agent): persist bash output on line truncation closes #2852

Files in the commit:

• packages/coding-agent/CHANGELOG.md
• packages/coding-agent/src/core/bash-executor.ts
• packages/coding-agent/src/core/tools/bash.ts
• packages/coding-agent/test/tools.test.ts