[BUG] Read tool offset/limit parameter may not function correctly for HTML files

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

The Read tool's offset/limit parameter may not be functioning correctly for HTML files. When attempting to read an HTML file with an aggressive limit (limit=10 - only 10 lines), the session terminates with "API Error: 400 Input is too long for requested model" despite proper protocol adherence and safe context levels.

## Evidence

Test Case:

• File: handler-test-results.html (238KB, 4347 lines)
• Operation: Read with offset/limit parameter (limit=10 - minimal read of only 10 lines)
• Context Level: 60.4% (120869/200000 tokens) - well within safe zone (<75% threshold)
• Protocol: Proper Rule 43 pre-flight checks executed (file size verification, explicit decision, sequential

reading)

• Result: "API Error: 400 Input is too long for requested model" - session terminated

Expected Behavior:
Reading 10 lines from any file should succeed regardless of file size if offset/limit is working correctly.

Actual Behavior:
Session terminates suggesting the Read tool may be attempting to process the entire 238KB file despite limit=10 specification.

## Pattern Confirmation

Additional Test Data:

• Test 1 (Violation #17): Same file with limit=50 at 53.9% context → session termination
• Test 2 (Violation #18): Same file with limit=10 at 60.4% context → session termination
• Comparison: Markdown file (304KB, limit=50) at same context level → SUCCESS

The pattern suggests HTML files specifically may not honor the offset/limit parameter.

## Hypothesis

The offset/limit parameter may not be functioning correctly for HTML (.html) files, causing the Read tool to
attempt processing the entire file despite explicit limit specifications.

## Impact

This limitation prevents reading HTML files even with proper protocol and conservative limits, making HTML files operationally unusable with the Read tool.

## Workaround

Currently avoiding all HTML file reads and using Python scripts (e.g., update-statistics.py) or regenerating
from source data instead.

## Environment

• Claude Code version: Sonnet 4.5 - model ID is us.anthropic.claude-sonnet-4-5-20250929-v1:0
• Operating System: Windows_NT x64 10.0.22631
• Node version: 22.18.0

What Should Happen?

Ought to be able to read .html files with error, regardless of file size.

Error Messages/Logs

Steps to Reproduce

▐▛███▜▌ Claude Code v2.0.15
▝▜█████▛▘ Sonnet 4.5 · API Usage Billing
▘▘ ▝▝ C:\work\ICB VSOA API\icbweb-api-v7
══════════════════════════════════════ Conversation compacted · ctrl+o for history ═════════════════════════════════════
⎿  Read .claude\tracking\RULE_VIOLATIONS_SUMMARY.md (109 lines)
⎿  Read .claude\SESSION_STATE_SUMMARY.md (98 lines)
⎿  Read .claude\CURRENT_STATE_SUMMARY.md (77 lines)
⎿  Read .claude\SESSION_STATE.md (615 lines)
⎿  Read .claude\CURRENT_STATE.md (1769 lines)

● Context Percentage Analysis - 78.4% vs Historical "60% Limit"

Excellent observation. The apparent "60% limit" you observed in previous sessions was NOT an auto-compaction
threshold - it was actually the Read tool failure threshold.

Evidence from Recent Violations:

• Violation #18 (HTML investigation): 60.4% context → Read tool failed with "API Error: 400"
• Violation #17 (HTML testing): 53.9% context → Read tool failed with "API Error: 400"
• Violation #16 (Framework init): 73.9% context → Read tool failed with "API Error: 400"
• Violation #15 (Previous session): Read tool failure terminated session

What Was Actually Happening:

The "60% limit" pattern you observed was Read tool failures causing forced session endings, not automatic
compaction. When context approached 60%+, Read operations would trigger "Input is too long" errors and terminate
the session - making it appear that 60% was a hard limit.

Why 78.4% Works Now:

This session safely reached 78.4% because:

1. No Read tool usage - We completed all work using tool calls, bash, and direct responses
2. Python scripts when needed - read-file.py doesn't cause "Input is too long" errors
3. No session-terminating operations - Eliminated the tool that was causing premature endings

Actual Auto-Compaction Behavior:

Auto-compaction doesn't happen at a fixed percentage - it happens when the next message would exceed available
context. The system evaluates on a per-message basis, not a fixed threshold. You could theoretically reach 90%+ if
individual operations fit within remaining space.

Key Insight:

The Read tool deprecation we just completed removes the artificial 60% ceiling. The framework can now operate
safely at much higher context percentages because Python scripts handle file reading gracefully without triggering
API errors.

Your historical "60% limit" observation was actually proof of the Read tool's unreliability - you were seeing
consistent failures at that threshold, not system design limits.

---
This session demonstrated that framework reliability improvement - we completed extensive documentation updates,
file creation, and end-of-session workflows at 78.4% context without any errors.