[dora-dotcom]

Why

Pi's package gallery (pi.dev/packages) lists any npm package with the pi-package keyword, so publishing one puts box there with no review. Our CLI doesn't write Pi configs, so this is also the one-line install for Pi users.

What

• pi/: npm package @simular-ai/box-pi. extensions/box.ts calls pi.registerMcpServer("box", …), so Pi's built-in MCP (Pi 0.99+) connects it with no extra adapter (pi-mcp-adapter picks it up too). On an older Pi without registerMcpServer it logs a warning and adds nothing. Sign-in is /mcp login box inside a session. Tools are deferred, with shell, browser_navigate, browser_snapshot, screenshot and box_status declared directly. The box skill copy uses Pi's tool names and its sign-in command.
• .github/workflows/release-pi.yml: a pi-vX.Y.Z tag on a commit on main, matching pi/package.json, publishes to npm through trusted publishing with provenance and creates a GitHub release.
• publish-cli.yml: pi/** in the path filter. The Pi step packs the package, installs it into Pi (pinned in cli/e2e/clients.json), and checks that /mcp reports box: needs sign-in.
• README: a row in the table and the tag-based release step.

Release

npm only lets you set a trusted publisher on a package that already exists, so the first version is published once by hand from pi/ (npm publish --access public, needs npm access to @simular-ai). Then set the trusted publisher (repo simular-ai/box-plugin, workflow release-pi.yml, environment npm). Every later release is a pi-v* tag.

Tested

On Pi 1.5.0 (@earendil-works/pi-coding-agent, isolated agent dir, package installed from this branch):

• pi install ./pi works and the extension loads with no errors.
• /mcp login box opened box's consent page in the browser. After Allow, /mcp showed box connected.
• Pi called mcp__box__screenshot and described what was on the box's screen (LibreOffice Calc with sales.ods open).
• CI: the Pi step above passes.

🤖 Generated with Claude Code

[dora-dotcom]

@chenchenSimular this one is ready for review too. Tested that it installs and loads on Pi 1.5.0 and registers box; I didn't run a real sign-in in Pi. After merge it needs an npm publish from pi/ under @simular-ai - your npm access, or I can add a publish workflow like publish-cli.yml if you prefer. thanks!

[chenchenSimular]

Thanks Dora. The extension API checks out against Pi's docs (registerMcpServer with url/exposure/toolExposure, the pi key and pi-package keyword, pi install npm:). Requesting changes for:

1. pi/README.md:11: drop the shell pi mcp login box. Pi's docs say "pi mcp shell commands do not load extensions and only see file-configured servers", so it won't find box. Keep only /mcp login box inside a session.
2. Untested sign-in. Pi signs in with its own client ID document (https://pi.dev/oauth/client.json) and falls back to client registration. Please complete one real sign-in and one box tool call with Pi before merge, and note the result in the PR.
3. Publishing. Manual npm publish doesn't match how the repo releases. Add a release-pi.yml on pi-v* tags (check the tag matches pi/package.json, the commit is on main, environment: npm, id-token: write, npm publish --provenance --access public), and update the README's releasing line. The first version can go out by hand, then set up trusted publishing on npm, same as the CLI.

CI: no checks ran because pi/** isn't in publish-cli.yml's path filter. Add it, plus a plugins step with npm pack ./pi --dry-run (ideally also install a pinned @earendil-works/pi-coding-agent, pi install ./pi, and check box is registered).

Non-blocking: before Pi 0.99, pi.registerMcpServer doesn't exist and the extension throws. Guard it or state the minimum Pi version. A Pi client for connect can be a follow-up (in the Rust CLI).

[dora-dotcom]

@chenchenSimular thanks for the review! All five points are in (f89f546):

1. README: only /mcp login box inside a session; the shell pi mcp login line is gone.
2. Real sign-in tested on Pi 1.5.0 (isolated config dir, package installed from this branch): /mcp login box opened box's consent page, Allow, then "take a screenshot of my box" made Pi call mcp__box__screenshot (a direct tool), and it described the box's screen correctly (LibreOffice Calc with sales.ods open). Model: Claude via subscription.
3. Publishing: .github/workflows/release-pi.yml on pi-v* tags (tag must match pi/package.json, commit must be on main, environment: npm, id-token: write, npm publish --provenance --access public), plus a Releasing section in the README. The first version goes out by hand, then trusted publishing on npm.
4. CI: pi/** in the path filter; the plugins job runs npm pack ./pi --dry-run, installs Pi 1.5.0 (pinned in cli/e2e/clients.json), runs pi install ./pi and checks over RPC that Pi reports box: needs sign-in, so box is registered and reachable without a model or key. Green.
5. Older Pi: the extension checks for pi.registerMcpServer and prints a warning instead of throwing; README states Pi 0.99+.
   Could you take another look when you have a minute? thanks!

[chenchenSimular]

Thanks, most of my earlier comments are addressed (the shell login line, release-pi.yml, the CI path filter and Pi step, and the version guard). A few things left before merge:

1. Root README.md:28 still says "then npm publish from pi/". Please point it at the new tag-based release (pi-v* tag → release-pi.yml), same as pi/README.md.
2. The PR description still says "Not yet tested: the OAuth sign-in and a tool call" and that a manual publish is needed after merge. Your later comment says you tested /mcp login box and a screenshot call on Pi 1.5.0. Please update the description so it matches what was tested and how it will be released.
3. It conflicts with main in README.md. Please rebase.

[dora-dotcom]

@chenchenSimular thanks, all three are in:

1. Root README's pi/ release line now points at the pi-v* tag and release-pi.yml, same as pi/README.md.
2. PR description rewritten: what was tested (sign-in with /mcp login box and a screenshot call on Pi 1.5.0) and how it's released (first version by hand, then tags).
3. Merged main into the branch to fix the README conflict (force push is blocked on my side; a squash merge comes out the same as a rebase).