Repository navigation
Add OMP (oh-my-pi) as first-class TuiAgent - #2662
Merged
Merged
Conversation
Contributor
|
Awesome. |
Contributor
Author
|
Sweet, thanks. I love oh my pi so i wanted to add support! Tested this locally seems to work fine! |
|
Yes please! |
Contributor
Author
|
Fixed the main conflicts |
Contributor
|
I'll fix the remaining ones here now and try to get this in |
- Add OMP (oh-my-pi) as first-class TuiAgent
Adds 'omp' alongside 'pi' across the canonical agent registries, UI
catalog, settings keyword lists, and notification labels. OMP uses
argv prompt injection (no --prefill flag needed) and shares the
PI_CODING_AGENT_DIR env var and extension API with Pi, so the
per-PTY overlay machinery is reused.
The Pi titlebar overlay default-dir detection now falls back to
~/.omp/agent when ~/.pi/agent is absent, so users with only OMP
installed get the status-extension overlay automatically. An
explicit PI_CODING_AGENT_DIR env var still wins.
README badge row gets an OMP entry (with omp.sh favicon) between
Pi and Hermes in the main README and all four localized READMEs.
- Make Pi/OMP overlay source dir per-agent
Fixes a silent extension-shadowing bug in the original OMP commit.
The previous getDefaultPiAgentDir() chose its source dir by existsSync
order — always preferring ~/.pi/agent when present and falling back to
~/.omp/agent. That meant a user with both installed would always get
Pi's user extensions loaded into OMP, never OMP's own.
In Orca the agent is picked per launch (TUI_AGENT_CONFIG.launchCmd),
so the overlay source dir must also be picked per launch. This change
parameterizes PiTitlebarExtensionService and the relay's overlay
manager with a PiAgentKind ('pi' | 'omp'), threaded through the
spawn path:
detectPiAgentKindFromCommand(command)
→ BuildPtyHostEnvOptions.launchCommand
→ buildPtyEnv(id, existingDir, kind)
→ getDefaultPiAgentDir(kind)
The relay's pty.spawn RPC gains a command field (hint only — the
relay shell still receives the actual command via pty.data writes)
so SSH overlays resolve correctly per agent.
An explicit PI_CODING_AGENT_DIR / ORCA_PI_SOURCE_AGENT_DIR env still
wins. Bare-shell PTYs default to 'pi' to match pre-fix behavior.
New tests cover the three required cases: Pi+both → mirrors ~/.pi/agent,
OMP+both → mirrors ~/.omp/agent, OMP+only-Pi → empty overlay (no
cross-pollination).
- Address PR stablyai#2662 review: OMP draft launches, kind-threading tests, doc nits
Four review-driven fixes on top of the per-agent overlay commit:
1. OMP draft launches now work. Setting draftPromptEnvVar to
ORCA_PI_PREFILL on OMP's TUI_AGENT_CONFIG entry lets
buildAgentDraftLaunchPlan return a valid plan for OMP (previously
returned null). OMP already inherits Pi's orca-prefill.ts extension
through the shared overlay and reads PI_CODING_AGENT_DIR
identically, so no new code or env var is needed.
2. Integration tests now cover OMP kind threading. spawnAndGetEnv
and daemonSpawnAndGetEnv accept an optional command parameter,
and two new assertions verify piBuildPtyEnvMock is called with
'omp' as the third arg at both the local and daemon spawn paths.
Prevents silent regressions if a future refactor drops the
command field at any of the three call sites.
3. Documented the relay revive path's intentional command-absence.
SerializedPtyEntry doesn't carry command, so cold-restart revived
OMP PTYs fall back to the Pi-default overlay. Acceptable
pre-OMP behavior, but the implication wasn't documented.
4. Rephrased two error-fallback comments in titlebar-extension-service
from Pi-only to agent-neutral (Pi or OMP), and updated one
test description that still said 'Pi dir' after the per-agent
rewrite.
- Isolate OMP from Pi: per-kind overlay tree, shadow vars, prefill env
Per user directive 'OMP is its own program with paths and stuff, make
sure we don't use anything PI related'. OMP launches now own a fully
separate overlay tree and namespace of Orca-owned env vars; the only
shared name is the PI_CODING_AGENT_DIR binary var, which OMP's own
runtime mandates (the upstream CHANGELOG documents the deliberate
OMP_CODING_AGENT_DIR -> PI_CODING_AGENT_DIR rename in
packages/ai/CHANGELOG.md and the dirs.ts read site).
What changed:
- Overlay parent dir: pi-agent-overlays for Pi, omp-agent-overlays for OMP.
PiTitlebarExtensionService.{buildPtyEnv,clearPty,getOverlayRoot,getOverlayDir}
now route through OVERLAY_ROOT_DIR_NAME[kind]. clearPty sweeps both
roots because PTY teardown does not carry the launch command.
- Per-kind prefill env var: ORCA_PI_PREFILL stays for Pi (back-compat with
in-flight PTYs at upgrade), OMP gets ORCA_OMP_PREFILL. The bundled
orca-prefill.ts source is parameterized by kind and reads the matching
var. tui-agent-config OMP entry now uses draftPromptEnvVar=ORCA_OMP_PREFILL.
- Per-kind PTY shadow vars: pty.ts emits ORCA_OMP_CODING_AGENT_DIR +
ORCA_OMP_SOURCE_AGENT_DIR for OMP launches; ORCA_PI_* for Pi launches.
Source-dir resolution reads either kind's source shadow so nested PTYs
preserve the original root across kinds without leaking the var name.
- Shell-ready wrappers (zsh daemon + local, bash, PowerShell OSC133,
Windows shell args): restore PI_CODING_AGENT_DIR from EITHER ORCA_PI_*
OR ORCA_OMP_* (a PTY only has one set, so OR-restore is safe).
pty-subprocess and local-pty-provider trigger the wrapper for either
shadow.
- Relay mirror: per-kind overlay subdir (.orca-relay/{pi,omp}-overlays/),
materializePi uses per-kind root, clearOverlay sweeps both. relay.ts
emits the kind-appropriate shadow. plugin-overlay-env reads OMP source
shadow first.
- Headless commit-message agent env: agentId='omp' resolves to
PI_CODING_AGENT_DIR via ORCA_OMP_SOURCE_AGENT_DIR.
Tests:
- titlebar-extension-service.test asserts OMP launches land in
omp-agent-overlays AND that pi-agent-overlays is untouched.
- plugin-overlay.test asserts each kind's overlay lives in the expected
subtree and clearOverlay drops both.
- pty.test asserts OMP launches emit ORCA_OMP_* shadow vars and the
matching Pi-named ones are absent (cross-leak regression guard).
- tui-agent-startup test asserts the OMP draft plan uses ORCA_OMP_PREFILL.
- shell-ready / pty-subprocess / windows-shell-args / OSC133 tests
assert the OMP restore line is present alongside the Pi one.
Constraint kept (cannot remove): PI_CODING_AGENT_DIR. OMP's own binary
reads this var by design (CONFIG_DIR_NAME stays '.omp' but the env var
the binary reads is PI_CODING_AGENT_DIR — verified against the upstream
source at C:\tmp\pr-workspace\oh-my-pi).
- Merge branch 'main' into add-omp-agent
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Adds OMP as a new coding agent you can pick in Orca, right next to Pi.
OMP is a fork of Pi — same idea, different program. So Orca now shows OMP in the agent picker, settings search, notifications, and the README badge row.
Why it's its own thing
OMP and Pi look similar but they're separate programs:
ompvspi)~/.omp/agentvs~/.pi/agent)So Orca treats them as two different agents. They never share files, folders, or environment variables. Launching OMP doesn't touch any Pi state, and vice versa.
Where each agent's stuff lives
pi-agent-overlays/omp-agent-overlays/~/.pi/agent~/.omp/agentORCA_PI_PREFILLORCA_OMP_PREFILLORCA_PI_*ORCA_OMP_*There's exactly one name they share:
PI_CODING_AGENT_DIR. That's not Orca's choice — OMP's own program reads that variable to find its config folder (the OMP authors renamed it fromOMP_CODING_AGENT_DIRtoPI_CODING_AGENT_DIRon purpose). Orca just sets it to the right value for whichever agent is running.What changed (by area)
The shared list of agents — added OMP to the union types, agent kind enum, telemetry, notifications, settings search, and the renderer's agent catalog.
Per-agent isolation — the code that builds overlay folders and environment variables now takes an "agent kind" parameter (
'pi'or'omp') and routes to the right folder + variable names. Shell wrappers (zsh, bash, PowerShell) accept either agent's env var and restore the right one.Relay (for SSH) — same isolation on the remote side: each agent gets its own overlay subfolder under
.orca-relay/, and the relay emits the rightORCA_*variables based on which agent was launched.Tests — every change has a paired test asserting OMP launches don't leave Pi files behind, and Pi launches don't leave OMP files behind.
READMEs — OMP badge added between Pi and Hermes in the main README and the four localized ones.
How I checked it works
pnpm run tc(typecheck, all 3 projects): cleanpnpm run lint: cleanORCA_PI_*vars, and vice versaWhat's out of scope
PI_CODING_AGENT_DIRstays shared. It has to — OMP's own runtime reads that exact name. Adding a parallelOMP_CODING_AGENT_DIRwould do nothing because nothing reads it.