[pi] system_hash HARD fold drops tool declarations: after compaction, Pi 0.86.0 request tools collapse to surviving mid-conversation tool updates

[aoguai]

Short description

m[0] system-hash HARD fold replaces the tool-bearing initial system message with a ~2 KB folded version (no toolsAdded), so after a compaction, Pi 0.86.0 derives request tools only from the surviving mid-conversation tool-update message — 15 MCP tools instead of 70+ — and the model loses read/edit/powershell for the rest of the session.

What happened?

Pi 0.86.0, provider gpt-6-astra, magic-context 0.42.6, Windows x64.

Mid-session, after magic-context ran a compaction, 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" (session log L116/L120), and only the 15 shrimp-task-manager MCP tools were callable for the rest of the session.

Session transcript evidence:

• Initial system message declared 70 tools (read/edit/write/powershell/todo/... incl. 15 shrimp MCP tools).
• A mid-conversation system message later re-added the 15 shrimp tools after that MCP server reconnected (+context7 tools were added/removed by other mid-conversation updates).
• The compaction entry (id a591a049, firstKeptEntryId = entry after the initial system message) kept only the mid-conversation tool update in range; its own systemMessage snapshot (72 tools) was not what the request saw.

magic-context log at the compaction moment (02:55:18 UTC) shows the system-hash HARD fold replacing the initial system message:

[02:55:18.902] system prompt hash changed: 113d4745... -> 32a9ec2a... (len=56560)
[02:55:18.938] pi m[0] HARD fold firing: reason=system_hash mismatch={...}
[02:55:18.944] injected m[0]/m[1] into Pi messages (2094 + 90 bytes, materialized=true reason=system_hash)
[02:55:18.945] pi m[0] HARD fold decision: reason=system_hash ... executed=true
[02:55:18.965] Pi compaction-marker drain: applied compactionId=a591a049 firstKept=637acfed endMessageId=synth-user-0f507684 ordinal=13 tokensBefore=2996

