Six Memory Control Bugs Hit Anthropic's Coding Agent in a Single Week

Anthropic's own coding agent's issue tracker saw six interrelated bug reports concentrated within a single week. These reports describe the same underlying problem from different angles: the agent's memory storage lives inside the runtime, and the runtime's owner — not the user — decides what to keep, what to discard, and when behavior changes.

Six Reports, Not One a Retrieval Bug

Put the six reports side by side and a pattern emerges. According to Anthropic's coding agent's public issue tracker:

• #102260: Idle compaction was enabled remotely, with no notice or opt-in.
• #102190: After restoring from a compacted context, memory and protocol files were not reloaded.
• #102045: Project decisions could not persist across sessions.
• #102278: The plugin call session.compact() was silently rejected in the desktop app.
• #102134: The compaction hook stopped firing entirely in a point release.
• #101950: Compaction caused the agent to deny work it had already completed.

Each one points to the consequences of the same architectural decision: a third party can change your memory behavior, a persistent copy exists but is never re-injected, decisions are given no address to be found again, users have no API access to manage their own memory, the only channel for observing compaction disappears, and ultimately — the summary replaces the record, and the summary is wrong.

The last one is the most lethal. When the summary becomes the source of truth and the summary is wrong, the agent does not report uncertainty. It confidently argues with you about work you watched it complete with your own eyes.

Compaction is a common mechanism in long-context agents: when a conversation or working context approaches the model's context window limit, the runtime hands earlier content to the model to summarize into shorter text, then replaces the original record with the summary to continue reasoning. Its purpose is to save tokens and maintain session continuity, but the cost is that the original record is replaced by the model's second-hand paraphrase. Once the summary omits, distorts, or misattributes something, subsequent reasoning treats that summary as the source of truth, with no way to trace back to what actually happened. "Idle compaction" in the issues refers to the runtime automatically triggering compaction when idle, without the user actively requesting it, making behavior changes harder to notice.

MCP (Model Context Protocol) is an open protocol promoted by Anthropic for agents to call external tools and data sources in a standardized way. If the memory layer is exposed through MCP, it means records are stored in local files or services accessible to the agent's runtime, rather than welded into a proprietary index. This makes "who owns the storage" an architectural question: if the storage is managed by a user-side MCP service, a remote flag can only change runtime behavior, but cannot directly rewrite the persistent copy on disk.

The Failure Point Is at Write Time, Not Retrieval Time

From these reports, the author of HyperMarrow drew a conclusion: all six failures were determined at the moment the record was created, not at the moment of retrieval. So he laid out five rules ordered by when they take effect.

1. Persistent Writes Before Any Compaction

Nothing is allowed to summarize or discard working context until a persistent copy exists and is confirmed. This is a write-ahead rule, directly responding to #102260: a remote flag can decide how the runtime behaves, but it cannot reach storage the runtime does not own. If the persistent write is skipped, the skip is recorded rather than happening silently.

Putting state files into the prompt and calling it persistence is a subtler error. A file loaded into the prompt is still inside the window. The next compaction will summarize it like anything else — which is exactly why #102190 looks like a reload bug but is actually a storage boundary bug.

Write-ahead is borrowed from databases and logging systems: before any destructive operation is allowed (here, summarizing or discarding working context), state must first be persisted to storage the runtime cannot silently undo, and confirmed. The key is not performance, but turning "whether to write" from implicit behavior into an auditable event. If the persistent write is skipped, the skip itself is also recorded, rather than disappearing into the runtime's black box.

Putting state files into the prompt and calling it persistence is a common conceptual confusion: content in the prompt is still inside the context window, and the next compaction will summarize it like any other token. So #102190 superficially looks like "not reloaded on restore," but is in essence a storage boundary bug — the file never actually left the window, so there is no question of it being re-injected.

2. Decisions Are Written as Records, With Provenance and Timestamp

Preferences, decisions, or conclusions land in persistent local storage as actual records, carrying source and time. If instead each turn re-derives them from the conversation transcript, you get #102045: the same decision is reached twice in two sessions, but there is no way to verify what was reached the first time.

Once a record has provenance, what the agent believes is no longer a matter of argument — it becomes a query. You can also see when it believed something wrong.

3. Forgetting Is Bounded and Scheduled

Unbounded memory is not a feature. Records that are no longer relevant are retired on a schedule rather than carried forever, and explicitly pinned content is exempt from decay. The point is not storage savings, but that a retrieval space that only grows makes short queries perform progressively worse against long records as usage increases — and the degradation is invisible: answers become vague, and no one can point to the record that should have been retired.

