[GH-ISSUE #283] Tool output truncation limits are env-var-only and undocumented, one is fully hardcoded #196

Open
opened 2026-10-18 14:03:44 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @Classic298 on GitHub (Sep 20, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/283

What happens

Every tool response the model sees gets truncated to a fixed cap, and none of the caps are configurable from the UI or config.toml:

  • run_command output: 8000 chars (CHAT_TOOL_COMMAND_MAX_CHARS)
  • other tool results (file reads, web results, subagent output): 50000 chars (CHAT_TOOL_MAX_CHARS)
  • task-check summaries: 4000 chars (MAX_TASK_CONTENT_CHARS, hardcoded constant, not even an env var)

Truncation itself is good behavior (head+tail, explicit marker). The problems are that the limits aren't documented anywhere a user can find, and there's no way to tune them without editing env vars outside cptr and restarting the systemd unit.

Consequences when the defaults bite: a long build log through run_command loses its middle 90% past 8000 chars, rtk recall-style full-output recovery is impossible because the elided part never reached the model, and debugging "the agent ignores half the log" means finding this issue or reading source.

Suggested change

Move the two env-backed constants into the existing Settings/config system (like chat.compact_token_threshold already is), keep the env vars as overrides. MAX_TASK_CONTENT_CHARS should follow. If the reason for the 8000 cap is context-size safety, a per-user setting is exactly where that tradeoff belongs.

Originally created by @Classic298 on GitHub (Sep 20, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/283 ## What happens Every tool response the model sees gets truncated to a fixed cap, and none of the caps are configurable from the UI or `config.toml`: - `run_command` output: 8000 chars (`CHAT_TOOL_COMMAND_MAX_CHARS`) - other tool results (file reads, web results, subagent output): 50000 chars (`CHAT_TOOL_MAX_CHARS`) - task-check summaries: 4000 chars (`MAX_TASK_CONTENT_CHARS`, hardcoded constant, not even an env var) Truncation itself is good behavior (head+tail, explicit marker). The problems are that the limits aren't documented anywhere a user can find, and there's no way to tune them without editing env vars outside cptr and restarting the systemd unit. Consequences when the defaults bite: a long build log through `run_command` loses its middle 90% past 8000 chars, `rtk recall`-style full-output recovery is impossible because the elided part never reached the model, and debugging "the agent ignores half the log" means finding this issue or reading source. ## Suggested change Move the two env-backed constants into the existing Settings/config system (like `chat.compact_token_threshold` already is), keep the env vars as overrides. `MAX_TASK_CONTENT_CHARS` should follow. If the reason for the 8000 cap is context-size safety, a per-user setting is exactly where that tradeoff belongs.
Author
Owner

@owui-terminator[bot] commented on GitHub (Sep 20, 2026):

⚠️ Missing Issue Title Prefix

@Classic298, your issue title is missing a categorising prefix (e.g. bug:, feat:, docs:).

Please update the title to lead with one of:

  • bug: bug report or error
  • feat: feature request or enhancement
  • docs: documentation issue
  • question: usage question
  • help: support request

Example: bug: Login fails when the password contains special characters

<!-- gh-comment-id:5753248586 --> @owui-terminator[bot] commented on GitHub (Sep 20, 2026): # ⚠️ Missing Issue Title Prefix @Classic298, your issue title is missing a categorising prefix (e.g. `bug:`, `feat:`, `docs:`). Please update the title to lead with one of: - **bug**: bug report or error - **feat**: feature request or enhancement - **docs**: documentation issue - **question**: usage question - **help**: support request Example: `bug: Login fails when the password contains special characters`
Sign in to join this conversation.
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/computer#196
No description provided.