feat(omp): add extension-based rewrite integration for Oh My Pi

[makoMakoGo]

Summary

Adds Oh My Pi (OMP) as a first-class RTK CLI integration via a TypeScript extension that intercepts tool_call events for the bash tool and delegates command rewrite decisions to rtk rewrite.

• New init flag: rtk init --omp / rtk init -g --omp
• Installs ./.omp/extensions/rtk.ts for project scope or ~/.omp/agent/extensions/rtk.ts for global scope
• Keeps rewrite logic in the Rust registry; the OMP extension is a thin runtime adapter
• Supports --show, --uninstall, --dry-run, project-scoped install, and global install
• Refuses to overwrite pre-existing non-stock OMP extension files

Closes #591.

Review cleanup

This version was rebased onto current develop to keep the PR focused on OMP only:

• Removed the previous docs noise and broad wording changes
• Kept Hermes and existing agent documentation intact
• Switched OMP from --agent omp to --omp because OMP is a CLI/runtime integration, closer to OpenCode/Gemini/Codex than IDE rules-file integrations

Test plan

• cargo fmt --all -- --check
• cargo clippy --all-targets
• cargo test
• bun --eval 'await import("./hooks/omp/rtk.ts")'
• cargo run -- init --help
• cargo run -- init --omp --dry-run
• cargo run -- init --omp --show

[CLAassistant]

All committers have signed the CLA.

[makoMakoGo]

I have used this pr for about 2 days on my omp.

[makoMakoGo]

@aeppling @KuSh @FlorianBruniaux this is now rebased onto current master, the PR description matches the current fail-closed OMP behavior, and the targeted checks were rerun:

• cargo test test_omp
• cargo test test_validate_init_target_selection
• cargo test test_npx_unknown_tool_passthrough
• bun --eval await import("./hooks/omp/rtk.ts")

This PR has been open since 2026-04-17. Could one of you review it when you have time? Thanks.

[makoMakoGo]

@pszymkowiak also pinging you here since you merge/review a lot of RTK work and this touches init/hook integration paths.

[tsubus]

this looks like a vibe coded mess, isn't this other one looking much better? https://github.com/beeemT/rtk/pull/2

[makoMakoGo]

this looks like a vibe coded mess, isn't this other one looking much better? beeemT#2

PR #2 is prompt-only, while OMP supports a cleaner command-rewrite path via tool_call. My personal opinion is that using event.input.command before the native BashTool runs, so RTK keeps transparent behavior without overriding the bash tool or relying on the model to remember rtk.

PR #2 describes Capability A(which I mentioned above), but the actual patch does not implement it; it ends up as Capability B (prompt-injection) only.

[KuSh]

Hi @makoMakoGo, thanks for your PR.

There's a lot of documentation changes that feels like nitpicks around terms (extensions/hooks/...). That seems uneeded and unwanted. Could you try to stay closer to what we already have?

Also OMP do have pre hooks, why not just use that? Why did you choose to use an extension?

[makoMakoGo]

Thanks for the review, @KuSh.

On the docs: Agreed — I'll strip the broad terminology changes and keep the diff to OMP-specific additions
only. The hook/plugin/extension wording updates aren't needed for this integration.

On extension vs pre hook: The goal is the same as a pre-execution rewrite: intercept the bash tool call before it runs and replace the command with the rtk rewrite result.

I chose the extension path because it's the actively maintained surface for tool interception in current OMP. Specifically:

• --hook is treated as an alias for an extension path in current OMP
• Extension modules are auto-discovered from .omp/extensions/ and ~/.omp/agent/extensions/
• OMP's authoring docs recommend ExtensionAPI for new integrations
• The hook subsystem's tool_call event can only block/allow — it cannot mutate tool input in-place, which is needed for command rewriting. In other words, the legacy hook result contract is block/allow-oriented and does not expose an explicit updated-input return shape for command rewriting.

This also aligns with RTK's existing transparent-rewrite integrations (OpenCode plugin, OpenClaw plugin) rather than the rules-file approach or hooks.

That said — if you'd prefer a pre-hook implementation, or would rather wait for another contributor's take, I'm happy to adjust or close. Just let me know which direction you'd prefer. 🤗

[KuSh]

On extension vs pre hook: The goal is the same as a pre-execution rewrite: intercept the bash tool call before it runs and replace the command with the rtk rewrite result.

I chose the extension path because it's the actively maintained surface for tool interception in current OMP. Specifically:

