[YuchenWell]

List PinK as an independently maintained Agent plugin, installed from magpie-plugin-pink@0.1.1. Source: https://github.com/YuchenWell/magpie-plugin-pink (MIT).

The plugin adds PinK to Magpie's native Agents page. A bundled Bun worker synchronizes model selection and the model catalog into PinK's Custom Endpoint configuration, including Profile inheritance. Requests through Magpie are attributed to PinK in Usage. While Magpie is running, disconnecting, disabling or removing the plugin restores managed configuration while preserving manual edits. The worker exits when its host is gone; an active host can take over after a transient CLI host exits. Offline CLI changes are applied on the next host startup, and offline disable/removal requires the documented restore command first.

This change adds only the registry entry, with the display name PinK, an icon and English/Chinese summaries. The package is maintained in its own repository. Requires Magpie 0.1.2136 or later.

Validation:

• Registry JSON parses; the entry is unique and existing entries are unchanged.
• Type checking and 29 unit tests pass in the plugin repository.
• The npm package is checked with unmodified Magpie 0.1.2183 in an isolated HOME: installation from npm, native connect/model switch/disconnect, disable/re-enable/remove, configuration restoration, host exit, restart and deferred offline operations, and gateway usage attribution with a mock upstream.
• Real PinK chat remains unverified because PinK sign-in was required. History import and per-session billing are outside this version's scope.

[yetone]

Thanks for this. PinK on the Agents page is welcome, and the package does its job well. I reviewed it at 78185d2 and am holding the merge for one problem.

What I checked

• I downloaded magpie-plugin-pink@0.1.0 from npm, and its sha512 matches the registry's integrity. I read dist/index.mjs, dist/worker.mjs, dist/cli.mjs and dist/pink.agent.mjs, plus the jsonc-parser 3.3.1 bundled inside them. There is no network call, no install script and no encoded code. It only writes to ~/.config/magpie-pink and to PinK's User/chatLanguageModels.json and settings.json. Both are MIT licensed. The registry icon is the same 150x150 PNG as the package's magpie.icon.
• On a Mac, with a sandbox HOME, a mock PinK User folder and the network refused, I called default.server the way magpie's plugin host does and wrote control.json from connect():
  • Connecting adds a Magpie (PinK) group. The JSONC comments are kept and chat.defaultModel is set.
  • Switching to another model updates the default.
  • Disconnecting gives back both files byte for byte.
  • After a manual edit to settings.json, disconnecting keeps the edit and puts back the user's own chat.defaultModel.
  • Turning the plugin off in plugins.json stops the worker within about a second.

The problem: the worker outlives magpie

start() spawns dist/worker.mjs detached and unref'd. The worker's loop leaves only when the plugin is turned off or removed, when launch.json changes generation, or when pluginEnabled throws and the parent is gone:

if (enabled === false) break;
if (enabled === void 0 && !processAlive(next.parentPid)) break;

So while the plugin is on and magpie quits, the worker keeps running. It re-reads plugins.json, launch.json, worker.json and control.json every 500 ms until the user logs out. In my run the host exited and the worker was reparented to launchd. It was still alive 5 s later (PPID 1) and stopped only when I turned the plugin off. For a user this is a stray bun process that nobody asked for, and it does nothing useful while the gateway is down.

The fix looks small. ensureWorker already starts the worker again when the host comes back, and launch.json carries the new parentPid. So the worker can exit whenever next.parentPid is gone, whatever enabled is:

if (enabled === false || !processAlive(next.parentPid)) break;

I tried that one line in my run. The worker was gone 5 s after the host exited, and connect, switch and disconnect all behaved as before. Please publish that as 0.1.1, along with a test that the worker exits once its host's pid is gone while the plugin is on. Then update this PR, or just comment, and I'll run it again and merge.

A minor note, not blocking: the README's install steps say to download a release tgz and use magpie plugin add /path. Once this is listed, Discover installs it from npm. You may want to say that first.

