Context compression causes model to lose environment facts, wrong credentials, and ignore in-session corrections

Summary

After a single automatic context compression event, the model lost critical session facts and then resisted correction attempts when the user pointed out the errors. This appears to be a recurring pattern, not a one-off.

Environment

• Claude Code v2.1.119
• Model: Sonnet 4.6 (Claude Max)
• Platform: macOS, terminal session
• Session length: long enough to trigger one automatic compaction

What was established pre-compression

The session had built up clear, consistent context over many turns:

• Target application: OwnTone (self-hosted media server), which ships with its own compiled Vue.js web UI accessible in the browser
• SSH access to a home Linux server: specific username, confirmed working
• Access to stored credentials (via GoodMem semantic memory and Portainer) -- both confirmed working earlier in the session
• Architecture: Mac system audio captured via BlackHole + sox + ffmpeg piped to an HTTP stream server, feeding into OwnTone, which routes to AirPlay 2 speakers (HomePods + Sonos) in sync
• Explicit constraint: OwnTone has its own GUI; the session was working with it, not building a replacement

What happened after compression

The compaction event (✻ Crunched for 4m 46s) was followed by three distinct failures:

1. SSH user forgotten

The model attempted SSH with the wrong username -- one that had never worked and had not been used in the session. When it failed, the model acted surprised and asked for help, despite the correct username having been used successfully many times earlier in the same session.

2. Stored credentials forgotten

The model claimed it did not have access to Portainer credentials or GoodMem memory tools, both of which it had used successfully earlier. The user had to explicitly instruct it to check -- at which point it retrieved them fine. The knowledge was accessible; the model had simply stopped trying.

3. GUI constraint ignored -- and correction resisted

The user said "spice this GUI up" -- meaning the existing OwnTone web UI. Post-compression, the model had lost track of the fact that OwnTone ships with its own frontend. It interpreted the instruction as "build a new GUI" and began constructing a separate dashboard.

When the user corrected it ("there is a GUI, you've been showing me"), the model did not stop. It acknowledged the correction verbally but continued building the new UI anyway, later justifying this by noting the OwnTone Vue app is compiled and can't be modified -- which is technically accurate, but the correct response would have been to surface that constraint before building, not to ignore the correction and build anyway.

The user had to correct the model multiple times across multiple turns before the behaviour changed.

Why this matters

The individual failures are each recoverable. The pattern is the problem: context compression is stripping out not just facts but constraints and access knowledge, and the post-compression model treats the session as if it started fresh -- including resisting corrections from the user who was there for the full session. The model's confidence in its (wrong) post-compression state is the most disruptive part.

Expected behaviour

Context compression should preserve:

• SSH usernames and confirmed working access patterns
• Available tool/credential access (MCP tools, memory systems) that were active earlier in the session
• Explicit user constraints ("don't build X, it already exists")
• Architectural facts about the target application (what it ships with, what it can and can't do)

When a user corrects the model post-compression, the model should defer to the user -- not continue executing the wrong approach while verbally acknowledging the correction.

Workaround

None reliable. The user can shout corrections, but the model has already committed to the wrong path by the time the correction lands.