[PR #178] fix: keep tool responses under a configurable size limit #153

New issue

Open

opened 2026-10-18 21:11:18 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 21:11:18 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-terminal/pull/178
Author: @Classic298
Created: 9/18/2026
Status: 🔄 Open

Base: main ← Head: fix/bounded-tool-output

📝 Commits (1)

571a7e0 fix: keep tool responses under a configurable size limit

📊 Changes

5 files changed (+369 additions, -41 deletions)

View changed files

📝 open_terminal/env.py (+19 -0)
📝 open_terminal/main.py (+120 -39)
📝 open_terminal/utils/fs.py (+81 -0)
➕ open_terminal/utils/limits.py (+138 -0)
📝 open_terminal/utils/log.py (+11 -2)

📄 Description

One search over minified files returned 36 MB in a single tool result. The model provider rejected the follow-up request at its 30 MB limit, and because the oversized result was already part of the conversation, every retry failed the same way until the chat's database row was repaired. Count limits never prevented this: limit, max_results and tail bound how many items come back, while one line, one file or one output entry can be any size at all.

Every model-facing tool now measures what it is about to return, serialized as JSON with escaping counted, and keeps the whole body under OPEN_TERMINAL_MAX_TOOL_OUTPUT_SIZE, 256 KiB by default. Nothing is dropped silently: a response that was cut says so and says where to continue. Reading a file returns a bounded slice plus the next line to read, and for a line too long to return whole, a position inside that line, so a multi-megabyte minified JSON file stays readable page by page. Searching returns a bounded excerpt around each match instead of the entire physical line. Running a command and polling its status return bounded output with the offset to continue from.

Reading a file also stopped loading all of it into memory. On a 300 MB single-line file the server now grows by 1.3 MB instead of 853 MB, and serves large reads about five times faster; files made of very many short lines are somewhat slower, since every line is now measured.

Two related corrections come with it. Content search passes a maximum file size to ripgrep, so results no longer depend on whether ripgrep happens to be installed on the host. Binary content cannot be cut meaningfully, so reading it is refused above OPEN_TERMINAL_MAX_BINARY_FILE_SIZE, 5 MiB by default, instead of returning the whole file.

On the reproduction in the issue, a 2 MB file holding one line: match_files 2,000,508 to 320 bytes, grep_search 2,001,947 to 3,972, read_file 2,000,082 to 262,119, run_command 2,013,929 to 259,995.

Closes #177

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-terminal/pull/178 **Author:** [@Classic298](https://github.com/Classic298) **Created:** 9/18/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/bounded-tool-output` --- ### 📝 Commits (1) - [`571a7e0`](https://github.com/open-webui/open-terminal/commit/571a7e054de8d09803168d70e1b549988c9078a4) fix: keep tool responses under a configurable size limit ### 📊 Changes **5 files changed** (+369 additions, -41 deletions) <details> <summary>View changed files</summary> 📝 `open_terminal/env.py` (+19 -0) 📝 `open_terminal/main.py` (+120 -39) 📝 `open_terminal/utils/fs.py` (+81 -0) ➕ `open_terminal/utils/limits.py` (+138 -0) 📝 `open_terminal/utils/log.py` (+11 -2) </details> ### 📄 Description One search over minified files returned 36 MB in a single tool result. The model provider rejected the follow-up request at its 30 MB limit, and because the oversized result was already part of the conversation, every retry failed the same way until the chat's database row was repaired. Count limits never prevented this: limit, max_results and tail bound how many items come back, while one line, one file or one output entry can be any size at all. Every model-facing tool now measures what it is about to return, serialized as JSON with escaping counted, and keeps the whole body under OPEN_TERMINAL_MAX_TOOL_OUTPUT_SIZE, 256 KiB by default. Nothing is dropped silently: a response that was cut says so and says where to continue. Reading a file returns a bounded slice plus the next line to read, and for a line too long to return whole, a position inside that line, so a multi-megabyte minified JSON file stays readable page by page. Searching returns a bounded excerpt around each match instead of the entire physical line. Running a command and polling its status return bounded output with the offset to continue from. Reading a file also stopped loading all of it into memory. On a 300 MB single-line file the server now grows by 1.3 MB instead of 853 MB, and serves large reads about five times faster; files made of very many short lines are somewhat slower, since every line is now measured. Two related corrections come with it. Content search passes a maximum file size to ripgrep, so results no longer depend on whether ripgrep happens to be installed on the host. Binary content cannot be cut meaningfully, so reading it is refused above OPEN_TERMINAL_MAX_BINARY_FILE_SIZE, 5 MiB by default, instead of returning the whole file. On the reproduction in the issue, a 2 MB file holding one line: match_files 2,000,508 to 320 bytes, grep_search 2,001,947 to 3,972, read_file 2,000,082 to 262,119, run_command 2,013,929 to 259,995. Closes #177 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-18 21:11:18 +00:00

No labels

bug

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/open-terminal#153

No description provided.

Rows
Columns