{"slug": "four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working", "title": "Four agent-memory bugs from real repos: idle compaction silently discards working context", "summary": "A developer building HyperMarrow, a local-first memory layer for agents, catalogued four recurring agent-memory bugs drawn from public issue trackers, including a widely used coding agent where idle compaction silently discards working context in long-running sessions with no opt-out. The writeup argues memory failures are write-time storage problems rather than retrieval or ranking problems, and proposes rules for pre-compaction writes, fact/decision/noise separation, scheduled decay, and addressable continuity.", "body_md": "Open a long-running agent session, walk away, come back. In at least one widely used coding agent, compaction can fire while the session is idle and drop context you still needed, with no way to opt out. The issue title says it better than I can: idle compaction silently discards working context in long-running sessions.\n\nThat report is not an outlier. Reading the public issue trackers of the major agent CLIs, the same handful of failures keeps showing up. They are not exotic edge cases. They are what happens when \"memory\" is really just a context window with a summarizer bolted on.\n\nI work on HyperMarrow, a local-first memory layer for agents. I treat these reports as a backlog rather than as talking points. Here are four of them, quoted from the trackers, and the write-time rule each one implies.\n\nSource: anthropics/claude-code issue 98747\n\nWhat happens: compaction is a background job. It runs when the session is idle, not when it is safe. Anything the summarizer judges low-value at that moment is gone, and the user never got a vote. A mirror-image report in another repo describes subagent-completion turns skipping preflight compaction, so a session over its threshold never gets compacted at all.\n\nThe rule: a write decision has to happen before compaction, not after it.\n\nIn our design, compaction is not allowed to be the first thing that touches recent state. Records, decisions and conclusions are written to the local store first, each with a source tag and a timestamp. Only then may the working context be summarized or dropped. If the summarizer throws something away, the durable copy is already on disk. That turns compaction from a data-loss problem into a view problem.\n\nSource: openclaw/openclaw issue 162764\n\nWhat happens: retrieval quality is treated as a ranking problem. It is usually a writing problem. If what you stored was already a lossy summary, no ranker can recover the sentence you needed.\n\nThe rule: decide at write time what is a fact, what is a decision, and what is noise.\n\nOur layer separates the three. Facts and decisions are stored verbatim and immutably. Noise is stored as a pointer, or not stored at all. Retrieval then has something exact to hit. When a recall misses, the first question is not \"which embedding model\", it is \"what did we fail to write down\".\n\nSource: anthropics/claude-code issue 98804\n\nWhat happens: everything is remembered forever, so stale agents, dead sessions and one-off experiments accumulate and start to pollute later decisions.\n\nThe rule: forgetting has to be bounded and scheduled, not manual.\n\nOur layer runs a decay pass. Low-value records fade along a curve, pinned records never fade, and nothing is hard-deleted while it is still referenced. The user should not have to be the garbage collector. A memory system that needs manual cleanup is not a memory system, it is a leak.\n\nSource: anthropics/claude-code issue 98768 (a feature request)\n\nWhat happens: users want to point at one paragraph from an earlier session. Today they can point at a whole conversation, or at nothing.\n\nThe rule: continuity has to be addressable.\n\nThis one is filed as a feature, and that is the interesting part. The distance between \"I remember your last chat\" and \"I can cite the exact paragraph from three sessions ago\" is where continuity actually lives.\n\nNone of this is exotic. It is the boring part of storage that most agent stacks skip, because a context window is good enough in a demo and the bill arrives later.\n\nThe useful question is not whether your agent has memory. It is where that memory lives, and what happens to it when the session ends. If the answer is \"in the context window\", these four bugs are already on your roadmap, whether or not you filed them.\n\nI am building HyperMarrow, the local-first memory layer described above. Docs and the client are here: [HyperMarrow](https://hm.qianshi.cool/api/v2/dl?from=devto).\n\nIf you maintain an agent runtime: which of these four have you hit, and which one do you consider unfixable?\n\n*(Disclosure: I build HyperMarrow, the local-first memory layer described above.)*", "url": "https://wpnews.pro/news/four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working", "canonical_source": "https://dev.to/qianqiuwanzi/four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working-context-562b", "published_at": "2026-10-02 02:00:55+00:00", "updated_at": "2026-10-02 02:14:23.177093+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models"], "entities": ["HyperMarrow", "Claude Code", "OpenClaw"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working", "markdown": "https://wpnews.pro/news/four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working.md", "text": "https://wpnews.pro/news/four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working.txt", "jsonld": "https://wpnews.pro/news/four-agent-memory-bugs-from-real-repos-idle-compaction-silently-discards-working.jsonld"}}