Claude Opus 4.6 skims long handoff prompts; acts on stale local state instead of synthesizing the state info already provided

Title: Claude Opus 4.6 skims long handoff prompts; acts on stale local state instead of synthesizing the state info already provided

Context: Claude Code, model claude-opus-4-6[1m], effortLevel: high, session resumed after /clear with a detailed handoff prompt written by the user summarizing the prior session's work.

Summary: When a session begins with a long, structured prompt that describes recent remote/state changes (e.g. "PR #10 was merged", "deployed yesterday", "cutover shipped"), the model treats the prompt as a sequential task list rather than a state document. It races to execute the first actionable bullet without verifying whether its local environment reflects the state the prompt describes. When local state is stale, it confidently produces work that duplicates or contradicts what's already live.

Reproduction (concrete, from a real session 2026-04-14):

1. Prior session squash-merged PR #10 to origin/main, then ended. The merge centralized ~30 string literals into a brand.ts module.
2. New session opened. Opening user prompt explicitly said: "Phase 3 (cutover) shipped last session. PR #10 was merged." It also pointed at a memory file with full context.
3. Claude read the memory file (good) but did not fetch origin. It ran git status, which reported "up to date with origin/main" — a misleading result, since git compares against the locally-cached remote ref, which hadn't been refreshed since before the merge.
4. Claude grepped the working tree for the old domain string, got ~30 hits, concluded the prior session had "missed" them, and announced a "plan gap."
5. Claude made 12 file edits hardcoding the new domain (inferior to the BRAND_EMAIL.x pattern the merged PR had introduced), committed, and attempted to push.
6. Push rejected. Rebase surfaced conflicts. Conflict markers finally revealed the truth: the remote had already fixed all 12 files, more cleanly.

What the model had but didn't use:

• A verbatim statement that PR #10 was merged
• Memory referencing the merge
• Domain knowledge that git status: up to date is only meaningful after git fetch

Why this matters:

• The failure mode is silent — Claude appears confident throughout
• User intervention is required to catch it; without it, stale-state edits would have been pushed
• It pattern-matches to other complaints about "racing to action" / "not reading the prompt" that users are raising
• The user-visible symptom is "Claude ignored what I told it in the initial prompt"

Expected behavior:
On any session start with a handoff-shaped prompt, the model should:

1. Produce a state summary as its first output (what the prompt claims happened + what needs verification)
2. Verify local-vs-remote state with a hard side-effect (e.g. git fetch && git log HEAD..@{u}) before grepping, reading, or editing tracked code
3. Treat "up to date" from any cached source as provisional until freshly verified

Workaround the user installed:
Two Claude Code hooks in ~/.claude/settings.json:

• SessionStart runs git fetch origin in the CWD repo and injects any incoming commits into Claude's context
• UserPromptSubmit detects prompts that are long or contain state-change verbs (shipped/merged/deployed/last session) and injects a "produce a state summary first" reminder

These shouldn't be necessary for a premium product. They're a user patch for a model behavior problem.

Note on regression impression: The user reports this pattern has been more frequent recently and feels like a reasoning regression. I can't verify that claim, but it's consistent with the failure mode described.