Feature request: Pi (oh-my-pi / pi-mono) and OMP runtime support

[ckumar1]

Thanks for shipping this — the integration is clean and well-scoped. Wanted to flag a runtime gap and offer to help close it.

Use case

We're standing up multi-runtime crew on Gas Town (gastownhall), which dispatches per-rig agents across multiple LLM runtimes per workspace. Today's lineup includes Claude Code, Codex CLI, OpenCode, Oh My Pi (OMP), and Pi (badlogic/pi-mono). The first three are supported by moshi-hooks today; the latter two aren't.

The OMP/Pi crew are exactly the kind of long-running agent work that benefits most from Live Activity push (a cross-model generalist agent that runs unattended for hours and surfaces a permission prompt or finished task). Right now those notifications go nowhere.

What OMP/Pi look like

OMP and Pi share a hook-extension architecture (TypeScript exports a function, runtime fires events), with this approximate event set today:

pi.on("session_start",       async (event, ctx) => { ... })   // ≈ SessionStart
pi.on("before_agent_start",  async (event, ctx) => { ... })   // ≈ UserPromptSubmit
pi.on("session_compact",     async (event, ctx) => { ... })   // (no Claude equivalent; reload context)
pi.on("tool_call",           async (event, ctx) => { ... })   // ≈ PreToolUse — supports `return { block: true }` to deny
pi.on("session_shutdown",    async (event, ctx) => { ... })   // ≈ Stop

tool_call carries event.toolName and event.input (matching Claude's PreToolUse shape closely). The Pi/OMP host runs on Bun-style JS, so the same bunx moshi-hooks invocation works — the adapter just needs to recognize a new --source value and the Pi/OMP-specific event names.

(There's no exact tool_finished / post_tool event in the public OMP API I've found — would be worth confirming with the upstream OMP author if Live Activity wants both pre/post coverage.)

What the change might look like

1. Extend the source type union: "claude" | "codex" | "opencode" | "pi" | "omp" (or merge to a single "pi" since OMP is a Pi fork).
2. Add a setup command: moshi-hooks setup --pi (or --omp) that emits a hook-extension snippet at <workspace>/.pi/extensions/moshi-hooks.js or <workspace>/.omp/hooks/moshi-hooks.ts. Gas Town crew would then merge that snippet into their existing gastown-hook.ts (one workspace can host multiple gastown-side hook concerns).
3. Map OMP/Pi event names to your existing eventType vocabulary: tool_call → pre_tool, session_shutdown → stop, etc.
4. Optionally — and this is the bigger ask — a generic stdin-based mode (moshi-hooks emit --eventType ... --message ... reading from any source) so future runtimes can wire in via shell without touching the package.

I'd be happy to put up a PR if any of this lines up with where you want to take it. Reference for what the OMP integration looks like today: gastown OMP hook template.

Why this matters server-side

The local index.ts defaults unknown sources to "claude" (line 588), which works around the local enum. But the API likely tags events by source for the Live Activity grouping and per-source UI affordances on the iOS side. A Pi/OMP event masquerading as Claude probably mis-renders on the phone. So the full fix needs both client-side --source pi support and server-side acceptance of the new value.

(Happy to test an alpha, file follow-up issues for OMP-specific edge cases, or contribute a PR.)

[adstastic]

Hi folks, I have a similar use case so I built a Pi extension:

https://github.com/adstastic/pi-moshi

It talks to the current moshi-hook daemon over the existing Unix socket.

As @ckumar1 suggests, could you please add native Pi support by:

1. accepting source: "pi" in the Moshi API
2. rendering Pi as its own source in the clients
3. optionally adding moshi-hook install --target pi to write a Pi extension into ~/.pi/agent/extensions/moshi.ts

That installer target could use this event mapping:

• session_start -> session_started
• agent_start -> session_started
• tool_execution_start -> tool_running
• tool_execution_end -> tool_finished
• agent_end -> task_complete
• session_shutdown -> session.closed (except reload)

Future approvals could use Pi's tool_call hook, since it can return { block: true }.

Current findings:

• works today with source: "opencode"
• same envelope with source: "pi" reaches daemon, then publish fails with 422 Unprocessable Entity

Thanks!