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:

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

1. 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.
2. 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.