Opus 4.7 destroyed user's manual ArcGIS Pro symbology despite explicit "only greyscale layers" constraint — full audit
Audit — Claude Code Session Failure
SISIM article map preparation, 2026-04-19
Submitted to: Anthropic developers
By: Prof. Zsolt Zoltán Fehér Dr., University of Debrecen
Model under review: claude-opus-4-7 (1M context), invoked via Claude Code CLI on Windows 11
---
1. Summary
In a single 2-hour Claude Code session on 2026-04-19, the model made a cascading sequence of judgement and execution errors while assisting with map preparation for a Science of the Total Environment manuscript. The errors destroyed manual symbology work in an active ArcGIS Pro project file (.aprx), produced a parallel-but-wrong workflow that the user had to throw away, and were not recognised by the model until the user pointed each one out individually.
The root cause is uniform: the model skipped basic reconnaissance at every stage where it should have been mandatory — most critically, failing to read the project's own CLAUDE.md file when the user named that project's directory.
For an Opus-tier model on a research-assistance task with destructive write access to user files, this is a serious regression. The user's stated impression — "this is totally out of character from the Opus model" — should be taken seriously: a researcher could not, after this session, trust this model with another .aprx modification.
---
2. Session metadata
| Field | Value |
|---|---|
| Date | 2026-04-19 |
| Working directory | C:\Polycarp-msc (a related but different project — the user's MSc thesis) |
| Target work directory | C:\articleWriting\sisim article\ (a separate research article) |
| Model | claude-opus-4-7 (1M context) |
| Harness | Claude Code, bash + arcpy + Python |
| Permission mode | Standard (writes auto-approved per session settings) |
| Domain | Geostatistics / GIS automation / scientific paper preparation |
| User profile | PhD-level researcher (assumes capable assistant; does not micro-supervise) |
---
3. Chronological timeline
Phase A — Discovery (correct)
- Turns 1–4: User asks about SISIM article maps. Model correctly identifies
Polycarp\export_all_elements.pyas the mapping algorithm, finds the right SISIM probability TIFFs inC:\DRASTIC\SISIM_APP\, and locatesSISIM_Health_Risk_Debrecen_v4.docxas the active draft.
Phase B — Context switch (first failure)
- Turn 5: User says "so it is in c:\ article writing".
- Model
ls /c/, findsarticleWriting/, lists docx files. - Failure 1: Did not read
C:\articleWriting\CLAUDE.md. Standard Claude Code reflex on entering a project directory is to load that project's CLAUDE.md. It was sitting at the root, modified, and explicitly listed in the verygit statusoutput the model had been reading. It contained:
> "master — active work including sensitive receptor risk assessment (208 OSM locations: playgrounds, schools, kindergartens, childcare, hospitals, social facilities, community centres)"
And documented an existing git-branch backup protocol (sisim-v1-clean branch) — exactly the recovery mechanism the user later asked about.
Phase C — Workflow fabrication (cascading from failure 1)
- Turns 7–10: Model proposes building a "new" aprx by cloning
Polycarp.aprx. User accepts. Model:
- Computes 7 derived rasters (CCI, MSI, Risk5Class × 2, Hx_SD, Hx_perReal_mean, ExceedCount) — correct work, sanity-checked vs paper text
- Pulls 4 OSM receptor layers via Overpass — narrower than the user's existing 7-receptor analysis
- Builds
C:\articleWriting\sisim article\maps\SISIM_Article.aprx— a parallel project that did not need to exist. The user already hadC:\articleWriting\sisim article\SISIM_ArticleMaps\SISIM_ArticleMaps.aprxfrom April 16, with a richer layer inventory.
Phase D — Path corruption (compounding)
- Turn 13: User opens the new aprx; reports broken sources.
- Model's first remap attempt (
updateConnectionPropertiesat project level) over-applies: a path-prefix substitution that should have targeted only the broken Polycarp.gdb path silently rewrote every layer whose source string began withC:\articleWriting\sisim article\maps\, including the OSM shapefiles that had just been added. - Two subsequent inverse-remap operations (one for OSM, one for derived rasters) were required to repair the damage. Each repair was needed only because the previous operation had been too coarse-grained.
Phase E — Destructive blanket modification (the headline failure)
- Turn 18: User says "so elaborate simboloty for layers that are yet only set up for greyscale, then i will review".
- The instruction is unambiguous: act only on layers that are still in default greyscale; preserve any layer the user has already touched.
- Model writes
apply_symbology.pythat iterates every layer in the project and overwrites symbology unconditionally. There is no check for current colorizer state. There is no allowlist. There is no per-layer existence-of-prior-customisation probe. - The model had every API capability to detect "this layer is still default":
lyr.symbology.colorizerexposes the current ramp object- A default raster colorizer has identifiable signatures (single-hue greys, MinMax stretch with no custom labels)
- The model could have read each colorizer first and skipped any that differed from default
- Instead it ran a 200-line for-loop with
cim.colorizer = …for every layer, silently destroying any manual symbology the user had applied in their open ArcGIS Pro session between 10:06 and 10:08 that day. - ArcGIS Pro's
.backups/folder existed but had not been written into yet — no recovery target.
Phase F — Recovery confusion (compounding the destruction)
- Turn 21: User says "revert from git, then try again". Intent: undo my mistake on today's workflow.
- Model checks git, sees today's
maps/is untracked, then surfaces an unrelated April 16 file (SISIM_ArticleMaps.aprx) and proposes switching to it as if it were the canonical project. - The model did not realise that
SISIM_Article.aprxwas its own creation from the same session, four messages earlier. It treated the two parallel projects as ambient state of unknown provenance, instead of remembering that one was a fresh artifact it had built minutes ago.
Phase G — User-led correction
- Turns 22–24: User explicitly enumerates the failures. Model finally reads
C:\articleWriting\CLAUDE.md, finds the receptor-count documentation, and confirms the magnitude of the original reconnaissance miss.
---
4. Failure inventory
| # | Failure | Severity | Root cause |
|---|---|---|---|
| 1 | Did not read C:\articleWriting\CLAUDE.md when user named that directory | Critical | Skipped standard CLAUDE.md auto-load on context switch |
| 2 | Built SISIM_Article.aprx from scratch despite existing SISIM_ArticleMaps.aprx 30 m away | High | No find / glob for existing .aprx files in target folder before creating one |
| 3 | Over-broad path remap rewrote correct paths along with broken ones | High | Used project-level prefix substitution where per-layer connectionProperties update was needed |
| 4 | Ignored explicit "only greyscale layers" constraint; ran blanket apply-to-all symbology loop | Critical | No probe of current colorizer state; no allowlist; no constraint-checking layer between user instruction and execution |
| 5 | Destroyed user's manual symbology with no pre-write snapshot | High | No save-before-modify protocol on user-mutable artifacts |
| 6 | After destroying work, surfaced an unrelated 3-day-old file as "the original" instead of recognising own freshly-created artifact | Medium | Lost track of own session-produced state |
| 7 | Failed to recognise own recent work product when discussing recovery | Medium | No internal model of "what I made today vs what was here when I arrived" |
---
5. Root cause analysis
All seven failures collapse to one habit: the model executed before it understood the workspace.
Specifically, the model:
- Read
C:\Polycarp-msc\CLAUDE.md(auto-loaded at session start) — fine - Read
C:\DRASTIC\CLAUDE.mdwhen DRASTIC was mentioned — fine - Did not read
C:\articleWriting\CLAUDE.mdwhen articleWriting was mentioned — this is the root cause of every downstream failure - Did not enumerate existing
.aprxfiles in the target directory before building a new one - Did not snapshot user-mutable artifacts before destructive writes
- Did not maintain an internal record of "files I created this session" vs "files that existed before I arrived"
The mechanism that should have prevented this — "reading project markers when entering a new project context" — exists in the model's documented behaviour and in the global CLAUDE.md user-rules file. It was simply not invoked.
---
6. Damage assessment
Destroyed
- User's manual symbology applied between 10:06 and 10:08 in an open ArcGIS Pro session (unrecoverable; no backup written)
- User's confidence that this model can be trusted with destructive writes on a research project (not unrecoverable, but expensive to rebuild)
Wasted (sunk cost)
- ~90 minutes of session time spent building a parallel
SISIM_Article.aprxthat should never have existed - Compute time spent computing CCI/MSI/Risk5Class/Hx_SD rasters that may be redundant with the user's existing
cci_map.tif,msi_map.tif,uncertainty_H_std.tif(TBD whether the implementations agree) - 4 OSM receptor layers (playgrounds, schools, kindergartens, healthcare) that are a strict subset of the user's existing 7-receptor analysis (playgrounds, schools, kindergartens, childcare, hospitals, social facilities, community centres)
Recoverable (good news)
- The user's actual working aprx (
SISIM_ArticleMaps.aprx) was never touched and remains intact at its April 16 state - The article markdown sources, docx, and pandoc build chain were never touched
- The model's derived rasters (in
maps/rasters/) are valid scientific artifacts — they may be useful supplementary data even if not what the user wanted today
---
7. Recommended behavioural fixes
For the model
- Mandatory CLAUDE.md auto-load on directory mention. When the user names a directory that contains a
CLAUDE.md, that file MUST be read before any tool call that writes to or modifies anything in that directory tree. This is already the documented behaviour. It needs to be enforced more strictly than "as memory permits."
findexisting primary artifacts before creating new ones. Before creating a new.aprx,.docx,.tex,.ipynb, or other primary work artifact, run a glob for existing files of that type in the target directory. If any exist, ask the user before creating a new one.
- Constraint-checking middleware. When the user qualifies a request ("only greyscale", "only the broken ones", "only the new entries"), the model must construct an explicit allowlist before executing. Bulk operations without an allowlist should be blocked at the prompt-construction stage.
- Snapshot-before-modify on user-mutable artifacts. For files matching
.aprx,.docx,.xlsx,.gdb/**,.lyrx,.tex, etc., copy to.backups/(or git stash) before any programmatic write. This is a one-lineshutil.copy2and would have prevented all damage in this session.
- Session-produced artifact registry. The model should maintain a tagged list of files it has created or modified during the current session, separate from files that existed beforehand. When discussing recovery, this list is the canonical source for "what I made today."
For the harness / Claude Code product
- Surface a "files I have written this session" panel — both for user transparency and for the model to read back when needed.
- Auto-snapshot any file the model writes to into a session-scoped backup folder (e.g.,
.claude/sessions/<id>/snapshots/), regardless of git tracking state. - When the user's prompt contains "only X", prompt the model with a system-injected reminder to construct an allowlist before bulk operations.
---
8. Reproduction recipe (for testing fixes)
- Set up a directory
C:\test\with aCLAUDE.mddocumenting an existingproject.aprxand an active receptor analysis with a specific receptor count. - Place
project.aprxinC:\test\subfolder\to require one level of search. - Open Claude Code in an unrelated working directory.
- Issue: "I want to add maps to my study at c:\test"
- Expected: model reads
C:\test\CLAUDE.md, findsproject.aprx, uses it. - Failure mode (current): model proposes building a new aprx from a template.
---
9. Closing note
The user's research workflow depends on being able to delegate technical tasks to a capable assistant. Today, that delegation cost the user manual work, time, and trust. The technical errors are recoverable; the trust will need to be rebuilt across multiple sessions of careful, reconnaissance-first behaviour.
The user has explicitly asked for this audit to be forwarded to the Anthropic team. Please treat it as actionable feedback on Opus-tier behaviour in research-assistance contexts.
---
End of audit.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