You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pi generated extension should default-export its factory function #1550
Running any Pi command with extensions enabled then failed:
pi doctor
with:
Error: Failed to load extension "/Users/musichen/.pi/agent/extensions/cbmem.ts": Extension does not export a valid factory function: /Users/musichen/.pi/agent/extensions/cbmem.ts
Hint: Start without extensions using "pi -ne".
Local fix verified
Changing the generated export to a default factory fixed Pi startup:
-export function register(pi) {+export default function (pi) {
After this change, both commands worked with extensions enabled:
Confirmed, and thank you @musichen — this is our bug, introduced when the Pi extension started being generated from the tool registry (#1392, shipped in v0.10.0). src/cli/client_adapter.c emits export function register(pi), and Pi wants a default-exported factory.
What makes it worse than a cbm-only failure: a broken extension file makes every Pi command fail to load, not just ours — pi doctor included, exactly as you saw. So this is queued for the next patch release.
Immediate unblock if you need Pi working right now: delete ~/.pi/agent/extensions/cbmem.ts (cbm keeps working through its MCP server registration; only the extension surface goes away), or edit it to export default function (pi) { ... } with the same body.
Your PR #1553 and @henri-edh's #1564 both arrived while ours was already in CI, so the commits are ours, but both of you are recorded as co-authors on 42e320a6 — and @henri-edh's description of the loader (jiti.import(path, { default: true }) rejecting a non-function, hence the module namespace object a named-only export hands back) replaced our vaguer comment, because it explains why a named export cannot simply be added alongside.
Thank you for reporting it and fixing it within the hour, and for the workaround you posted for anyone who needed Pi working before the release.
This fix is in it. Please give it a try when you get a chance: if it behaves in your setup, feel free to close this out, and if anything still looks off, say so and we'll pick it straight back up. Thank you again for the report.
Closing as fixed in v0.10.3 by commit 42e320a6. The generated Pi extension now default-exports the factory expected by Pi's loader, with the community fixes credited as co-authored work.
Thank you again @musichen for the exact loader failure, verified workaround, and prompt PR. If Pi still rejects a freshly generated extension on v0.10.3 or newer, comment here and we will reopen it.
Activity
DeusData commentedon Aug 11, 2026
Confirmed, and thank you @musichen — this is our bug, introduced when the Pi extension started being generated from the tool registry (#1392, shipped in v0.10.0).
src/cli/client_adapter.cemitsexport function register(pi), and Pi wants a default-exported factory.What makes it worse than a cbm-only failure: a broken extension file makes every Pi command fail to load, not just ours —
pi doctorincluded, exactly as you saw. So this is queued for the next patch release.Immediate unblock if you need Pi working right now: delete
~/.pi/agent/extensions/cbmem.ts(cbm keeps working through its MCP server registration; only the extension surface goes away), or edit it toexport default function (pi) { ... }with the same body.fix(cli): stop breaking commands people already type (#1544, #1550)
musichen commentedon Aug 12, 2026
A test-backed fix is available in #1553.
fix(cli): stop breaking commands people already type (#1544, #1550)
docs(pi): name the loader mechanism behind the default-export require…
DeusData commentedon Aug 12, 2026
@musichen — shipping in v0.10.3 (releasing now).
Your PR #1553 and @henri-edh's #1564 both arrived while ours was already in CI, so the commits are ours, but both of you are recorded as co-authors on
42e320a6— and @henri-edh's description of the loader (jiti.import(path, { default: true })rejecting a non-function, hence the module namespace object a named-only export hands back) replaced our vaguer comment, because it explains why a named export cannot simply be added alongside.Thank you for reporting it and fixing it within the hour, and for the workaround you posted for anyone who needed Pi working before the release.
DeusData commentedon Aug 13, 2026
v0.10.3 is published — https://github.com/DeusData/codebase-memory-mcp/releases/tag/v0.10.3 (GitHub archives, npm, and PyPI are all serving it).
This fix is in it. Please give it a try when you get a chance: if it behaves in your setup, feel free to close this out, and if anything still looks off, say so and we'll pick it straight back up. Thank you again for the report.
DeusData commentedon Aug 13, 2026
Closing as fixed in v0.10.3 by commit
42e320a6. The generated Pi extension now default-exports the factory expected by Pi's loader, with the community fixes credited as co-authored work.Thank you again @musichen for the exact loader failure, verified workaround, and prompt PR. If Pi still rejects a freshly generated extension on v0.10.3 or newer, comment here and we will reopen it.