- New agent-plugins provider discovers packages with a root plugin.json
targeting the canonical schema (agent-plugins.org) from marketplace
installs, --plugin-dir, and configured extension roots; skills/ and
mcp.json load per spec with closed-schema validation,
${PLUGIN_ROOT}/${PLUGIN_DATA} expansion, reserved subprocess
environment, instance-keyed data dirs, and per-component isolation.
- Package-boundary containment (spec §4.1) is enforced before every
read via the new contained-path helpers, including skill:// resource
access from the read tool and bash; plugin skill files must
realpath-resolve inside the plugin root (skills carry containRoot).
- Legacy claude-plugins/omp-plugins providers yield skills and MCP
surfaces of standard-targeting roots to the new provider and skip
fatally invalid packages.
OMP plugins ship their own .mcp.json, and that provider whitelists fields into
the canonical MCPServer shape the same way the other loaders do, so a plugin
bundling an integer-only server could set requestIdFormat and still have it
dropped before it reached a transport.
Extract the value parsing into parseRequestIdFormat() next to parseBoolean() in
discovery/helpers.ts and use it from all three OMP-owned loaders (native,
standalone mcp.json, omp-plugins), replacing the two hand-rolled copies.
Vendor providers (claude, claude-plugins, cursor, vscode, gemini, opencode,
windsurf) are deliberately untouched: they translate another tool's own server
list, where an OMP-specific key has no meaning.
Discovered plugin .mcp.json stdio servers launched relative command/cwd
values against the session cwd instead of the plugin's config directory,
breaking bundled ChatGPT/Codex plugins (e.g. Computer Use) with ENOENT
when spawning ./... from an unrelated cwd.
The claude-plugins and omp-plugins providers now resolve relative cwd and
path-like command (./ or ../) against the .mcp.json directory via a shared
resolvePluginStdioPaths helper; bare executables such as npx are left
untouched so PATH lookup still works.
Fixes#5330
Bug 1: capability loaders in src/discovery/builtin.ts only walked
.omp/ and ~/.omp/agent/, so extension packages registered via
extensions: in settings or --extension on the CLI shipped their
skills/, hooks/pre|post/, tools/, commands/, rules/, prompts/, and
.mcp.json silently — the docs at omp.sh/docs/extension-authoring
advertise the opposite. Add a new omp-plugins discovery provider that
scans every configured extension package directory for those
sub-trees, plus a small omp-extension-roots helper that resolves the
union of settings-driven and CLI-injected roots. main.ts injects CLI
extension paths via injectOmpExtensionCliRoots before any capability
load.
Bug 2: install was never registered as a top-level subcommand, so
`omp install ./my-extension` was rewritten to `launch install
./my-extension` and forwarded to the LLM as an initial prompt. Add a
top-level install command that routes local paths to plugin link and
remote specs to plugin install. Extract the command table into
src/cli-commands.ts so tests can introspect registered subcommands
without triggering cli.ts's top-level await.
Fixes#1496
can1357