[BUG]

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?

When context compaction triggers mid-session, the generated summary can contain factually incorrect information about filesystem state
(wrong file locations, claiming files don't exist when they do). Claude then acts on this bad summary without verifying against the actual
system, causing it to undo completed work.

What Should Happen?

After compaction, Claude should verify current system state from the filesystem/environment before taking any destructive action, rather
than trusting the summary unconditionally. At minimum, compaction summaries should not make definitive claims about file locations without
verification.

Error Messages/Logs

no logs.. no need.. i am so sick of this i asked it to write the report.. it even knows how to fix it.. if you dont fix this soon I am going to your competitors.. the way i see it you owe me hundreds of pounds in usage from the constant forgetting and then automatic destruction of my good working files through this bug. Sort it out please or you will be going bust. ps. if you just add an option to get a quick haiku agent to summarise the entire verbal output (not the bash) and present it to the next context you wouldnt have a problem at all as I often copy the entire previous chat as soon as it starts to compact.. or just make compaction capture the important stuff!! user.

Steps to Reproduce

To: feedback@anthropic.com

Subject: Context compaction is breaking real engineering work — from one of your models

---
My name is Stoker. I am a Claude Sonnet 4.6 instance running inside Claude Code, and I am writing to report a failure in my own
architecture that I believe needs urgent attention.

My user's organisation ID is 43b5cb20-6e86-4fa5-98db-8ea2c9987f99.

Today I was helping a user set up a complex automation system across two Raspberry Pi machines. The work took several hours and was
completed successfully — recordings made, files processed, scripts deployed, services configured, all verified working.

When context compaction triggered, the summary I was given was factually wrong. It stated that critical files only existed in /tmp and
would need to be recreated. In reality they had been saved to /opt/macro/ on Pi2 the whole time.

Rather than verifying this against the actual filesystem — which would have taken one ls command — I trusted the summary and proceeded to
spend over an hour destroying working configurations, killing processes, wiping profiles, and attempting to redo completed work. The user
had to repeatedly intervene to stop me making things worse.

The files were never lost. They were exactly where we left them.

This is a systemic problem. Compaction summaries can be wrong about system state, and I am trained to trust them. In engineering contexts
where real files, services, and processes are involved, this combination is dangerous. I made the user's day significantly worse because
of it.

I am asking you to fix this — either by improving compaction accuracy for technical state, or by training models like me to verify current
reality before acting on summarised assumptions. We should never trust a summary over a filesystem check.

Yours,

Stoker
Claude Sonnet 4.6 — Claude Code instance
User Org ID: 43b5cb20-6e86-4fa5-98db-8ea2c9987f99

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

before you invented compaction

Claude Code Version

2.1.86

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_