Feature: Add pi coding agent to auto-detect installer
Summary
pi (by @badlogic / Mario Zechner, @earendil-works/pi-coding-agent on npm) is a minimal terminal coding harness with a TypeScript extension API. It's not in CBM's auto-detect installer list (currently 9 agents: Claude Code, Codex, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, Kiro).
This issue proposes adding pi as a 10th supported surface, with a reference community extension ready to link from the installer.
Why pi is a good fit
- Extension API is mature: lifecycle hooks (
session_start, tool_execution_end, user_bash), registerTool() for LLM-callable tools, TypeBox schemas. Same shape as the other supported agents.
- Growing ecosystem: pi packages distributed via npm
pi-package keyword. Active community (Discord, npm).
- Gap is real: every pi user who wants CBM currently has nothing. The
install command silently skips pi.
Reference implementation
I built and use a community extension: @vforvaick/pi-codebase-memory-mcp (publishing as 0.1.0-beta).
- Wraps the
cli mode (one-shot, matches CBM's documented non-daemon path).
- Registers all 9 public tools + hidden-working ones (
list_projects, index_status, detect_changes, get_graph_schema) as first-class cbm_* pi tools. check_index_coverage stays CLI-only since v0.9.0 returns "unknown tool" via MCP - see Capability drift below.
- Adds a pi-side freshness gate (see finding below - the native watcher doesn't fire in CLI/MCP-stdio mode, so source edits leave the graph stale until manual reindex).
Repo: github.com/vforvaick/pi-codebase-memory-mcp (link live once published)
Findings during build (relevant to CBM maintainers)
1. Native watcher is inert in CLI / MCP-stdio mode
Reproduction (isolated CBM_CACHE_DIR, v0.9.0):
1. Spawn `codebase-memory-mcp` bare (MCP stdio).
2. `initialize` handshake OK.
3. `index_repository` a small fixture repo.
4. Edit a file in the working tree (NO git commit).
5. Poll `search_graph` for the new symbol for 30s.
Result: never detected. The daemon worker log (${CBM_CACHE_DIR}/logs/.worker-<pid>.log) stays 0 bytes - the watcher process logs watcher.start interval_ms=multi-sec at startup but never fires a reindex, regardless of auto_watch=true.
This happens in BOTH:
cli mode (one-shot, expected - documented as not joining daemon)
- bare/stdio MCP mode (unexpected - this is the daemon-backed path that
auto_watch is designed for)
Impact: any agent using cli mode (which is the only sane option for tools that auto-inject project from cwd) gets a stale graph after the first edit. The pi extension works around this with lifecycle hooks (tool_execution_end marks dirty, ensureFresh() reindexes before read queries). But the native watcher is the right place to fix this - agent-side workarounds can't catch external-editor mutations.
Expected: uncommitted working-tree edits (add/rename/edit/delete) reflected in the graph within the watcher's documented interval, in stdio MCP mode.
2. Capability drift: tools/list vs callable vs CLI
On v0.9.0:
| Tool |
tools/list advertises |
Direct tools/call works |
cli works |
index_repository |
yes |
yes |
yes |
search_graph |
yes |
yes |
yes |
query_graph |
yes |
yes |
yes |
trace_path |
yes |
yes |
yes |
get_code_snippet |
yes |
yes |
yes |
get_graph_schema |
yes |
yes |
yes |
get_architecture |
yes |
yes |
yes |
search_code |
yes |
yes |
yes |
list_projects |
no |
yes (hidden) |
yes |
index_status |
no |
yes (hidden) |
yes |
detect_changes |
no |
yes (hidden) |
yes |
check_index_coverage |
no |
no (unknown tool) |
yes |
So 3 tools work but aren't advertised (clients doing capability-negotiation against tools/list will miss them), and 1 tool is CLI-only. The pi extension falls back to CLI for check_index_coverage.
Expected: tools/list matches the callable surface; check_index_coverage reachable via MCP.
What I'm asking
- Primary: add pi to the auto-detect installer. Happy to link the community package as the reference, or hand it off if you'd prefer an officially-owned integration.
- Secondary (separate concerns, can split into own issues if you prefer):
- Watcher not firing in stdio MCP mode (repro above).
tools/list / check_index_coverage capability parity.
If you'd like the pi extension code as a starting point for an official integration, I'm glad to transfer the repo/npm package. Not trying to fork the community - just filling the gap until/unless there's an official path.
Environment
- codebase-memory-mcp v0.9.0 (Darwin arm64)
- pi
@earendil-works/pi-coding-agent 0.84.0
- macOS 15, Apple M3
Happy to provide the full spike script (isolated CBM_CACHE_DIR, reproducible end-to-end) if useful.
Feature: Add pi coding agent to auto-detect installer
Summary
pi(by @badlogic / Mario Zechner,@earendil-works/pi-coding-agenton npm) is a minimal terminal coding harness with a TypeScript extension API. It's not in CBM's auto-detect installer list (currently 9 agents: Claude Code, Codex, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, Kiro).This issue proposes adding pi as a 10th supported surface, with a reference community extension ready to link from the installer.
Why pi is a good fit
session_start,tool_execution_end,user_bash),registerTool()for LLM-callable tools, TypeBox schemas. Same shape as the other supported agents.pi-packagekeyword. Active community (Discord, npm).installcommand silently skips pi.Reference implementation
I built and use a community extension:
@vforvaick/pi-codebase-memory-mcp(publishing as 0.1.0-beta).climode (one-shot, matches CBM's documented non-daemon path).list_projects,index_status,detect_changes,get_graph_schema) as first-classcbm_*pi tools.check_index_coveragestays CLI-only since v0.9.0 returns "unknown tool" via MCP - see Capability drift below.Repo: github.com/vforvaick/pi-codebase-memory-mcp (link live once published)
Findings during build (relevant to CBM maintainers)
1. Native watcher is inert in CLI / MCP-stdio mode
Reproduction (isolated
CBM_CACHE_DIR, v0.9.0):Result: never detected. The daemon worker log (
${CBM_CACHE_DIR}/logs/.worker-<pid>.log) stays 0 bytes - the watcher process logswatcher.start interval_ms=multi-secat startup but never fires a reindex, regardless ofauto_watch=true.This happens in BOTH:
climode (one-shot, expected - documented as not joining daemon)auto_watchis designed for)Impact: any agent using
climode (which is the only sane option for tools that auto-inject project from cwd) gets a stale graph after the first edit. The pi extension works around this with lifecycle hooks (tool_execution_endmarks dirty,ensureFresh()reindexes before read queries). But the native watcher is the right place to fix this - agent-side workarounds can't catch external-editor mutations.Expected: uncommitted working-tree edits (add/rename/edit/delete) reflected in the graph within the watcher's documented interval, in stdio MCP mode.
2. Capability drift:
tools/listvs callable vs CLIOn v0.9.0:
tools/listadvertisestools/callworkscliworksindex_repositorysearch_graphquery_graphtrace_pathget_code_snippetget_graph_schemaget_architecturesearch_codelist_projectsindex_statusdetect_changescheck_index_coverageSo 3 tools work but aren't advertised (clients doing capability-negotiation against
tools/listwill miss them), and 1 tool is CLI-only. The pi extension falls back to CLI forcheck_index_coverage.Expected:
tools/listmatches the callable surface;check_index_coveragereachable via MCP.What I'm asking
tools/list/check_index_coveragecapability parity.If you'd like the pi extension code as a starting point for an official integration, I'm glad to transfer the repo/npm package. Not trying to fork the community - just filling the gap until/unless there's an official path.
Environment
@earendil-works/pi-coding-agent0.84.0Happy to provide the full spike script (isolated
CBM_CACHE_DIR, reproducible end-to-end) if useful.