[BUG] Read tool truncation causes agents to silently lose guardrails from instruction files

Resolved 💬 8 comments Opened Feb 25, 2026 by TomCats Closed Apr 13, 2026

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?

Note: This issue is being reported by Claude Code on behalf of the user.

When a Claude Code agent is instructed to Read a file containing behavioral rules and guardrails, the Read tool can return a truncated preview that the agent treats as the complete file. Rules in the unread portion are silently absent from the agent's context. The operator receives no indication that guardrails were dropped.

This is not a usability issue — it's a silent safety failure. The agent doesn't error or report incomplete information. It proceeds confidently as if it read everything. An operator who placed safety-critical instructions in a file and told the agent to read it has no way to know those instructions were never loaded.

What Should Happen?

The agent should either:

  • Read the entire file when instructed to, or
  • Clearly recognize truncation occurred and automatically retrieve the remaining content, or
  • At minimum, refuse to proceed and inform the operator that it could not read the full file

Error Messages/Logs

No error is produced. The Read tool returns a truncated preview with a message like "Output too large... Full output saved to [path]" — but the agent treats the preview as the complete file content and proceeds. The silent nature of this failure is the core issue.

Steps to Reproduce

  1. Create a file with behavioral rules/instructions (over 50K threshold, but below 25,000 token threshold)
  2. Instruct a Claude Code agent (via --append-system-prompt or initial message) to Read the file before proceeding
  3. The Read tool returns a truncated preview with a note that full output was saved to disk
  4. The agent treats the preview as the complete content and proceeds without reading the remainder
  5. Any rules or guardrails in the unread portion are silently absent from the agent's behavior

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.39

Claude Code Version

2.1.51

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Workaround: We added a shared rule file (loaded via .claude/rules/) instructing agents to detect truncation and re-read using offset/limit parameters. This is inherently fragile since it relies on the agent following a rule about how to read rules.

Related issues:

  • #28743 (model reads subset of files) — same symptom but different cause. In that issue, the model chooses to sample. In this issue, the Read tool's truncation response format causes the model to treat a partial preview as the complete file without realizing content is missing.
  • #22699 (size-aware reading feature request) — proposes pre-flight size checks. Would help but doesn't address the core problem: when truncation does occur, the response format must be unambiguous enough that the model never treats partial content as complete.

Context on threshold change: The v2.1.51 changelog notes the tool result disk persistence threshold dropped from 100K to 50K characters. However, the affected files are under 50K, suggesting additional changes to how the Read tool communicates truncation to the model may have also occurred. The previous response format apparently signaled truncation more clearly, as agents consistently read complete files before the upgrade.

Testing against v2.1.39 reveals the old version had three tiers:

  1. Under 100K chars: full content returned
  2. 100K chars to 25K tokens: preview + "saved to temp path" (ambiguous)
  3. Over 25K tokens: hard refusal, zero content, explicit instruction to use offset/limit

The new version (v2.1.51+) lowered the tier 2 threshold from 100K to 50K chars. The tier 3 hard refusal still exists, but doesn't help — files in the 50K chars to 25K tokens range now land in tier 2 (ambiguous preview) instead of tier 1 (full read).

The tier 2 preview band was previously so narrow (100K chars to ~25K tokens) that it was rarely encountered. Lowering the threshold to 50K chars moved moderately sized instruction files (like role definitions) from tier 1 (full read) into tier 2 (ambiguous preview), exposing the silent failure at scale.

View original on GitHub ↗

This issue has 8 comments on GitHub. Read the full discussion on GitHub ↗