Bug: truncated command output permanently lost, message references non-existent method

[thehighnotes]

Description

Two issues with truncate_output() in interpreter/core/utils/truncate_output.py:

1. Output permanently lost: When command output exceeds max_output_chars, the middle portion is replaced with [...] and discarded. Neither the user nor the LLM can recover the full output. For commands like ls -la on a large directory or grep -r results, the most useful data is often in the discarded portion.

2. Truncation message references non-existent method: The message tells users to use computer.ai.summarize(result), which does not exist in the CLI context. Users follow this suggestion and get an error.

3. ANSI escape codes counted as content: Raw ANSI codes are counted toward the character limit, meaning the visible content is shorter than max_output_chars suggests.

Current code

message = (f"Output truncated ({len(data):,} characters total). "
           f"Showing {chars_per_end:,} characters from start/end. "
           "To handle large outputs, store result in python var first "
           "`result = command()` then `computer.ai.summarize(result)` for "
           "a summary, search with `result.find('text')`...")

Suggested fix

• Strip ANSI escape codes before measuring length
• Save full output to a temp file (e.g. /tmp/oi-output-latest.txt) before truncating, so users can review it
• Reword the truncation message to reference practical shell commands (head, tail, grep) instead of non-existent Python methods

Related: #1588

Environment

• open-interpreter 0.4.3
• Python 3.10, Linux

[endolith]

The message tells users to use computer.ai.summarize(result), which does not exist in the CLI context. Users follow this suggestion and get an error.

Was this written by LLM? If I recall correctly, ai.summarize does exist, but doesn't work well. Open Interpreter follows the suggestion, not "users".

I don't think the escape codes is going to make a practical difference. The point is that the content is truncated to some number of characters, giving the AI an overview, and then the AI has to run more specific commands if it wants to get more specific content.

Automatically putting the content into a variable might be a good idea for one-off commands, so the AI can grep through it after the fact without running the command again. That would have to work for each supported language though.

[thehighnotes]

Good catch on ai.summarize — you're right it exists in interpreter/core/computer/ai/ai.py. My wording was off. The issue I should've described more precisely:

• import_computer_api defaults to False, so the computer object isn't injected into execution namespace by default
• The truncation message shows for all languages including bash, where computer.ai.summarize() isn't callable regardless
• There's even a comment in the source: # This won't work because truncated code is stored in interpreter.messages :/

So the method exists but isn't reachable in the default CLI flow where truncation actually happens.

And yeah — this was drafted with help from an LLM (Claude), but I've been reviewing and running these patches on a local OI 0.4.3 setup for a while. We've got a pretty heavily modified version running on a Jetson with Ollama backend — callable auto_run, output spillover to temp file + a %view command to page through it, sudo detection, etc. The truncation stuff was one of the first things we hit in practice.

Fair point on the ANSI stripping too — not a huge deal on its own, but it was easy to fix alongside the rest so we threw it in.

— Mark (with Claude's assistance)

[endolith]

import_computer_api defaults to False, so the computer object isn't injected into execution namespace by default

Ah, yes, it shouldn't say to use it if it's not imported. I'm used to it always being imported.

The truncation message shows for all languages including bash, where computer.ai.summarize() isn't callable regardless

Yes, it shouldn't say it there, either.