[gradyzhuo]

Depends on AIToolKit 0.0.1-dev.10, which this branch now pins. The 661 tests were built from what the pin resolves to, not from the local checkout the code was written against.

The first time a plugin owns something instead of answering questions about directories orrery prepared. orrery-claude holds the pool: where accounts live, what is in them, and which one is pinned.

orrery hands over a root and stops there

Each plugin is spawned with $ORRERY_HOME/plugins/<id> in its environment, and everything beneath it is the plugin's to arrange.

The root comes from the host because a plugin must never derive a home — that seam is what keeps an isolated run out of the developer's real config. The host stops at the root because one that knew the layout would be back to owning the pool and asking the plugin to look things up in it.

The layout itself is inherited unchanged: a directory per account id holding metadata.json. A layout that moves for no reason is a migration nobody asked for. What changed is who may know it.

Two behaviours carried over deliberately

Both are about not making a whole command useless:

• An account whose metadata cannot be read is skipped with a warning to stderr, not thrown. A listing is worth having with one row missing; refusing to list anything would take away the command someone needs in order to notice and fix it.
• A pin naming an account that no longer exists reads as nothing pinned. The account is gone; reporting that as a failure asks every caller to handle a state it cannot fix.

Cheap listing, fresh detail

list() reads files only and leaves the credential store alone. current() is a detail view and spends one spawn on it, because an in-session /login lands there before anywhere else.

The host now asks one question and gets whole accounts back — it no longer fetches identities separately and stitches them onto rows.

Host side

RemoteAccounts is all five methods or none. A plugin that could list accounts but not delete one would leave a pool that can be filled and never emptied, and finding that out at the first delete is worse than the capability being absent.

Unlike a listing of identities, an undecodable account is not skipped: a short listing looks complete, and orrery would go on offering a pool quietly missing rows.

AIToolKit.Account is spelled out at every use, because OrreryCore still has an Account — the one carrying tool, displayName and workspace. Two types with one name is a transition state, not a design; the host's copy goes when the Tool enum does. One existing test needed the same qualification.

orrery list now asks the plugin

The branch deciding where accounts come from lives in AccountListing and nowhere else. Writing if this tool has a plugin into each command that lists or shows accounts would spread a transition across fourteen files and then require finding all fourteen again to remove it.

The fork is temporary in a specific way: codex and gemini are not being migrated into the plugin model, they are being replaced by it — codex gets reimplemented against the framework, gemini is dropped for now and returns as a plugin. Nobody has to maintain this bridge.

No fallback, and that is the point. A plugin-owned tool with an empty pool lists nothing, even when orrery's own records still hold accounts for it. A fallback would make the plugin unobservable — orrery-claude could be deleted and every path would keep working exactly as before, which is indistinguishable from never having asked it. Verified the test catches it: adding if !rows.isEmpty { return rows }, which reads entirely reasonable, fails the case immediately.

An error from the plugin propagates rather than degrading to an empty list. It owns the accounts, so "I cannot say" and "there are none" are different answers, and rendering the first as the second tells someone their accounts are gone.

Rows are flattened on the way out: the plugin path returns accounts already carrying email and plan, while the pool path fetches identity separately. A caller that could see the difference would have to care about it.

Still on the store

add, remove and use are unchanged. orrery use turned out not to set a global current at all — it pins an account into a workspace (env.setAccount(acct.id, for: tool)), so the real pin is (workspace, tool) → account. AIToolAccounts.setCurrent(id:) has no workspace dimension and cannot express it. That shape is an open design question, not something to guess at here.

add, remove and pin go through the plugin

The mapping turned out cleaner than expected, because orrery already keeps the two facts apart:

orrery already had	reaches
_pin-current — what the shell function's use) case calls; a global current, deliberately independent of workspaces	account.makeCurrent()
orrery pin --workspace — binds an account to one	account.pin(to:)

Neither command needed its meaning changed, only its destination.

UseCommand is untouched: orrery-bin use --claude already throws, because claude's selection is handled by the orrery() shell function, which calls _pin-current. Routing a command that refuses to run for claude would have been theatre.

orrery add says out loud that it cannot log in for a plugin-owned tool. AccountLoginFlow works on orrery's own Account — staging dirs, a Keychain item name — and none of that exists for an account the plugin owns. Moving credentials across the boundary is its own piece of work; printing nothing would leave someone holding an account that looks finished and cannot be used.

Four commands became async, which pulled await through their test call sites. No test changed what it asserts.

Checked on a real installation, not only in tests

Built for Linux x86_64 with the release toolchain and installed in a clean OrbStack machine, because what matters here is where bytes land — which unit tests cannot show:

Where accounts landed	orrery's pool 0, plugin store 2
Where the workspace landed	the account's own metadata: {"id":…,"name":"work","workspace":"client-x"}
An unpinned account	no workspace key — "not pinned" is genuinely absent, not a default
current	the plugin's own file, holding an id
A second process	reads what the first wrote
Does claude still reach workspace.json?	no — origin's workspace.json has no accounts key
remove	plugin store 2 → 1
codex	still orrery's pool (1), plugin store 0

The last row is the point: claude and codex coexist in one orrery list, one asked and one read, and the output does not betray which. The transition fork works rather than half-working.

Verification

14 tests through the shipped binary, not an in-process conformer — including that a pin survives the process that recorded it. Full suite 667 green. No nonisolated(unsafe), @unchecked Sendable or @preconcurrency.

A trap worth recording

Found while writing the registration test. PluginDiscovery.locate searches an env var, then $ORRERY_HOME/tools, then PATH — so a test supplying only PATH exercises whatever is installed on the machine.

Here that was a plugin from weeks earlier advertising tool/describe alone, so the capability under test was simply absent and the failure pointed somewhere else entirely. The suite now pins the binary by env var.

The other plugin suites drive the transport directly and never reach locate, which is why none of them had ever caught it.

🤖 Generated with Claude Code