[YuchenWell]

Fixed the issue raised in this review and published magpie-plugin-pink@0.1.1. The fix commit and GitHub release are available for review.

1. Worker lifecycle: when its host is gone, the worker completes one final reconciliation and exits. A generation handoff starts a replacement only if the new host is still alive. A surviving host also refreshes parentPid before restarting the worker, preventing a transient CLI host from leaving a stale PID that causes repeated restarts.
2. README: npm installation now comes first, with separate instructions for the search box and the manual installation field. The 0.1.1 package includes the updated README.

Validation: type checking and all 29 unit tests pass. The lifecycle regression check keeps the plugin enabled, terminates its last host, and requires both lease cleanup and worker process exit within five seconds. It also covers two-host takeover, absence of a restart loop, generation handoff, offline restore, and normal disconnect restoration. I installed 0.1.1 from npm and tested it with official Magpie 0.1.2183 under an isolated HOME: connection, model switching, shutdown/restart reconciliation, disable/re-enable/removal, and gateway usage attribution with a mock upstream.

One behavior boundary is now explicit: without a persistent host, a standalone magpie pink command does not necessarily load the plugin. The old version relied on its persistent worker for those operations. In 0.1.1, automatic synchronization requires the Magpie desktop app or gateway service to be running with the plugin loaded. Offline CLI model selection or disconnection is reconciled when the plugin next loads; before disabling or uninstalling offline, run restore first. This is documented and tested separately from operations performed while Magpie is running. Real PinK chat remains unverified.

The registry entry uses an unpinned package name, so no registry.json change is needed for this release. The PR description now references 0.1.1 for retesting.

[yetone]

Thanks, YuchenWell. 0.1.1 fixes the worker lifecycle, and I'm merging the entry.

What I checked

• The package. I downloaded magpie-plugin-pink@0.1.1 from registry.npmjs.org into an empty folder. Its sha512 matches the registry's dist.integrity (sha512-7orjsdh1…Iyng==). Next to 0.1.0, cli.mjs and pink.agent.mjs are byte for byte the same. package.json changes only its version and how the keywords are laid out, and there is still no install script. Two files change:

  • worker.mjs: the loop now exits once next.parentPid is gone, whatever enabled is. A generation hand-off starts a new worker only while the new host is alive.
  • index.mjs: ensureWorker rewrites launch.json, with the live host's pid, before it starts a worker.

  Neither change adds a network call, a new path or encoded code. The README puts npm first, as suggested.

• The registry entry. Your entry names the package without a version, so magpie installs the newest one and the entry doesn't need to change for 0.1.1. The icon URL still serves the same PNG I checked last time (same SHA-1). On current main (848497c) the entry is unique, and the other 61 are unchanged.

• The lifecycle, run again. I used the same harness as last time (macOS, sandbox HOME, a mock PinK User folder, network refused) and called default.server the way magpie's plugin host does:

  • Connect, switch to another model, disconnect (both files given back byte for byte), and a manual edit kept on disconnect all behave as in 0.1.0.
  • When the host exits with the plugin still on, the worker is gone within 1 s. On 0.1.0 it was still alive 5 s later, reparented to launchd.
  • A second host start spawns a fresh worker, and that worker exits with its host too.
  • With the host still up, turning the plugin off stops the worker within 3 s.
  • Two hosts: a long-lived host A, then a short-lived host B that exits after 2 s. A worker was alive under A for the whole run after B left. Once A exited no worker was left, and pgrep found no stray worker.mjs.

• The repo suite on a local merge of 78185d2 into main 848497c: HOME=$(mktemp -d) bun test gives 3808 pass, 8 skip, 0 fail. In bun scripts/check.mjs the only ✗ is cloudflare-workers-ai, the known #519 when there is no network.

Not tried: real PinK chat (as you say, it needs a PinK sign-in), and a run inside a real magpie app rather than a harness that calls default.server.