Implements mcpctl as an opencode addon, mirroring the prime-agent UX
(active-project indicator + a /mcpctl project switcher). opencode is a
native MCP client, so instead of a bridge this mounts the active project's
proxy MCP gateway through opencode's own live MCP API.
- src/opencode-ext/mcpctl-opencode.ts — server plugin (headless runs): mounts
the active project under a stable `mcpctl` name via `client.mcp.add`,
re-asserting on first contact and before each turn; never throws.
- src/opencode-ext/mcpctl-opencode-tui.tsx — TUI plugin: `/mcpctl`,
`/mcpctl-status`, `/mcpctl-skills`, and a `mcpctl:<project>` indicator in
the prompt footer (next to the model name, above the token counter); the
switch delegates to the CLI then re-points the mount live.
- `mcpctl config opencode` — provision/reuse the project mcptoken, install +
register the plugins (tui.json), write the 0600 state file, sync skills.
- `skills sync --agent opencode` — new shared-tree target
(~/.config/opencode/skill).
- embedded-source generator + embed test, settings/config/order tests,
completions, README + docs/opencode-extension.md.
Typechecked against the real @opencode-ai/plugin types (1.18.15).
The pi extension shipped in `src/pi-ext/` was covered by no tsconfig and no
eslint config, so nothing ever checked it against pi's API. Pointing tsc at
the published @earendil-works/pi-coding-agent types found the command surface
to be inert.
Fixes:
- `/mcpctl` did nothing. `ctx.ui.select` takes `string[]` and returns the
chosen string; it was called with `{value,label}` objects, so the menu
rendered five `[object Object]` rows and `choice === "status"` never
matched any branch. Labels are now plain strings mapped back to actions.
- The headless branch returned a status string from a handler typed
`Promise<void>`; pi drops it. Reports via notify instead.
- "Sync skills" omitted `--agent pi`, writing into ~/.claude/skills — in an
integration whose stated purpose is to not depend on ~/.claude — and said
so in its own success message. It also ran execSync with `stdio: "inherit"`,
painting raw output over pi's TUI, and interpolated the project name into a
shell string. Now execFile with `--agent pi` and captured output.
- Tool results typed `content[].type` as `string`; pi's AgentToolResult wants
the `"text"` literal.
- `callTool` asserted `Promise<unknown>` to `ToolCallResult`.
- Sanitising MCP tool names to `[a-z0-9_]` can collide (`docs.search` vs
`docs-search`). The colliding tool was silently never registered but still
reported active, so its calls were forwarded to the first tool. Names are
now disambiguated and tracked with the MCP tool they forward to.
- `registerWithPi` rewrote settings.json even when nothing changed. Since
parsing strips `//` comments, a no-op run destroyed them.
Guards, so this class of bug can't return:
- `src/pi-ext/tsconfig.json` checks the extension against the real published
pi types (dev dependency, not a shim — a shim drifting from the published
API is the exact failure being guarded). Wired into `pnpm typecheck`.
- eslint now covers `src/pi-ext/*.ts` like every other source file.
- A test fails if the embedded copy in `config/pi-extension.ts` is stale;
editing the sources without regenerating silently shipped old code.
Also: the branch added `config pi` without regenerating shell completions
(the committed-completions test was failing), and the doc advertised
`mcpctl pi sync-skills`, which does not exist. Both corrected, plus a note
on the session-token vs `mcpctl_pat_` bearer difference that would bite
against an authenticated `mcplocal serve`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017BMXdb2qZbPSh8Q7XpTyjB
