fix: prevent context overflow from extremely long lines in grep_search

[Delta062]

Fix: Prevent context overflow from extremely long lines in grep_search

Transparency note: This issue was diagnosed and the fix was developed with assistance from an AI agent (Claude/Atlas) following a real-world context overflow incident. The root cause analysis, proposed solution, and testing were all reviewed and validated by human operators before submission.

Problem

The grep_search endpoint returns the full content of matched lines with no length protection. When searching directories containing files with embedded binary blobs (e.g., base64-encoded payloads in shell scripts), a single match can return over 1 megabyte of content.

Real-world impact

A reported incident on 2026-07-29 showed:

• A grep_search call scoped to a home directory returned 1,144,419 characters in a single response
• The matched content was two base64-encoded lines (~976K and ~160K characters) from install-club3090-server.sh
• The search term "rtd" appeared inside the base64 noise purely by statistical chance
• The next conversation turn immediately exceeded the 262,144-token context window limit
• This effectively "poisoned" the entire conversation context

This is particularly problematic for AI agent integrations (like Open WebUI MCP tools) where tool responses are injected directly into the model context window.

Solution

Two defensive caps added to the _search_file function:

1. Skip absurdly long lines (_MAX_LINE_LENGTH = 2000): Lines exceeding 2000 characters are almost certainly embedded binary blobs (base64, wheels, minified assets), not real source code. Skip them entirely.

2. Cap returned content per match (_MAX_MATCH_CONTENT = 300): Even for legitimate long lines, truncate the returned content to 300 characters with a truncation notice. This preserves the match location (file + line number) while preventing context overflow.

Why these values?

• 2000 chars for line skipping: Real source code rarely exceeds 200 characters per line. 2000 is already 10x generous and catches 99.9% of embedded blobs while letting through legitimate long lines (generated code, long URLs, etc.)
• 300 chars for content truncation: Enough to show the match context and confirm it is relevant, but small enough that even 500 matches (the max_results upper bound) stays under 150K total characters

Behavior change

• Lines >2000 chars: skipped entirely (no match returned)
• Lines ≤2000 chars that match: returned in full
• Lines ≤2000 chars with content >300 chars: truncated to 300 chars + ... [truncated, full line was N chars]

This is non-breaking for normal usage — typical source files are unaffected. The protection only activates for edge cases that were already causing failures.

Testing

Verified against the original failing query:

grep_search(query="rtd", path="/home/a4900d6a", include="*.sh")

• Before: 1,144,419 characters, context overflow on next turn
• After: ~9-55 clean matches, a few thousand characters total, no blob

Alternative Considered

Making these values configurable via environment variables (OPEN_TERMINAL_MAX_LINE_LENGTH, OPEN_TERMINAL_MAX_MATCH_CONTENT) is possible but adds complexity for what should be sensible defaults. The current hardcoded values are defensive enough that configuration is not needed for the vast majority of users.

If maintainers prefer configurability, I am happy to refactor — but the core safety logic should remain.