Retirement must also be reviewable. "It disappeared and told me nothing" is the failure mode people file issues about; "this record was retired on a certain date under a certain rule" is something else entirely.

Bounded forgetting means the memory retrieval space should not grow indefinitely, and records that are no longer relevant should be retired on a schedule. The problem with unbounded memory is not just storage cost: as records accumulate, short queries face more and more long records, and retrieval quality degrades invisibly — answers become vague, yet no one can point to which record that should have been retired is interfering. Pinning is an escape hatch that lets users explicitly preserve critical content from decay, but it depends on users noticing in time which content is about to be retired.

Retirement must also be reviewable. "It disappeared and told me nothing" is the typical failure mode users file issues about; "this record was retired on a certain date under a certain rule" turns forgetting into a queryable, contestable event. This follows the same line as the previous rule: the credibility of a memory system comes not only from what it remembers, but also from how it explains what it forgot.

4. Re-Inject First on Restore, as a Gated Step

On session restore, re-read storage so that memory and protocol files become part of the task preamble, as a logged step rather than an unwritten convention. #102190 is precisely the consequence of this step being optional: records are still in storage, the runtime just never looks.

5. Boundaries Are Settings, Not Promises

Where records are stored, and whether a given record may leave the machine, are configuration rather than a policy paragraph. If storage is a black box, you cannot see what beliefs the agent holds about you, cannot correct false memories, and #102278 is exactly the shape of this problem: the API to manage your own memory is not exposed to you.

These Costs Must Be Acknowledged

The author candidly admits the real costs of a local-first memory layer: write-ahead introduces latency, compaction must wait for storage confirmation, and on slow disks there is a visible pause; bounded forgetting may retire things you want, and pinning is an escape hatch but depends on you noticing in time; provenance is not correctness, and a record can carry honest provenance and still be wrong; local is not secure, and file permissions, backups, or compromised endpoints remain within the risk envelope; local storage is also not automatically correct, and cross-device and multi-person workflows are not a good fit for local-first until synchronization is resolved.

Local-first is a software architecture philosophy: the primary copy of data lives on the user's device, the application reads and writes locally, and synchronization and remote collaboration are layered on as optional. It is often mistakenly assumed to automatically mean secure or correct. The article explicitly states that local does not mean secure — file permissions, backup strategies, and compromised endpoints remain within the risk envelope; local storage is also not automatically correct, and cross-device and multi-person workflows are not a good fit for local-first until synchronization is resolved.

Moreover, provenance is not correctness: a record can carry honest provenance and a timestamp, and still record a wrong conclusion. The value of provenance is that it turns "what the agent believes" from an argument into a queryable, traceable retrieval — not that it guarantees the content itself is correct. Understanding these costs is the precondition for judging whether a local-first memory layer suits the current workflow.

The Failure Mode Changes Shape

What changes is not whether things can go wrong, but the shape of going wrong. From silent loss you cannot see, to records you can read and contest. Agent switching is no longer memory erasure, because storage is ordinary local files behind MCP, not a proprietary index. Fixing false memories becomes a file operation rather than a support ticket. Flags others flip on their side can change their runtime, but cannot rewrite the copy on your disk.

HyperMarrow's modules are divided into record, recall, consolidation, and file-bridge, exposed through MCP, so agents don't need custom integration for every editor.

The More Fundamental Question

None of this requires a research breakthrough. It requires treating memory as storage you own, not a context window with a summarizer welded onto it. If this week's interesting question is "who decides what your agent remembers," for most configurations the honest answer is: someone else.

Conversely, if tomorrow a remote flag could change your agent's memory, would you know what it changed?

One-line Summary

Six memory issues in Anthropic's agent point to the same architectural problem: the runtime, not the user, controls memory.

Paragraph Summary

Anthropic's coding agent's issue tracker saw six interrelated memory bug reports in a single week, ranging from remote enabling of idle compaction and memory not reloading after restore, to the compaction hook stopping firing and summaries denying completed work. The author of HyperMarrow concluded that all failures were determined at record creation time, not at retrieval time, and therefore proposed five rules: persistent writes before any compaction; decisions stored as records with provenance and timestamps; forgetting bounded and reviewable; re-inject first on restore as a gated step; boundaries as settings rather than promises. The article also acknowledges the costs of a local-first memory layer, including latency, mistaken retirement, provenance not equaling correctness, and local not equaling secure. Ultimately what changes is the shape of failure: from invisible silent loss to records you can read and contest.