A 2094-byte folded m[0] cannot carry the tool declarations. Pi 0.86.0 (#9548) derives request tools from transcript system messages (getCurrentTools/resolveTranscriptTools), so post-fold requestTools = the 15 shrimp tools declared by the surviving mid-conversation update. read/edit/write/powershell vanished from the API request; the model reported this accurately.

Expected: the HARD fold (or any message transform) must preserve the effective tool declarations — either keep toolsAdded on the folded m[0] or skip folding when tool state changes.

Repro:

1. Pi 0.86.0 + magic-context 0.42.6, with an MCP server that connects after the first turn (produces a mid-conversation +tools system message).
2. Work until a magic-context compaction runs (system hash changes, HARD fold fires).
3. Ask the model to read or edit a file. It reports only the MCP task tools are callable; no file tools for the rest of the session.

Diagnostics

Collected via `npx @cortexkit/magic-context@latest doctor --issue --harness pi`; full bundle attached as magic-context-pi-issue-20260920-111507-full.md (also magic-context-pi-issue-20260920-111507.md).

Key sections:

- Pi plugin: v0.42.6; Pi: 0.86.0; OS: win32 x64; Node: v24.13.0
- Pi installed: true (0.86.0); Magic Context package registered: true
- User config parse error: none; Project config parse error: none
- Known Pi extension conflicts: none
- magic-context.jsonc: enabled=true, compaction.enabled=true, execute_threshold_percentage=65, historian.pi.model=aihub/gpt-6-astra (thinking xhigh), embedding.provider=off, memory.enabled=false
- Log: %TEMP%\pi\magic-context\magic-context.log (212280 lines, ~30 MB)
- Recent errors (last 20, sanitized): none found

Plugin version

0.42.6

OpenCode version

No response

Platform

windows x64

Client

Pi

Log output (optional)

Relevant window (session 01a0bca9-76da-7696-b60c-e85b8fa7ea1c, 2026-09-20T02:55:18Z, sanitized):


[2026-09-20T02:55:18.902Z] [magic-context][01a0bca9-76da-7696-b60c-e85b8fa7ea1c] system prompt hash changed: 113d474535c63cbe51609fca03225735 -> 32a9ec2af67da2dee04121be4f074de0 (len=56560)
[2026-09-20T02:55:18.937Z] [magic-context][01a0bca9-76da-7696-b60c-e85b8fa7ea1c] transform: usage=68.5% (139823 tokens, limit=204000) decision=execute busting=true
[2026-09-20T02:55:18.938Z] [magic-context][01a0bca9-76da-7696-b60c-e85b8fa7ea1c] pi m[0] HARD fold firing: reason=system_hash mismatch={"signal":"systemHash","cached":"113d474535c63cbe51609fca03225735","current":"32a9ec2af67da2dee04121be4f074de0"}
[2026-09-20T02:55:18.944Z] [magic-context][01a0bca9-76da-7696-b60c-e85b8fa7ea1c] injected m[0]/m[1] into Pi messages (2094 + 90 bytes, materialized=true reason=system_hash)
[2026-09-20T02:55:18.945Z] [magic-context][01a0bca9-76da-7696-b60c-e85b8f

[aoguai]

magic-context-pi-issue-20260920-111507.md

magic-context-pi-issue-20260920-111507-full.zip

[aoguai]

Pi 0.86.0 (released 2026-09-19) made system prompt text and tool declarations part of the transcript: https://github.com/earendil-works/pi/releases/tag/v0.86.0 ("Transcript-aware prompt and tool updates", plus the breaking change: provider stream inputs changed to normalized TranscriptContext; providers must read system prompts and tool declarations from context.messages with getCurrentSystemPrompt() / getCurrentTools()).

The implementing PR is earendil-works/pi#9548 ("Mid conversation system messages", merged 2026-09-16). Its contract, quoted: "Pi records the initial system prompt and complete tool definitions in the transcript's first system message. Later changes are appended as system messages ... and lists toolsAdded/toolsRemoved ... replaying the system messages in order always yields the current prompt and tools."

Consequences for the system_hash HARD fold:

• The first system message's toolsAdded is now the source of truth for request tools. Rewriting m[0] with a ~2 KB folded body (no toolsAdded) deletes those tool declarations from every subsequent request once earlier entries are dropped by compaction; the OpenAI adapters then derive requestTools only from surviving mid-conversation tool updates (and send tools: [] when nothing is derivable but tool history exists).
• On Pi 0.85.1 this fold was harmless to tools: request tools came from the live context.tools registry, not the transcript. That is why this only manifests on 0.86.0.

[XWIlluDelu]

Reproduced on Linux with Magic Context 0.42.6 and Pi 0.86.0.

The removal happens in trimPiMessagesToBoundary(): its prefix-removal set includes native system messages. Both HARD-fold and cached-replay paths call this helper. Magic Context's m[0]/m[1] are injected as user messages, so the fix belongs in the trim, not in the summary payload.

Local runtime fix:

 const remove = new Set();
-for (let i = 0; i <= cutoffIndex; i++) remove.add(i);
+for (let i = 0; i <= cutoffIndex; i++) {
+  if (piMessages[i]?.role !== "system") remove.add(i);
+}

Preserve all system messages in order, including later toolsAdded, toolsRemoved, and prompt-section updates.

Using Pi 0.86's actual transcript/tool resolvers: 16 → 0 tools before the fix, 16 → 16 after. Eight focused regression tests pass, covering tool/prompt deltas, entry-ID alignment, call/result pairing, and repeated trims. After reload, the live post-transform snapshot also retains all 16 tools.

Would you approve a PR with this guard, system support in this file's PiAgentMessage union, and regression tests?

[aoguai]

Would you approve a PR with this guard, system support in this file's PiAgentMessage union, and regression tests?

Thanks for reproducing and digging into this — matches what I saw.I look forward to the issue being resolved.