Adds `mcpctl config opencode`, two opencode plugins and an `opencode` skills
sync target, so an mcpctl project can be switched from inside opencode's TUI
and the active one is visible at a glance.
Unlike `config claude` / `config prime-agent`, this writes NO MCP entry into
the host's config. opencode exposes an HTTP API for its own MCP registry
(`POST /mcp`), so the project is mounted through the running app:
- the token stays in ~/.mcpctl/opencode-state.json (0600) instead of a
mode-0644 opencode.json users paste into bug reports;
- switching projects takes effect on the next turn, with no restart.
Inside opencode:
/mcpctl filterable project picker; switches live
/mcpctl-status active project, mount state, gateway URL
/mcpctl-skills re-sync this project's skills
plus a `mcpctl:<project>` indicator in the prompt footer, next to the model
name and one line above the token counter.
Design notes:
- the MCP server is registered under a constant name, so tools keep a stable
`mcpctl_*` prefix and opencode's per-request tool resolution shows the new
project's tools by itself — no "your old tool names are dead" message to
the model, unlike the pi extension;
- an unchanged mount is never re-registered: mcp.add rebuilds the connection
and mcplocal binds a gated project's unlocked state to that connection's
mcp-session-id, so re-adding would re-lock a project begin_session had just
opened;
- the server plugin does not mount during setup — setup runs before the
server accepts connections and mcp.add calls back into it, which hangs
opencode on a blank screen before the TUI draws;
- the switcher shells out to this CLI (--skip-plugin --skip-marker) so token
minting, state and skills stay in one place;
- no usable credential aborts non-zero with the state file untouched, so a
failed switch leaves the previous project working rather than swapping it
for a mount that 401s.
`skills sync --agent opencode` installs into ~/.config/opencode/skill (XDG
aware) with the same shared-tree semantics as pi and prime-agent. The
credential plumbing shared with `config prime-agent` is lifted to one place and
parameterised by agent rather than copied.
The plugin sources are embedded in the CLI (generated, freshness-tested) so an
installed binary with no source tree can provision them, and are typechecked
against the real @opencode-ai/plugin types.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BVwuCjuMoA13gmzYEfcrNP
63 lines
2.6 KiB
JavaScript
63 lines
2.6 KiB
JavaScript
#!/usr/bin/env node
|
|
/**
|
|
* Generates `src/cli/src/config/opencode-extension.ts`, which embeds the two
|
|
* opencode plugin sources as string constants — mirroring how the pi extension
|
|
* (`pi-extension.ts`) and prime-agent's `/mcpctl` switcher
|
|
* (`prime-agent-extension.ts`) are embedded.
|
|
*
|
|
* Embedding matters: `mcpctl config opencode` must work from an installed
|
|
* binary that has no access to the source tree. The installed plugin files are
|
|
* this exact embedded source, so what the CLI ships is always what opencode
|
|
* runs.
|
|
*
|
|
* Regenerate after editing the plugin sources:
|
|
* npx tsx scripts/generate-opencode-extension.ts
|
|
*/
|
|
import { readFileSync, writeFileSync, mkdirSync } from 'node:fs';
|
|
import { dirname, join } from 'node:path';
|
|
|
|
const scriptsDir = import.meta.dirname;
|
|
const root = join(scriptsDir, '..');
|
|
const extDir = join(root, 'src', 'opencode-ext');
|
|
|
|
const SERVER = readFileSync(join(extDir, 'mcpctl-opencode.ts'), 'utf-8');
|
|
const TUI = readFileSync(join(extDir, 'mcpctl-opencode-tui.tsx'), 'utf-8');
|
|
|
|
function embed(src) {
|
|
// JSON.stringify yields a quoted string literal we can inline directly.
|
|
return JSON.stringify(src);
|
|
}
|
|
|
|
const out = `/**
|
|
* Embedded source of the mcpctl opencode plugins — DO NOT EDIT BY HAND.
|
|
* Generated by \`npx tsx scripts/generate-opencode-extension.ts\` from
|
|
* \`src/opencode-ext/mcpctl-opencode.ts\` and
|
|
* \`src/opencode-ext/mcpctl-opencode-tui.tsx\`.
|
|
*
|
|
* \`mcpctl config opencode\` writes these verbatim into ~/.config/opencode/
|
|
* (and registers them), so an installed binary with no source tree can still
|
|
* provision a working opencode integration.
|
|
*
|
|
* The install file names differ from the source file names on purpose:
|
|
* - the server plugin lands in opencode's auto-discovered \`plugin/\` dir,
|
|
* where its basename is what shows up in \`opencode plugin list\`;
|
|
* - the TUI plugin lands beside it in \`mcpctl/\`, referenced by path from
|
|
* \`tui.json\`, and must keep a \`.tsx\` extension for opencode to transpile
|
|
* its JSX.
|
|
*/
|
|
|
|
/** Install name of the server plugin, relative to ~/.config/opencode/plugin/. */
|
|
export const OPENCODE_SERVER_PLUGIN_FILENAME = 'mcpctl.ts';
|
|
|
|
/** Install name of the TUI plugin, relative to ~/.config/opencode/mcpctl/. */
|
|
export const OPENCODE_TUI_PLUGIN_FILENAME = 'mcpctl-tui.tsx';
|
|
|
|
export const OPENCODE_SERVER_PLUGIN_SOURCE: string = ${embed(SERVER)};
|
|
|
|
export const OPENCODE_TUI_PLUGIN_SOURCE: string = ${embed(TUI)};
|
|
`;
|
|
|
|
mkdirSync(dirname(join(root, 'src', 'cli', 'src', 'config')), { recursive: true });
|
|
writeFileSync(join(root, 'src', 'cli', 'src', 'config', 'opencode-extension.ts'), out);
|
|
console.log('wrote src/cli/src/config/opencode-extension.ts');
|