Support Oh My Pi (omp) as a first-class MCP client

[asuan-dev]

Context

Oh My Pi (omp) is a local-first coding agent framework (TUI + CLI). It is a full MCP client: ~/.omp/agent/mcp.json holds a standard {"mcpServers": {...}} map supporting both stdio and HTTP transports (currently running codebase-memory-mcp over stdio and donut-browser/cloudflare over HTTP in my setup).

Compartment already works with it through the generic stdio route (any MCP client), but it is missing from clients.py (compartment integrate), so there is no one-command wiring, no integrate --all coverage, and no docs.

Requests

1. Add omp to CLIENTS in src/compartment/clients.py — config paths:

   • ~/.omp/agent/mcp.json (agent-level, currently the live one)
   • ~/.omp/mcp.json (additional)
     Standard mcpServers root key, plain {"command", "args"} entries — same shape as Cursor/codex entries.

2. Document manual wiring for omp in INTEGRATIONS.md (stdio compartment serve, --vault/--caller args).

3. Optional deeper integration ideas (happy to elaborate):

   • omp has an extension system (~/.omp/agent/extensions/, npm-style packages with an on(event, handler) API subscribing to agent lifecycle events, e.g. beforeAgentStart) — a natural write-path capture hook equivalent to the Claude Code PostToolUse hook.
   • The /compartmentalize skill already uses the standard Agent Skills layout; omp loads skills from ~/.agents/skills/, so it can be installed there manually today.
   • omp ships a local SQLite memory backend (Mnemopi) with memory:// URLs — a potential import source (similar to import-claude) for migrating existing memories into the vault.

Manual config that already works

{
  "mcpServers": {
    "compartment": { "command": "compartment", "args": ["serve"] }
  }
}

Why it matters

omp users get the encrypted vault + deterministic retrieval, but currently lose the deterministic write path (no hook, model-discretion only) and have no documented integration. Adding omp to the client table is a few lines (same pattern as the existing 27 clients) and unlocks integrate omp + --all.

[asuan-dev]

Correction / stronger evidence: omp has a first-class hook subsystem

Follow-up after checking omp official docs (hooks.md, skills/authoring-hooks.md in the oh-my-pi repo): omp ships a full hook subsystem (the --hook CLI flag is now an alias for --extension; hooks load through the same extension runner and register via pi.on(event, handler)).

Key events for a memory write/read path:

• tool_result (post-execution, can override content) — fires after EVERY tool execution. A write-path capture hook here sees all tool outputs, not just host memory files — strictly broader than the Claude Code PostToolUse mirror (which only watches Claude memory notes).
• tool_call (pre-execution, can block or rewrite args) — useful for injecting a "recall before answering" gate at the tool level.
• context (fires before every LLM call, can rewrite messages) — enables deterministic memory injection without relying on model discretion, equivalent to cognee's UserPromptSubmit hook.
• session.compacting (can inject context during compaction) — keeps memory across compaction boundaries.

Hook discovery: .omp/hooks/**/*.ts capability registry (or explicit paths via config). Also worth noting omp loads skills from ~/.agents/skills (Agent Skills layout), so /compartmentalize installs there manually already.

So the integration surface for omp is not just "another MCP client" — it can support the full deterministic write path (tool_result hook → memory_store) and deterministic read path (context hook → inject memory_search results), matching or exceeding what the Claude Code integration offers. Happy to provide reference hook implementations if useful.