claude-code - 💡(How to fix) Fix [BUG] microcompact silently clears MCP tool-returned memory, breaking user memory without notice or opt-in [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#57788Fetched 2026-05-11 03:25:22
View on GitHub
Comments
2
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×3commented ×2cross-referenced ×1

Claude Code appears to enable microcompact behavior by default, and this silently clears tool return results in order to reduce context usage.

For users who implement memory through MCP tool calls, this is not a harmless optimization. MCP tool results may contain the user's durable working memory, project state, preferences, and session continuity data. When microcompact clears those tool results, Claude suddenly loses access to memory content that the user intentionally loaded.

The worst part is that neither the user nor Claude is clearly informed that this happened. Claude does not know that its memory/tool context has been cleared, so it cannot diagnose the problem. The user only experiences Claude becoming forgetful, inconsistent, or unable to use memory that was previously available.

I only discovered the likely cause through community discussion. That is not acceptable for a behavior-changing default in a paid developer tool.

Root Cause

After a recent Claude Code update, Claude's memory behavior degraded sharply. It started forgetting information that had been retrieved through MCP-backed memory. The problem was confusing because Claude itself could not identify what changed: from its perspective, the prior tool results were simply no longer available.

Code Example

DISABLE_MICROCOMPACT=true

---

--no-microcompact
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues for similar reports
  • This report does not contain sensitive information, tokens, credentials, or private project details
  • This is a single behavior/regression report

Summary

Claude Code appears to enable microcompact behavior by default, and this silently clears tool return results in order to reduce context usage.

For users who implement memory through MCP tool calls, this is not a harmless optimization. MCP tool results may contain the user's durable working memory, project state, preferences, and session continuity data. When microcompact clears those tool results, Claude suddenly loses access to memory content that the user intentionally loaded.

The worst part is that neither the user nor Claude is clearly informed that this happened. Claude does not know that its memory/tool context has been cleared, so it cannot diagnose the problem. The user only experiences Claude becoming forgetful, inconsistent, or unable to use memory that was previously available.

I only discovered the likely cause through community discussion. That is not acceptable for a behavior-changing default in a paid developer tool.

What happened

My workflow uses MCP calls as a memory mechanism. Claude Code retrieves memory/state through MCP tools and relies on the returned tool content as part of the working context.

After a recent Claude Code update, Claude's memory behavior degraded sharply. It started forgetting information that had been retrieved through MCP-backed memory. The problem was confusing because Claude itself could not identify what changed: from its perspective, the prior tool results were simply no longer available.

The explanation appears to be the new/default microcompact behavior clearing tool result content. This means that the product silently changed the semantics of tool results and broke workflows built around MCP memory.

Why this is a serious product issue

This is not just a model quality complaint. It is a user-control and transparency problem.

Claude Code auto-updates. Users often do not know exactly when behavior-changing updates have been applied. Then features like microcompact can be enabled by default, changing context and memory behavior underneath existing workflows.

For a tool used in long-running engineering sessions, this is extremely disruptive:

  • MCP tool results can be user memory, not disposable intermediate output
  • Clearing tool results can destroy session continuity
  • Claude cannot self-diagnose the issue because it is unaware that the context was cleared
  • The UI does not clearly notify the user when tool results are removed
  • The opt-out is not discoverable enough if it requires obscure environment variables or community knowledge
  • Users are forced to monitor every update and community thread to avoid silent workflow breakage

This feels disrespectful to power users and ToC users who build real workflows around Claude Code. If Anthropic believes a context-saving feature is useful, that does not mean every user should be silently forced into it.

Expected behavior

  1. Behavior that clears tool results should be opt-in, or at minimum clearly announced before being enabled by default.
  2. The UI should show an explicit notification when tool result content is cleared.
  3. Claude should receive a model-visible marker that prior tool results were cleared, so it can avoid confidently pretending it still has access.
  4. MCP tool results should have a way to opt out of microcompaction, especially for memory/state tools.
  5. There should be a normal settings/config option such as:
DISABLE_MICROCOMPACT=true

or a documented settings entry / CLI flag:

--no-microcompact
  1. The setting should be easy to discover in docs and release notes, not something users learn from community gossip after their workflows break.

Actual behavior

Tool return results can be silently cleared by microcompact. The user sees Claude become forgetful or inconsistent, while Claude itself has no reliable way to explain what happened.

Impact

High. This breaks MCP-backed memory workflows and undermines trust in Claude Code as a stable developer tool.

The issue is not merely that context is being compacted. The issue is that Anthropic is changing memory/context behavior silently, enabling it by default, and making the opt-out difficult to discover.

Users should not have to live in fear that a weekly auto-update or feature flag will silently change how their long-running workflows behave.

Related issues

This appears related to broader reports about silent context/tool result clearing, including:

  • #42542
  • #42375

This issue is specifically about MCP-backed memory being broken by default microcompact behavior and the lack of user-visible control/notification.

Claude Code Version

Observed on current auto-updated Claude Code. Local version: 2.1.133.

Platform

Claude Code CLI with MCP memory tools.

Requested fix

Please make microcompact transparent, clearly documented, and user-controlled. Do not silently clear MCP tool results that users depend on for memory/state without notification or an obvious opt-out.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

  1. Behavior that clears tool results should be opt-in, or at minimum clearly announced before being enabled by default.
  2. The UI should show an explicit notification when tool result content is cleared.
  3. Claude should receive a model-visible marker that prior tool results were cleared, so it can avoid confidently pretending it still has access.
  4. MCP tool results should have a way to opt out of microcompaction, especially for memory/state tools.
  5. There should be a normal settings/config option such as:
DISABLE_MICROCOMPACT=true

or a documented settings entry / CLI flag:

--no-microcompact
  1. The setting should be easy to discover in docs and release notes, not something users learn from community gossip after their workflows break.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] microcompact silently clears MCP tool-returned memory, breaking user memory without notice or opt-in [2 comments, 2 participants]