Read 工具新增 allow_large：大文本文件可以一次读完
日志、导出的 JSON、一次性生成的大配置——这类文件经常超过 Read 工具的常规大小上限。以前 Claude 只能分段读，或者改用 Bash 里的 head/tail，既慢又容易漏上下文。
CLI 2.1.296 给 Read 工具加了 allow_large 选项：在上下文还有空间、并且确实需要整份文件时，可以一次把超限的大文本文件读进来。
以前为什么要限大小
Read 的默认上限不是刁难，是保护会话：
- 一次塞进过大的文件，会迅速吃掉上下文窗口；
- 后面的工具调用、子代理、压缩都会更早触发；
- 很多时候其实只需要文件的一部分（某段日志、某几个键）。
所以默认策略是：超限就拒绝或要求分段。对多数日常读写这是合理的。
allow_large 做什么
打开 allow_large 后，Claude 可以在同一次 Read 调用里读完平时会超限的文本文件，前提是：
- 需要整份内容（例如全局搜索引用、校验完整结构）；
- 当前上下文还有余量，塞进去不会立刻把会话顶满。
它不是「无限大」。上下文不够时，仍然应该分段读，或者先压缩、清掉无关历史再读。
什么时候值得用
- 整份校验：schema、锁文件、导出清单，缺一段就没法判断。
- 跨文件对照：要把 A 的全文和 B 的全文摆在一起比。
- 一次性分析：大日志里找根因，分段读会丢失前后关联。
不适合的场景：
- 只想看文件开头或某个关键字——继续用默认 Read，或 Grep；
- 会话已经很挤——先压缩或开新会话，别硬塞；
- 二进制、图片、PDF——
allow_large针对的是文本文件，格式不对时还是走对应工具或 skill。
和分段读怎么选
| 情况 | 建议 |
|---|---|
| 只要局部内容 | 默认 Read（带 offset/limit）或 Grep |
| 全文必要，上下文宽裕 | allow_large 一次读完 |
| 全文必要，但上下文已紧 | 先 /compact 或新开会话，再决定是否 allow_large |
| WebFetch 网页截断 | 那是另一条线，看 WebFetch offset 续读 |
同版本还修了托管设置里 PreToolUse / prompt hooks 拒绝工具调用后不结束回合的问题：拒绝会真正拦住动作。团队若靠 hooks 做门禁，升级到 2.1.296 后行为更符合预期。
小结
- 2.1.296 起，Read 支持
allow_large：上下文够用时，一次读完超限大文本文件。 - 默认上限仍在，避免无脑塞满上下文；需要整份内容时再开。
- 只读局部、会话已满、非文本文件，继续用原来的分段或专用工具。
升级后用 claude --version 确认 ≥ 2.1.296。下次 Claude 因为文件太大读不进时，可以明确告诉它：上下文够的话用 allow_large 一次读完。