[BUG] At the beginning of the session, the essential documents for the workflow are summarized internally.

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

Issuing several Read calls in parallel within a single assistant turn caused one batch (3 markdown files) to return summarized/condensed versions rather than the verbatim file contents. The content looked plausible and internally consistent, making it hard to detect.

Environment

• Claude Code CLI (interactive agent)
• Model: claude-opus-4-8[1m] (Opus 4.8 / 1M context)
• OS: Windows 11 Home (10.0.26200)
• Shell: PowerShell / Git Bash
• Target: markdown files inside a git repository
• Date: 2026-06-13

Observed conditions / repro

1. Early in a fresh session, before any context compaction.
2. Multiple Read calls (3) issued in parallel in one assistant message (medium/large markdown: 47 / 152 / 248 lines).
3. All three results came back as shortened versions.

• Parallel Read batches in other turns of the same session (main.py, core.py) were correct.

1. No reliable on-demand repro established (observed once). Circumstantial: parallel + multi-file + early session.

Expected

Read returns the verbatim file content (cat -n line-numbered).

Actual (evidence)

Diff between the true version in git (working tree clean at session start, so disk == committed) and what Read returned:

| File | True (git/disk) | What Read returned |
|---|---|---|
| timeline.md | title # ESC-SA-001 — … / 47 lines / heading ### SA に詰めてほしい論点 / 6 points: screen layout, mode/genre/submode switchers, search demotion (FR-C6), employed gray-out (FR-C5), "OK to hire" note (FR-C4), cook-mode display integration | title # ESC-SA-001 タイムライン / shown as 55 lines / heading ### 詰めるべき論点（6 点） / a different 6-point list |
| REQUIREMENTS.md | title # 要件定義書 — … / 248 lines / detailed tables | title # 要件定義書（…） / ~96 lines / trailing （後略：…） ("rest omitted") |
| APP_FLOW.md | title # アプリケーション操作フロー — … / 152 lines | title # アプリケーションフロー（…） / ~43 lines / trailing （後略：…） |

Diagnostic clues

1. All three files in the same parallel batch were affected; other-turn parallel reads were fine → possibly a per-batch phenomenon.
2. The returned content contained omission markers ("（後略）") absent from the real files → hallmark of summarization, not file-I/O corruption.
3. Returned content kept current metadata (version/date/status) but had a condensed body — a hybrid matching no git commit, so "stale cached old version" does not explain it.
4. Presented with cat -n line numbers as if verbatim; timeline was shown as 55 lines vs. the real 47.
5. A later Edit/Write was rejected with "File has not been read yet", forcing a fresh read that returned the correct content → the "has this file been read" tracker and the initially-returned representation appear to be different sources of truth.

Impact

• Initial design inputs (e.g., the "6 points to resolve") were the summarized version; work started on wrong premises.
• Damage was limited only by a lucky triple safety net: (a) the summaries were faithful in gist; (b) Edit/Write forced re-reads that exposed the real files; (c) the user noticed a mismatch and ran an independent subagent re-check.
• General risk: a silent, plausible divergence between what the model "sees" and the real file. Read-only judgments (review/summary/decisions) not followed by an edit could reach wrong conclusions undetected.

Hypotheses (not asserted; not determinable client-side)

• A per-batch summarization/compaction step may have replaced large Read results with condensed text while preserving the cat -n layout.
• Or a retrieval/cache layer returned a non-canonical representation.
• Whether the fault is in the Read tool, a context-assembly/summarization layer, or elsewhere cannot be determined from the client side.

Suggested fixes

1. Treat Read output as always verbatim; never summarize file contents before passing to the model without explicit marking.
2. If large-file summarization is intentional, mark it unmistakably, do not reuse cat -n numbering, and never fabricate omission markers like "（後略）".
3. Make the "file has been read" tracker and the Read result share a single source of truth (here the Edit guard rejected the initial read).
4. Consider attaching the file's true total line count / hash to Read responses so mismatches with the presented line count are detectable.

Workarounds (user side)

• Read important files individually (avoid large parallel batches).
• Cross-check length/first line with wc -l / git show before read-only judgments.
• If you spot omission markers ("（後略）") or altered headings, re-read.

What Should Happen?

This will lead you to accurate information.

Error Messages/Logs

Steps to Reproduce

It seems to have happened suddenly.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.177

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_