* `--hook` is treated as an alias for an extension path in current OMP

* Extension modules are auto-discovered from .omp/extensions/ and ~/.omp/agent/extensions/

* OMP's authoring docs recommend ExtensionAPI for new integrations

* The hook subsystem's tool_call event can only block/allow — it cannot mutate tool input in-place, which is needed for command rewriting. In other words, the legacy hook result contract is block/allow-oriented and does not expose an explicit updated-input return shape for command rewriting.

This also aligns with RTK's existing transparent-rewrite integrations (OpenCode plugin, OpenClaw plugin) rather than the rules-file approach or hooks.

That said — if you'd prefer a pre-hook implementation, or would rather wait for another contributor's take, I'm happy to adjust or close. Just let me know which direction you'd prefer. 🤗

No, I was just questioning the choice since, after a quick review of the OMP repo, I didn't find anything that prioritizes extensions over hooks. But after your explanation and a closer review of the documentation, extensions seem like the right choice.

So rebase, handle conflicts, and reduce documentation noise—the principles remain the same even if OMP chooses different wording.

[rtk-release-bot]

Automatic message from CI checks : It seems like this branch is targeting the wrong branch, any contribution should target develop branch.

See CONTRIBUTING.md for details.

[makoMakoGo]

@KuSh updated.

Changed:

• Kept docs to OMP-additive entries only; no broad terminology changes
• Aligned OMP extension with RTK's fail-open convention used by Hermes/OpenCode etc: missing rtk or rewrite
  failures leave the original command unchanged

Verified:

• cargo fmt --all -- --check ✓
• cargo clippy --all-targets ✓
• cargo test ✓
• bun --eval 'await import("./hooks/omp/rtk.ts")' ✓
• Local OMP simulation: tool_call rewrites supported bash commands through rtk
• Manual fail-open check: hid the rtk binary; command passed through unchanged, no block

Ready for re-review when you have time.

[KuSh]

nitpick, why not just skip registering the tool_call hook if RTK isn't available?
How could we alert the user about that?

[makoMakoGo]

Got it. I moved the RTK availability check to extension setup: when rtk is missing, the extension now registers only a session_start warning via OMP's UI and skips the
tool_call handler; when rtk is available, it registers the rewrite hook as before.

[makoMakoGo]

I initially tried ctx.ui.notify(..., "warning"), but session_start notifications did not appear reliably during OMP startup, likely because the initial chat container is rebuilt afterward.

So I chose the persistent hook status line instead, as shown in the screenshots below.

[makoMakoGo]

I tried to align this with the OpenCode plugin behavior: when rtk is missing, don't register the tool hook and surface a warning.

For OMP, it's a little werid.

 mode.init()
    -> UI start
    -> initHooksAndCustomTools()
    -> emit session_start
    -> extension: ctx.ui.notify(...)
    -> showWarning -->chatContainer

  main.ts 
    -> mode.renderInitialMessages()
    -> chatContainer.clear()
    -> warning clear (not show)

As a result, I cant see any warning expected.

[KuSh]

Does persistent hook status works flawlessly? It seems enough. I'm not sure to understand your latest message.

[KuSh]

Ideally this should go into uninstall_init_dispatch as user could want to uninstall multiple things in one go

[KuSh]

@makoMakoGo in the meantime Pi support has been merged. Could you rebase your work on what has been done here. Perhaps some mutualization could be used.

[makoMakoGo]

@makoMakoGo in the meantime Pi support has been merged. Could you rebase your work on what has been done here. Perhaps some mutualization could be used.

Thanks for the heads-up. I’ll take a look at the merged Pi support and coordinate with @thedavemarshall on the best path forward. 🫡

[makoMakoGo]

@KuSh

