feat(hook): add pi support

[gitbluf]

Summary

• Add Pi coding agent support via a thin TypeScript extension that delegates rewrites to rtk rewrite
• Wire Pi into rtk init for install/uninstall, global and local scopes, plus Pi-specific docs
• Add Pi tests and supporting hook/init plumbing

Test plan

• cargo fmt --all && cargo clippy --all-targets && cargo test
• Manual testing: rtk output inspected

Issue #401

I also saw PR #750 is open, but it seems abandoned.

[CLAassistant]

All committers have signed the CLA.

[gitbluf]

@aeppling Any thoughts on this?
If any change is needed to make this mergeable, do let me know.
Thanks in advance!

[zicochaos]

I tested Pi 0.74.0 locally with an RTK extension using the current @earendil-works/pi-coding-agent API.

Smoke results:

• Pi loads rtk.ts under Extensions.
• ls hooks/pi through Pi matches rtk ls hooks/pi, not raw ls hooks/pi.
• ls -la hooks/pi also returns compact RTK output.
• git status --short, git log --oneline -3, git diff --stat, and gh pr list --limit 3 all worked.
• Pi appears to render/log the original requested command, so verification should be based on RTK-shaped output or rtk gain --history.

Two suggestions:

• Prefer rtk init --agent pi as the primary CLI surface, matching Cursor/Kilo/Antigravity.
• Consider also covering Pi user_bash for context-visible !cmd, while skipping !!cmd.

[gitbluf]

I tested Pi 0.74.0 locally with an RTK extension using the current @earendil-works/pi-coding-agent API.

Smoke results:

• Pi loads rtk.ts under Extensions.
• ls hooks/pi through Pi matches rtk ls hooks/pi, not raw ls hooks/pi.
• ls -la hooks/pi also returns compact RTK output.
• git status --short, git log --oneline -3, git diff --stat, and gh pr list --limit 3 all worked.
• Pi appears to render/log the original requested command, so verification should be based on RTK-shaped output or rtk gain --history.

Two suggestions:

• Prefer rtk init --agent pi as the primary CLI surface, matching Cursor/Kilo/Antigravity.
• Consider also covering Pi user_bash for context-visible !cmd, while skipping !!cmd.

Hi @zicochaos , thanks for taking the time.

Would you prefer me to completely remove the rtk init --pi cli surface and just leave --agent one?

I was thinking about covering !cmd but decided against it as it might be useful if the user want's to give the full context of the command output (user can still prefix his commands with rtk) without having to copy paste the output of the command either from another session or !!cmd.

[borrougagnou]

hope this one will really be merged 🙏

[borrougagnou]

@gitbluf @jeanduplessis

[gitbluf]

@aeppling @jeanduplessis Any chance to get this one reviewed and merged?

[jeanduplessis]

Sorry mate, I'm not a maintainer on this repo. Just a curious bystander hoping this gets merged so I can stop using workarounds.

[gitbluf]

@pszymkowiak Seems quite some people would like to see this one added, any chance to review it?

[fboudra]

@gitbluf just curious as a rtk and pi user, there's already a bunch of rtk extensions available. I've been using myself https://github.com/MasuRii/pi-rtk-optimizer for example. What's the benefit to make this integration in rtk vs a pi extension? thanks.

[gitbluf]

@gitbluf just curious as a rtk and pi user, there's already a bunch of rtk extensions available. I've been using myself https://github.com/MasuRii/pi-rtk-optimizer for example. What's the benefit to make this integration in rtk vs a pi extension? thanks.

Hi, probably best to see #401

[pszymkowiak]

Thanks @gitbluf — tested the install/uninstall lifecycle and the rtk rewrite exit-code delegation, both solid. The thin-delegate extension is clean. A few things to fix before merge:

1. --dry-run is not honoured (blocking)

• rtk init --uninstall --agent pi --dry-run actually deletes the extension file — the if pi block in uninstall() never reads dry_run, it calls fs::remove_file unconditionally. A --dry-run that mutates the filesystem breaks the flag's contract ("Preview changes without writing any files").
• rtk init --agent pi --dry-run still creates .pi/extensions/ on disk — run_pi_mode discards dry_run (let InitContext { verbose: _, .. }) so fs::create_dir_all runs unguarded. (write_if_changed correctly skips the file itself.)

Please guard both directory creation and file removal behind dry_run, and emit print_dry_run_footer() on the Pi paths. The existing agent integrations in this same file already do this correctly — take a look at the cursor and codex blocks in uninstall(), and at run_hermes_mode_at / uninstall_hermes_at for the install/uninstall dry-run pattern. Aligning with those keeps Pi consistent with the rest of the codebase.

2. Add dry-run tests
The 9 Pi tests don't cover --dry-run; a dry_run install + uninstall test asserting nothing is written/removed would have caught the above.

3. semgrep filesystem-deletion (CI)
The scan flags fs::remove_file(&plugin_path). The Hermes uninstall a few lines down already handles this with // nosemgrep: filesystem-deletion -- … — please apply the same acknowledgement comment for consistency. (Rule over-broadness tracked in #1954.)

Nit: the ; removed from show_config(codex)? looks like an unrelated cosmetic change — worth reverting to keep the diff focused.

