block
Goose Desktop auto-compacts new sessions after removing custom MCP extension
Bug: Goose Desktop auto-compacts new sessions after removing custom MCP extension
Describe the bug
Goose Desktop immediately shows “Context limit reached. Compacting to continue conversation…” on brand-new chat sessions, before any user input, after adding and attempting to remove a custom MCP extension.
Even after the UI reports “Successfully removed extension”, the extension appears to remain enabled internally, and the auto-compaction behavior persists across restarts. This makes Goose unusable for new sessions unless application state is manually reset outside the app.
To Reproduce
- Install Goose Desktop on macOS.
- Add a custom MCP extension (local MCP server).
- Use the extension in one or more long or multi-agent sessions.
- Attempt to remove or disable the extension via Extensions → Remove.
- Goose shows a success toast (“Successfully removed extension”).
- Start a new chat session.
- Observe that Goose immediately displays:
“Context limit reached. Compacting to continue conversation…” before sending any message.
Additional observations:
- Happens even with chat recall disabled.
- Happens on completely new sessions.
- Restarting Goose does not resolve the issue.
- UI token counts appear small, but compaction still triggers immediately.
Expected behavior
- Removing or disabling a custom MCP extension should fully unregister it.
- New chat sessions should start with an empty context.
- If persistent extension state exists, Goose should either:
- reflect that the extension is still active, or
- provide a supported way to clear/reset extension state.
Actual behavior
- The extension appears removed in the UI but continues to affect session startup.
- Goose auto-compacts immediately on new sessions.
- The extension cannot be reliably disabled or removed via the UI once this state occurs.
- Manual deletion of Electron/macOS container data is required to recover.
Environment
- OS: macOS (Apple Silicon)
- Goose Desktop: latest at time of report (please fill in exact version)
- Extensions: Custom MCP extension (local MCP server)
- Model: Claude 3 Haiku (likely not model-specific)
Additional context / suspected cause
This appears related to persisted extension state in Electron/macOS containers (e.g. IndexedDB / Local Storage / sandboxed Containers), where:
- The UI reports successful extension removal
- But extension registry or cached tool state is rehydrated at startup
- Leading Goose to believe a large context already exists before user input
Clearing only ~/Library/Application Support/goose was insufficient; full recovery required deleting Goose’s macOS container data.
Impact
This makes Goose Desktop fragile for workflows involving:
- custom MCP extensions
- long or multi-agent sessions
- experimentation with tools
A single failed extension lifecycle can render Goose unusable until manual state cleanup is performed outside the app.
Willing to provide
- Screenshots of the Extensions UI showing removal
- Steps that reliably recover the app
- Logs or diagnostics bundle, if supported
thanks for the report. does this happen with any extension or can you point to a particular one? also if you have a diagnostics report laying around, that could be helpful too
