What happened?
pi 0.86.0, provider gpt-6-astra, extensions loaded (pi-mcp-adapter, @cortexkit/pi-magic-context 0.42.6).
After an extension-performed compaction mid-session, the model could no longer call read/edit/powershell. It said: "only task-management tools are actually callable; there is no read, edit, or terminal interface" — and only the 15 shrimp-task-manager MCP tools were called for the rest of the session.
The session log shows why: the initial system message declared 70 tools; later, a mid-conversation system message added 15 MCP tools after that server reconnected. The compaction entry's firstKeptEntryId pointed past the initial system message, so the kept transcript contained only the mid-conversation tool update. With 0.86.0 deriving request tools from transcript system messages (#9548, getCurrentTools/resolveTranscriptTools), the post-compaction request tools became just those 15 MCP tools. The compaction entry's own systemMessage snapshot (all 72 tools) was not used as the request tool source.
Steps to reproduce
- Start pi 0.86.0 with an MCP server that connects after the first turn, so a mid-conversation system message adds its tools (initial message: 70 tools; later system message: +15 MCP tools).
- Work several turns until a compaction runs whose firstKeptEntryId lands after the initial system message while the kept range still contains the mid-conversation tool update (triggered here by the magic-context hook).
- Ask the model to read or edit any file.
Observed: only the MCP tools remain reachable; the model reports it has no file tools; no read/edit/powershell call is possible afterwards.
Expected behavior
Compaction preserves the full effective tool declarations — e.g. the compaction entry's systemMessage snapshot should anchor the post-compaction transcript tool state — so requests keep all active tools.
Version
0.86.0 (Windows, PowerShell 7)
What happened?
pi 0.86.0, provider gpt-6-astra, extensions loaded (pi-mcp-adapter, @cortexkit/pi-magic-context 0.42.6).
After an extension-performed compaction mid-session, the model could no longer call read/edit/powershell. It said: "only task-management tools are actually callable; there is no read, edit, or terminal interface" — and only the 15 shrimp-task-manager MCP tools were called for the rest of the session.
The session log shows why: the initial system message declared 70 tools; later, a mid-conversation system message added 15 MCP tools after that server reconnected. The compaction entry's firstKeptEntryId pointed past the initial system message, so the kept transcript contained only the mid-conversation tool update. With 0.86.0 deriving request tools from transcript system messages (#9548, getCurrentTools/resolveTranscriptTools), the post-compaction request tools became just those 15 MCP tools. The compaction entry's own systemMessage snapshot (all 72 tools) was not used as the request tool source.
Steps to reproduce
Observed: only the MCP tools remain reachable; the model reports it has no file tools; no read/edit/powershell call is possible afterwards.
Expected behavior
Compaction preserves the full effective tool declarations — e.g. the compaction entry's systemMessage snapshot should anchor the post-compaction transcript tool state — so requests keep all active tools.
Version
0.86.0 (Windows, PowerShell 7)