Ping me once dry-run is fixed.

[gitbluf]

@pszymkowiak Thanks for the review, I've just pushed the new commit addressing your comments.

[borrougagnou]

@gitbluf conflicts

[gitbluf]

@gitbluf conflicts

Resolved.

[borrougagnou]

OOOOOH !!!! 🚀 🚀 🚀

[aeppling]

Hey @gitbluf

Thanks for this PR :) I've looked into PI agent as well as your code, here are some questions so we can implement this the best way possible.

Blocking question: Cross-agent permission leakage (the extension imposes Claude's config on Pi)

How permissions flow today: hooks/pi/rtk.ts shells to rtk rewrite, which calls permissions::check_command() → load_permission_rules(). That loader reads deny/ask/allow only from Claude Code settings and returns a verdict via exit code (2=deny, 3=ask/default, 0=allow+rewrite, 1=no-rewrite).

The extension then maps exit 2 → { block: true }.

Why this is wrong for Pi: Pi has no native permission model; its settings schema has no permissions/approval/allow/deny/sandbox option; gating only exists if an extension adds it apparenlty.

So we apparently have two options here :

• make this extension rewrite only
• take as permissions references a PI agent permissions extensions to correctly manage those

I could be wrong, never used PI Agent before, but it seems that for permissions it should be handled by extensions like https://github.com/MasuRii/pi-permission-system ?

Happy to discuss about this and what should this PI extension responsible for. RTK should be as transparent as possible and reflect the CLI/agent native behavior on exit codes and permissions

PI provide some tools to build permissions flows and ask user, but this can be delegated to various extensions.

Note : i'm aware the permission leak issue is a current design issue in RTK and should be fixed, however we should not propagate this more.

Once we have a proper solution for this i'll complete the review so we can merge this asap

[aeppling]

PR look clean and already had a review so this should be resolvable quickly for a release :)

[gitbluf]

@aeppling Thanks for the review.

You assumption is correct for the Pi agent that the handling of permissions should be handled by another extension(could be the one you shared).

I would say that the main goals of this extensions should be to handle rewrites and stay as lean as possible as to not intervene with (or break) other extensions -- best effort.

[aeppling]

Thanks for the reply, agreed on the direction

Here are some things to be addressed to match our approach

Concrete change set for hooks/pi/rtk.ts:

Remove the deny path (exit 2 → { block: true }) and the false/moot "Pi has no per-tool confirmation UI" line.
And anything related that could interfere

lean/robust practices

PR #2022 add some interesting point for robust integration, these could serve the "stay lean / don't interfere"
You may want to check against this PR if anything to be taken.

eg: Consider replacing the hand-rolled spawn+timeout+settle with pi.exec: it returns { stdout, stderr, code, killed } without throwing on non-zero exit, so you keep stdout for every exit code (including exit 3's rewrite)

Standardize with codebase

• Extract uninstall_pi(). Pi uninstall is inlined in the uninstall() dispatcher (init.rs:652–686). Match uninstall_codex / uninstall_hermes (and your own run_pi_mode), move it to its own helper.
• No hardcoded paths. pi_plugin_path_for_scope() hardcodes ".pi"; add a PI_LOCAL_DIR constant alongside the other PI_* constants.
• Use pi.exec instead of hand-rolling spawn, no other integration hand-rolls process management.

Docs adjustement

• Remove the broken inexsiting link docs/specs/pi-hook-integration.md link
• State our design intent explicitly in hooks/pi/README.md: rewrite-only token optimizer; permission gating is intentionally out of scope, defer to a dedicated permission extension.

PI Agent extensions compatibility

Since there are others extensions like the permissions one i shared, we should ensure RTK does not bypass any extensions.
If you have any extensions running with your PI agent did you test this compatibility and behavior ?

[aeppling]

If anything i'm open to discuss here

[borrougagnou]

@aeppling
Then you're saying it's better to merge PR#2022 instead of this one... a PR opened just yesterday...
It's nice to hear that what's been done here is pointless if it doesn't suit your tastes or your AI tool taste...

That's really not nice of you...
mostly after saying it will be "resolvable quickly for a release" ...

PR look clean and already had a review so this should be resolvable quickly for a release :)

4 peoples here are reviewed the code...
including 2 peoples who contribute a lot to the repository...

And now you're asking to "lean/robust practices" at a PR opened yesterday... really ?

[gitbluf]

@aeppling I'm using it with couple of other extensions atm, and current implementation doesn't colide with them.

Currently afk, but I'll address your suggestions a bit later today, and ping you when it's done for the review.

So just keep an eye out on the notification 🙂

Thanks

[aeppling]

@gitbluf thanks !

@borrougagnou I get the eagerness to ship this, and that's exactly why I want it consistent with the codebase and other integrations before it lands. This is the PR I'm moving forward with.

Neither PR was mergeable exactly as-is, I started the review here, and the author is aware of original issue, Pi context, and the other PR.

Thanks for the reviews and the patience.

[gitbluf]

@aeppling Should be done now.

[aeppling]

Hey @gitbluf

All look good to me,
Thanks for contributing to RTK and addressing all reviews !

Will be released in RTK 0.42