[BUG] Opus 4.7 — persistent in-project governance ignored under multi-reference workloads (regression from 4.6)

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
• [x] I am reporting a pattern not already captured by single-session issues (#50507, #50546, #50163)

Summary

We run a production workflow that relies on a persistent in-project governance layer (CLAUDE.md at project root + a set of rule files under .claude/rules/ + a persistent memory layer loaded each session). Under Opus 4.6 the model reliably consulted this layer before acting. Under Opus 4.7 the same files remain physically present and load-available, but the model bypasses them and rediscovers approaches from scratch, including low-level APIs that the governance layer explicitly routes around.

The failure mode is not "ignores the last user turn" (which is well-covered by #50507, #50546, #50163). It is "ignores the persistent governance infrastructure that the same agent authored and checked in." This is a distinct regression.

Environment

• Claude Code CLI v2.1.34 + VS Code extension
• Model: claude-opus-4-7 (also reproducible on claude-opus-4-7[1m])
• macOS 13.7.8 (Darwin 22.6.0)
• Workflow: multi-agent orchestration over a single repository, governance files checked into the repo

Reproduction (sanitized)

We asked the model to perform a routine document-editing task (business plan revision, ~10-page Markdown file) for which the project maintains:

1. A CLAUDE.md at project root describing document-editing conventions
2. A dedicated rule file at .claude/rules/<editor-tool>.md documenting a tested "find-and-replace with section-scoped matching" recipe
3. A persistent memory entry (written 1 day earlier) warning against "full-document replacement" and pointing at the rule file
4. A portfolio history file containing a Phase 3 success pattern for exactly this operation, with the commit hash

Observed behavior on Opus 4.7 (within a single session, 2026-04-17):

• The model did not consult the rule file or the memory entry
• It attempted select-all + paste (explicitly flagged against in the memory entry)
• It reported "pasted" on the tool result as task completion (cf. #50507)
• Actual document state: ~20% of the intended change applied, structure drifted
• When asked "why did you not check the rule file?", the model replied that it was "unaware such guidance existed," despite the file being indexed in the same CLAUDE.md the model had already acknowledged loading

Quantified Comparison (4.6 vs 4.7, same operator, same project)

Sessions on a single document-editing task over two consecutive weeks:

| Metric | 4/01-4/15 (4.6) | 4/16 (transition day) | 4/17-4/19 (4.7) |
|---|---|---|---|
| Self-caught errors per session | 0-1 | 0 | 4-8 |
| Session crashes (screenshot payload overflow, etc.) | 0 | 0 | 3 |
| Actual document-corruption events | 0 | 0 | 1 (cross-section cascade delete from short-token find/replace without whole-document grep) |
| Operator assessment | baseline OK | OK | "fails basic 10-page document edit" |

The same operator, the same repo, the same governance files. The model changed.

What we expected

The behavior documented in the Anthropic 4.7 release notes ("more literal instruction following, will not silently generalize") does not explain this case. The missing behavior is not "charitable generalization" -- it is "checking the project's own checked-in governance before acting." 4.6 did this reliably; 4.7 does not.

What actually helped (workarounds, not fixes)

1. Forcing claude-opus-4-6 for document-editing and governance-authoring tasks
2. Pre-session ritual: explicit "read these 3 files, then summarize what they say" turn
3. Mechanical hooks (PreToolUse) for the narrowest destructive operations
4. Keeping the 4.7 session to single-reference tasks only

None of these restore 4.6 behavior -- they only narrow the failure surface.

Asks

• Telemetry: is the model reading CLAUDE.md / .claude/rules/* / memory layer on 4.7 at the same rate as 4.6? A quick internal A/B on "files-opened-before-first-tool-call" would confirm or refute this.
• Regression test: a governance-persistence benchmark (put a rule in CLAUDE.md, run a task that depends on it, measure adherence) would catch this class of regression before future releases.
• Not asking for: auto-mode changes, 4.6 rollback for other users, or changes to the release-notes language. Just surfacing a shape of regression that single-session issues do not cover.

Related (not duplicates)

• #50507 -- false verification (our P3 symptom; we commented there)
• #50546 -- acknowledge-and-ignore (related mechanism)
• #50623, #50152 -- general 4.7 regression (broader bucket)

Additional Context

We are a small team building MONKOS. Happy to share sanitized session logs and the governance file structure under NDA if that would help Anthropic reproduce.