cyberine mcp install — register the cyberine MCP server with a harness

Companion to cyberine skill install: instead of copying files, it registers cyberine (src/mcp.ts — the orchestrator's own MCP server, exposing orchestrate + bus tools; npm run mcp runs it directly) as an MCP server a harness can call — Claude Code (the default target) or, via --target, Codex CLI, Muse Code CLI or Gemini CLI.

cyberine mcp install                        # Claude Code, --scope user (idempotent: no-op if already registered)
cyberine mcp install --scope project        # Claude Code, THIS project's .mcp.json instead of the user-level config
cyberine mcp install --target codex         # Codex CLI: writes [mcp_servers.cyberine] into ~/.codex/config.toml (or $CODEX_HOME)
cyberine mcp install --target muse          # Muse Code CLI: writes mcpServers.cyberine into ~/.config/muse/settings.json
cyberine mcp install --target gemini        # Gemini CLI: writes mcpServers.cyberine into ~/.gemini/settings.json
cyberine mcp install --target codex --print # print the entry that would be written instead of registering (any target)

Claude Code (--target claude, the default): live mode probes claude mcp get cyberine first — already registered is reported and exits 0 without touching config — then runs claude mcp add --scope <scope> cyberine -- <command> with CLAUDE_CODE_OAUTH_TOKEN/ANTHROPIC_API_KEY stripped from the child's env so the probe and the add never inherit this process's own Claude credentials. --print (or running with no claude CLI on PATH at all) skips the live probe entirely and prints the JSON block plus a hint on stderr naming where to paste it — .mcp.json at the project root for --scope project, or the project's entry under ~/.claude.json's mcpServers for the default --scope user. --scope has no effect on the other three targets (a note is printed if combined).

Codex / Muse / Gemini (--target codex|muse|gemini): these three write the harness's own config file directly (never shelling out to that harness's CLI, so the write works even when the harness isn't installed) — see docs/providers/codex-cli.md, muse-cli.md and gemini-cli.md's "MCP servers" sections for the exact schema each one takes. Every target shares the same safety contract:

• Merge, never clobber. The existing file is parsed (TOML for Codex, JSON for Muse/Gemini) and every other key or table is left untouched; only a cyberine entry is added.
• Idempotent. Running the same --target twice detects the existing cyberine entry and prints already registered without writing.
• One backup before the first write. If the target file already exists, it is copied once to <file>.bak-cyberine before any write — a second install run (already idempotent, so no write happens) never overwrites that backup.
• No secrets written. The entry carries only command/args (the cyberine-mcp binary path); CYBERINE_MCP_AUTH_TOKEN, if the operator has it set, reaches the spawned server process through normal environment inheritance from the harness, never through the config file.
• --print writes nothing for any target — it shows the exact entry (or, for Codex, the exact TOML table) on stdout with a stderr hint naming the file it would merge into.

The command resolves to the cyberine-mcp binary when it is on PATH, else node <pkgRoot>/bin/cyberine-mcp.mjs, for every target.

Known limitations and deferred work

• --scope project is Claude-Code-only. Codex, Muse and Gemini always write to the user-level config file; Gemini's own project-scoped .gemini/settings.json and Codex's project-trusted .codex/config.toml are not wired up here.
• Muse Code has no muse mcp add/muse mcp list — the CLI's own mcp subcommand only manages OAuth login/logout for an already-configured server (muse mcp --help), so there is no harness-side listing to observe after an install; verify by reading ~/.config/muse/settings.json directly.
• The Muse MCP client schema in docs/providers/muse-cli.md is measured from the installed binary's own validation strings (there is no public Meta doc page for it), not exercised end-to-end through a live Muse dispatch calling a tool over the registered server.