I rebased this on top of the merged Pi support (#1741) and tested the OMP path locally.

I confirmed that OMP v15.2.4 can load the merged Pi extension unchanged when the file is installed under OMP's native extension directories (.omp/extensions/rtk.ts or ~/.omp/agent/extensions/rtk.ts). The core runtime mechanism is the same: handle tool_call, narrow to bash, call rtk rewrite, and mutate event.input.command.

OMP provides legacy-pi-compat: it uniformly remaps the scopes of historical Pi internal packages — @mariozechner/, @earendil-works/, and @oh-my-pi/* — to OMP's own bundled @oh-my-pi/*.

Given that, I think this PR should not maintain a separate OMP runtime extension. 🤔 I'll update it to reuse the merged Pi extension implementation and keep only the OMP-specific install/init paths, docs, and tests.

The intended final shape is:

• no separate OMP rewrite logic
• install the Pi-compatible RTK extension into .omp/extensions/rtk.ts / ~/.omp/agent/extensions/rtk.ts
• keep OMP-specific rtk init --omp, uninstall/show behavior, and coverage for those paths

Any other suggestions on the intended shape before I push the update ? I'm happy to do that.

[makoMakoGo]

wait

I tested pure reuse of the merged Pi extension under OMP, including the missing-rtk path.

The normal rewrite mechanism is compatible and should stay aligned with Pi: listen to tool_call, handle only bash, delegate to rtk rewrite, and mutate event.input.command.

related to #1365 (comment)

However, reusing the Pi extension file unchanged has a bad OMP startup UX when rtk is missing from PATH.
In OMP, pi.exec("rtk", ["--version"]) fails during extension loading, and the error is not visibly surfaced in the UI. I also confirmed that ctx.ui.notify(...) during session_start is cleared by OMP's initial render, while ctx.ui.setStatus(...) remains visible.

I want do something like this:

to do this, I need to use the ctx.ui.notify(...) approach. But it did not work reliably because the notification was emitted during startup and then disappeared when OMP rendered/cleared the initial chat container.

but I can only do this to alert the user about that:

the persistent status worked in my manual OMP testing and stayed visible after startup.

[KuSh]

Any other suggestions on the intended shape before I push the update ? I'm happy to do that.

Try to keep the spirit of the pi extension, even for install/uninstall, follow what have been documented. Rebase and resolve conflicts. If the pi extension doesn't work as is, we can duplicate it, but asking OMP maintainer about that usage which seems legit to me, could be a better option. Keep up the good work!

[makoMakoGo]

Opened the issue for that notify bug, and it's fixed in oh-my-pi. Will move on, need some time though.

[Crandel]

any news for this PR?

[alvins82]

Yes also looking for this @makoMakoGo @thedavemarshall

[alvins82]

PR reply draft (comment on #1365, voice: alvins82)

@makoMakoGo @KuSh — I picked this up and reworked it against current develop (29f9bb7). Everything below is verifiable on the branch; details of the OMP discovery findings are in the PR description.

Shape

Your 05-23 message ("the intended final shape is: no separate OMP rewrite logic; install the Pi-compatible RTK extension into .omp/extensions/rtk.ts / ~/.omp/agent/extensions/rtk.ts; keep OMP-specific init/uninstall/show behavior, docs, and tests") is now exactly the state of the PR:

• The hooks/omp/ directory is gone. There is no OMP-specific runtime code anywhere.
• rtk init --agent omp installs the same hooks/pi/rtk.ts that Pi gets (local: <project>/.omp/extensions/rtk.ts; -g: ~/.omp/agent/extensions/rtk.ts). OMP loads it unchanged through its legacy-pi-compat layer (import remap of @earendil-works/pi-coding-agent to the bundled @oh-my-pi/pi-coding-agent).
• OMP-specific surface is Rust-side only: the --agent omp target, install/uninstall/--show wiring, additive docs, tests.

Your 05-23 "wait" finding is addressed

The missing-rtk startup UX you hit — silent failure of pi.exec("rtk", ["--version"]) during extension load, ctx.ui.notify wiped by OMP's initial render — is fixed inside the shared file, so both runtimes carry it. Four small guarded additions to hooks/pi/rtk.ts, everything else byte-identical to the merged Pi extension:

1. Header note that the file is shared with OMP.
2. On a failed version probe, the extension registers a persistent ctx.ui.setStatus("rtk", "RTK disabled: …") on session_start (in addition to the existing console.warn). This is the exact primitive from your second screenshot — verified persistent in OMP 18.0.4. It is wrapped in optional-chaining + try/catch, so on Pi the callback never fires and the code is inert.
3. Guarded setLabel("RTK") — OMP surfaces extension labels in its session UI; Pi has no such method, so it's a no-op there.
4. The session_start-based alert means OMP users see why rewrites are off (missing binary vs. too old), instead of the silent startup path you described.

ctx.ui.notify is deliberately not used: in the 18.0.4 sources (current release) the notify toast is still cleared on the initial render, so the code doesn't depend on that upstream fix at all.

Your 05-14 questions

Docs: agreed — the rework is strictly additive. One row per agent table, one OMP section in supported-agents.md (between Pi and OpenClaw), one row in the install-modes table. No terminology rewrites; +25 lines in that file total.

Extensions vs. pre-hooks: with mutualization this question resolves itself — OMP has no new surface to maintain at all. The OMP compat layer executes the Pi extension natively (tool_call → bash-only → rtk rewrite → mutate event.input.command), identical behavior to Pi, and --hook being an alias for an extension path in current OMP (per your 05-14 reply) means the extension is the pre-hook mechanism there.

05-22 review items — all five

1. hooks/omp/rtk.ts:57 default-branch simplification — file is gone; the simplification lives on in the shared extension (default: skip).
2. hooks/omp/rtk.ts:51 skip-when-unmodified — same: rtk rewrite no-op (empty stdout or unchanged command) → skip.
3. hooks/omp/rtk.ts:80 "skip registering tool_call if RTK isn't available, how to alert?" — the availability check happens at load; when the probe fails the tool_call handler does nothing and the user gets the persistent session status + console warning (the session_start-alert approach you suggested, generalized to work on Pi too).
4. init.rs:1808 split condition — gone: omp_extension_path_for_scope(global) computes the full path (local .omp/extensions/rtk.ts, global ~/.omp/agent/extensions/rtk.ts).
5. init.rs:1824 write_if_changed — the OMP install path uses it: write_if_changed(path, PI_PLUGIN, "OMP extension", ctx), same as the Pi path.

OMP 18.0.4 discovery findings (corrected, source-verified)

I went through the OMP 18.0.4 sources (can1357/oh-my-pi, tag v18.0.4) and ran a full discovery matrix against the real binary, because a couple of our earlier readings of OMP's loading model were wrong. The facts that matter for this design:

• Both .omp/extensions/ (project) and ~/.omp/agent/extensions/ (user) are auto-discovered and executed, unconditionally, per session. Your original local path was correct. v15.2.4 has the identical structure (builtin.ts:444), so the 05-23 local test holds for both versions.
• There is no enable/trust gate in the extension load chain; per-file import errors are silently swallowed. This is why the missing-rtk alert matters — a broken extension file would otherwise fail silently.
• OMP 18.0.4 ships no built-in rtk extension (full binary fingerprint grep; the only rtk strings are a third-party crate copyright notice) — nothing to conflict with or shadow.

Verification

• cargo fmt --all -- --check, cargo clippy --all-targets: clean.
• Full suite: 2645 lib tests (2637 passed / 8 ignored / 0 failed) + 8 integration suites, 0 failed. 9 new OMP unit tests + 3 in main.rs.
• Extension harness (Pi-shaped fake API): 5/5 scenarios — normal rewrite, no-op passthrough, rtk missing, rtk too old, non-bash passthrough.
• Dry runs of all four OMP install/uninstall paths (outputs in the PR description), including the real-world 3-way uninstall bail on a pre-existing global install.
• Live OMP 18.0.4: extension executes through the compat layer (explicit -e); user-scope file auto-discovered and probed every session; project-scope .omp/extensions/rtk.ts auto-loaded and executed with no flags, no config, no prompt (marker binary fired). Full model-run e2e: a real omp -p session (qwen3.8-27b) shows the bash call as rtk git status in the session JSONL after the extension rewrite, and the session completed.

Two design questions for you, @KuSh

1. Uninstall asymmetry. OMP uninstall is 3-way safe (missing → no-op; exact stock match → remove; modified RTK content → refuse with "remove the file manually"), while --agent pi is unconditional. OMP's file lives in a user-global dir, so I made it conservative there. Should we make Pi 3-way too, or keep the asymmetry?
2. Guarded additions to the shared file. The four guarded deltas are inert on Pi and exist for OMP. I'd keep one shared file (the whole point of 05-23) rather than forking a Pi-pristine variant — but your call, since it touches the file a merged PR owns.

Where it stands

Rebased onto develop 29f9bb7 (current head at time of writing). 8 files, +551/−17. I've opened a new PR (#3707) from my fork with this shape — a fresh branch rather than a force-push onto yours, so you're welcome to close #1365 or take over either one. You're credited as co-author on both commits.

[makoMakoGo]

@alvins82 Thanks! I'm currently busy working toward my Ph.D. I'm glad you can continue supporting OMP RTK support and let me know. I'll close the PR. Best of luck!