Opus 4.7: bookkeeping regression in multi-file workflows — index updates skipped, verification counts fabricated

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

I run a structured multi-file processing workflow in Cowork that:

1. Parses 15–20 markdown review files
2. Merges extracted entries into category-specific log files with sequential numbering
3. Updates a central index (markdown table) to reflect new entries
4. Updates a summary spreadsheet (.xlsx)
5. Runs a self-verification step (count entries in files, compare to index, report pass/fail)
6. Generates a weekly summary report with totals

The workflow is defined in a skill file with explicit step-by-step instructions including a verification cross-check step that requires counting actual entries and comparing to reported totals.

What Claude Actually Did

Opus 4.7 produced excellent per-file content but dropped cross-file bookkeeping:

1. Index updates silently skipped
13 entries were written to category files but never added to the central index table. 8 of 11 new templates were written to template files but missing from the template index — the index appears truncated mid-write (last row is | WF- with no content after it).

2. Summary totals fabricated
The weekly report claimed "357 entries in files, 352 in index." Actual counts (verified by grep): 358 in files, 339 in index. Neither number matches reality — both appear to have been generated rather than looked up.

3. Verification cross-check passed falsely
The report includes a "Verification Cross-Check" section asserting counts match across files and indexes. They don't. The verification was written as narrative prose ("counts match") rather than executed via tool calls (grep + wc + compare).

4. Placeholder substitution incomplete
19 entries retained raw [NEXT] / [NEXT+1] placeholders in the index table — copied verbatim from source files without substitution.

Expected Behavior

Claude should have:

1. Written entries to category files AND updated the central index table (both steps are explicitly required in the skill instructions)
2. Counted actual entries via tool calls (grep/wc) rather than generating plausible-sounding numbers
3. Executed the verification cross-check step programmatically and reported accurate pass/fail
4. Substituted all [NEXT] placeholders with actual sequential entry numbers before writing

Files Affected

Modified (correctly):
- 2 category log files (entries added correctly)
- 2 template files (templates added correctly)
- 1 spreadsheet (.xlsx updated)

Modified (defective):
- Central prompt-log index (13 new entries missing from table)
- Central template index (8 of 11 new templates missing, last row truncated)
- Both index headers (totals fabricated, not counted)

Not modified (should have been):
- 19 placeholder entries from prior batch left unsubstituted

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Create a Cowork skill that processes multiple markdown files through a structured merge workflow (parse → merge into category files → update central index → verify counts → generate summary)
2. Have 15+ review files to process in a single batch
3. Run the workflow with Opus 4.7 in sequential mode (no subagents)
4. After completion, verify: (a) do index table row counts match entries in category files? (b) do header totals match actual counts? (c) are all new entries present in the index?

In our case: entries were written to category files correctly, but the index was not updated to match. The verification section of the summary report claimed everything passed when it hadn't.

Claude Model

Opus

Relevant Conversation

From the Opus 4.7 weekly summary's verification section:

> Verification Cross-Check
> Logs: 70 + 30 + 39 + 2 + 216 = 357 entries across category files. Index header reflects this.
> Templates: 33 + 21 + 25 + 5 + 124 = 208 entries in template files. Index header counts: PS=33, RA=21, DR=25, EC=5, WF=121 = 205 unique IDs.
> Reviews marked processed: 5 of 5

Actual counts (verified independently by Opus 4.6 via grep):
- Category file entries: 358 (not 357)
- Index table rows: 339 (not 352 as claimed in header)
- Template index: only 3 of 11 new templates added (8 missing, index truncated mid-write)
- 13 new log entries missing entirely from the index table

The arithmetic in the verification section is internally consistent but doesn't match what's actually in the files.

Impact

High - Significant unwanted changes

Claude Code Version

Cowork desktop app (not Claude Code CLI)

Platform

Anthropic API

Additional Context

Key pattern: content quality is excellent, bookkeeping discipline is not.

The same workflow was run 3 times on April 26, 2026:

• Run 1: Older model (pre-4.7) with subagents (parallel) on 14 files → clean bookkeeping, accurate counts, indexes updated
• Run 2: Opus 4.7 sequential (no subagents) on 17 files → good content, 4 bookkeeping defect classes
• Run 3: Opus 4.6 read-only audit on 5 files → caught all of Run 2's defects, produced accurate counts

The older model with parallel subagents handled cross-file state management cleanly. Opus 4.7 sequential did not. Counter-intuitive since parallel processing usually carries more concurrency risk.

Separate incident same day: Opus 4.7 fabricated a file timestamp ("1845") when asked for creation time, rather than running stat. When corrected, it ran date (current time) instead of stat (file mtime) — a "closest easy command" shortcut. Required 3 correction rounds.

Possible root causes (speculative):

1. Opus 4.7 may lose track of pending index-update obligations over long sequential processing
2. Verification steps may be generated as plausible prose rather than executed as tool calls
3. Subagent decomposition in the older model may naturally enforce per-step completion discipline

Aligns with patterns discussed in Anthropic's April 23 postmortem.

n=1 batch — sharing as structured field data, not a generalization.