Add OMP (oh-my-pi) as a first-class agent variant of Pi

[noamsiegel]

Summary

OMP (@oh-my-pi/pi-coding-agent) is a published variant of pi-coding-agent with a different binary name (omp vs pi), config directory (~/.omp/ vs ~/.pi/), and resume flag (omp --resume <id> vs pi --session <id>). It shares pi-coding-agent's extension API (same pi.on("session_start", …) shape), so the bridge generated by cmux hooks pi install actually works against OMP — but the agent gets labelled pi in Feed → By Agent and the saved launch/resume command is wrong for restore.

This bites users who run OMP exclusively or alongside pi, because:

• Feed → By Agent groups OMP sessions under Pi alongside genuine pi sessions, making it impossible to tell them apart.
• ~/.cmuxterm/pi-hook-sessions.json saves launchCommand.executablePath: "pi" for OMP sessions, so app relaunch will try pi --session <id> and fail (no pi on PATH, or worse, finds a different pi install).

Repro

1. Install OMP globally: bun add -g @oh-my-pi/pi-coding-agent (provides omp binary; no pi symlink).
2. cmux hooks pi install — cmux generates ~/.omp/agent/extensions/cmux-session.ts (it auto-detects the OMP install path, good).
3. Start an OMP session in a cmux pane: omp (or omp --resume <id>).
4. Inspect ~/.cmuxterm/pi-hook-sessions.json:

   "019e6f6c-921d-7000-8aa1-8cdc9285738f" : {
     "launchCommand" : {
       "executablePath" : "pi",
       "launcher" : "pi",
       "source" : "environment",
       "environment" : { "PI_CODING_AGENT_DIR" : "/Users/noam.siegel/.omp/agent" }
     },
     "runtimeStatus" : "idle"
   }

   Note executablePath: "pi" even though the actual process is bun … omp. cmux is identifying via PI_CODING_AGENT_DIR env and assuming the binary name.
5. In Feed → By Agent, the entry appears under Pi, mixed with real pi sessions.
6. Quit and relaunch cmux: session restore runs pi --session <id>, which fails because the user only has omp.

Proposed fix

Add omp as a recognised agent in cmux hooks setup, parallel to (but distinct from) pi. From the existing docs/agent-hooks.md integration matrix, OMP would look like:

Agent	Binary checked	Installed file	Session restore	Feed bridge
OMP	omp	~/.omp/agent/extensions/cmux-session.ts	omp --resume <id>	none

Concrete changes (INFERENCE — I haven't read cmux's Swift source; pointer to TerminalStartupEnvironment.swift is from DeepWiki §6.4):

1. Agent registry — add omp alongside pi, amp, rovodev, etc., in the cmux hooks agent list.
2. Binary detection — sniff omp on PATH (in addition to pi); when both exist, prefer the one matching the live process's executable.
3. Process-tree identification — when a session_start hook fires, look at the actual process executable (/proc/<pid>/exe equivalent / argv[0] of the bun wrapper) instead of inferring from PI_CODING_AGENT_DIR. The current code path mislabels OMP as pi because both set the same env var.
4. Bridge template — cmux hooks omp install writes the same cmux-session.ts content as pi (the extension API is byte-identical) but with cmux hooks omp <event> calls in place of cmux hooks pi <event>, so events are tagged --source omp.
5. Resume command — omp --resume <id>, not pi --session <id>. OMP also accepts omp --session <id> for forward-compat AFAICT, but --resume is the documented flag.
6. Sessions file — ~/.cmuxterm/omp-hook-sessions.json separate from pi-hook-sessions.json.
7. Env override — CMUX_OMP_HOOKS_DISABLED=1 (matches the existing CMUX_PI_HOOKS_DISABLED=1 pattern).
8. Config dir override — OMP_AGENT_DIR (mirroring PI_CODING_AGENT_DIR).

Why this lives in cmux, not OMP or pi-coding-agent

• The agent registry, binary sniffer, hook generator, and Feed grouping all live in cmux. OMP can't register itself without cmux acknowledging its existence first.
• pi-coding-agent has no opinion on cmux. The extension API is generic.
• OMP already ships cmux-aware extensions for the pieces it can control independently (cmux-tab-title.js, cmux-workspace-reaper.js), but the agent-registry side is cmux-only territory.

Verification

After the fix, the same repro produces:

// ~/.cmuxterm/omp-hook-sessions.json
"019e6f6c-921d-7000-8aa1-8cdc9285738f" : {
  "launchCommand" : {
    "executablePath" : "omp",
    "launcher" : "omp",
    …
  }
}

And Feed → By Agent shows separate OMP and Pi buckets.

Environment

• cmux 1.3.2-HEAD-+ff6e126 (Ghostty 1.3.2-HEAD)
• @oh-my-pi/pi-coding-agent@15.5.10
• macOS 25.4.0 (Darwin) arm64
• bun --version 1.2.x (binary at ~/.local/share/bun/bin/omp)

Happy to test a fix or write the integration if you'd like a PR.

[ender1214]

will this be picked up anytime soon?

[ErebusBat]

Just a note that as written, this will not work for everyone. OMP also supports a --profile flag (and $OMP_PROFILE) In order to segment profiles, If implemented without that support you have the real possibility of connecting to the wrong profile when resuming.

[noamsiegel]

Just a note that as written, this will not work for everyone. OMP also supports a --profile flag (and $OMP_PROFILE) In order to segment profiles, If implemented without that support you have the real possibility of connecting to the wrong profile when resuming.

Good catch, hopefully the maintainers pick this up. Or if easier, I can make a PR but I'm trying not to put any more PR code reviews on their plate.