The bug

When compaction runs, it sends the conversation history to an LLM asking it to generate a summary. For small/medium sessions this works fine — the history fits within the model's context window. But for long-running sessions where the history has grown past the model's 200k token limit, the summarization call itself gets rejected: 448694 prompt tokens > 200000 maximum.

That's exactly what the compaction.mode: "safeguard" extension is supposed to prevent — it hooks into session_before_compact to truncate the history before the summarization LLM call. The config was set, the extension code existed, but it wasn't doing anything. Compaction on large sessions was guaranteed to fail.

Impact

Roughly ~1,000 lines of extension code were sitting idle in production — compaction safeguard (435 lines), context pruning (572 lines), and the path resolution glue (~100 lines). The runtime state was being set correctly, but the extensions that read that state were never loaded. All of it passed tests, shipped, and did nothing.

First fix attempt (83eb996)

Digging into the code, the issue seemed straightforward: buildEmbeddedExtensionPaths() was being called for its side effects (setting runtime state), but its return value — the actual extension file paths — was being discarded. Neither compact.ts nor run/attempt.ts were passing the paths to DefaultResourceLoader, so the session_before_compact hook never got registered.

The fix wired the return value into a DefaultResourceLoader with additionalExtensionPaths, passed it to createAgentSession, and all tests passed. Deployed, tested /compact again — same error. 248k tokens, rejected.

Root cause

resolvePiExtensionPath() computes extension file paths relative to import.meta.url:

const self = fileURLToPath(import.meta.url);
const dir = path.dirname(self);
return path.join(dir, "..", "pi-extensions", `${id}.${ext}`);

In dev (tsx), import.meta.url points to the actual .ts source file, so the relative path lands on src/agents/pi-extensions/compaction-safeguard.ts — which exists. In production, tsdown bundles everything into hashed chunks like dist/pi-embedded-Df4JcLlD.js. The path resolves to dist/pi-extensions/compaction-safeguard.js — a file that doesn't exist, because the extension code is already inlined in the bundle. The extension silently fails to load, the safeguard never fires, compaction sends the full history unguarded.

Actual fix

DefaultResourceLoader supports an extensionFactories option that accepts ExtensionFactory[] — functions, not file paths. Instead of resolving paths at runtime for dynamic import, we import the extension functions directly at build time:

import compactionSafeguardExtension from "../pi-extensions/compaction-safeguard.js";
import contextPruningExtension from "../pi-extensions/context-pruning.js";

These get bundled inline by tsdown. No file resolution, no dynamic imports, no runtime path that can break.

buildEmbeddedExtensionPaths → buildEmbeddedExtensionFactories, returns ExtensionFactory[] instead of string[]. Both callers (compact.ts, run/attempt.ts) pass extensionFactories to DefaultResourceLoader. The dead resolvePiExtensionPath() helper and its path/fileURLToPath imports are removed.

After deploying this fix, /compact works — compaction completes and the token count drops as expected.

Files changed

• src/agents/pi-embedded-runner/extensions.ts — core change: imports → factories
• src/agents/pi-embedded-runner/compact.ts — wire extensionFactories to resource loader
• src/agents/pi-embedded-runner/run/attempt.ts — same wiring for the run path

🤖 Generated with Claude Code