JFrog Plugin for OpenCode

JFrog plugin for OpenCode: artifact management, security scanning, supply-chain best practices, and Agent Guard. The plugin ships the official JFrog Agent Skills with the package and registers them with OpenCode at load time, plus the JFrog Platform MCP server.

The JFrog plugin provides the following capabilities, grouped by component:

The skills ship with the plugin (vendored and pinned) — they are not downloaded at runtime, so the plugin works offline and the skill set is reproducible for a given plugin version.

Before installing, make sure you have:

• JFrog host URL and access token — A JFrog Platform instance you can authenticate against.
• OpenCode — Installed (verified against OpenCode 1.17.7 and newer, which honors config.skills.paths in object form).
• Node.js (≥ 18) — with npx on your PATH (used by the Agent Guard).
• Skill runtime requirements — jf CLI, jq, and curl on PATH, plus a configured JFrog CLI server. For the minimum versions, see the upstream skills Requirements. Configure the CLI with jf login / jf config add — see Authentication.
• JFrog AI Catalog (optional) — If you want to use the Agent Guard feature, your JFrog subscription needs to include the AI Catalog entitlement. Contact your JFrog account team if you're unsure whether it's enabled.
• JFrog CLI ≥ 2.105.0 (optional) — If you want the Agent Guard to auto-resolve the credentials/server ID from the JFrog CLI configuration.
• JFrog project (optional) — If you want to use the Agent Guard feature.

The plugin is published to public npm as @jfrog/opencode-jfrog-plugin and listed on the OpenCode ecosystem page. OpenCode has no plugin marketplace — you install by referencing the npm package in your OpenCode config (opencode.json):

{
  "plugin": ["@jfrog/opencode-jfrog-plugin"]
}

OpenCode resolves the package from npm and loads it. To pin a specific version use "@jfrog/opencode-jfrog-plugin@<version>"; omitting the version tracks the latest release. For an organization-wide rollout, set the plugin in OpenCode's remote configuration so every developer gets it automatically.

Test an uncommitted checkout without publishing. Build the module, then point your OpenCode config at the local build:

mise run build

{
  "plugin": ["file:///absolute/path/to/opencode-jfrog-plugin/dist/index.js"]
}

Local paths must be absolute (file://) or start with ./ / ../ (resolved relative to the config file). Restart OpenCode after a rebuild to pick up changes.

The plugin is intentionally thin. On load it resolves its bundled skills/ directory (shipped inside the package) and registers it with OpenCode through the config hook by adding it to config.skills.paths. OpenCode then discovers the skills the same way it discovers any skill — via the skill tool and /skills — and invokes them when relevant. There is no runtime download, unzip, or network call on load.

The plugin is self-contained: everything it needs ships in the published npm tarball (dist/ + the vendored skills/), with no runtime downloads and no dependency on releases.jfrog.io or any other external artifact host.

Configure the JFrog CLI so the skills and Agent Guard can reach your platform. Run jf login for browser-based setup, or if you have never configured the JFrog CLI on this machine:

1. Open your terminal.

2. Run:

   jf config add

3. Follow the interactive prompts to enter your JFrog platform URL and access token.

The JFrog Platform MCP server authenticates separately from an access token — see below.

When the environment is configured, the plugin registers the JFrog Platform remote MCP server (https://<JFROG_URL>/mcp) into config.mcp.jfrog, so the JFrog platform tools appear in OpenCode alongside the skills.

Prerequisites — both must be set:

• JFROG_URL — your JFrog platform URL (e.g. https://mycompany.jfrog.io). The legacy JF_URL and the JFROG_PLATFORM_URL (Cursor-compat) names are also accepted.
• JFROG_ACCESS_TOKEN — a JWT access token created with jf access-token-create (or the legacy JF_ACCESS_TOKEN). This must be a JWT access token, not a 64-character reference token — reference tokens are rejected by the /mcp endpoint.

The MCP is authenticated with the token directly (Authorization: Bearer …, oauth: false), so it works headlessly with no interactive browser sign-in. Registration is a pure config mutation — there is no network call on plugin load.

Opt-out: set JFROG_MCP_DISABLE=true to skip MCP registration entirely. You can also scope the exposed tools via OpenCode's tools globbing. If you define your own mcp.jfrog server in your config, the plugin leaves it untouched.

Context cost: the JFrog MCP exposes ~56 tools whose schemas are loaded into the model context on every request (OpenCode has no lazy tool loading), measured at roughly +32K tokens per request. If that overhead matters, disable it with JFROG_MCP_DISABLE=true or narrow the surface with tools globbing. The bundled skills do not carry this cost — only their short descriptions stay in context, and a skill's body loads only when it is invoked.

Token handling: OpenCode does not expand {env:…} placeholders in config that a plugin injects at runtime, so the plugin reads JFROG_ACCESS_TOKEN from the environment and sets the resolved Authorization: Bearer <token> header directly. The token therefore lives in the in-memory session config (sourced from your environment); the plugin itself never writes it to disk. Prefer a short-lived token (jf atc --expiry=…).

Once configured, interact with the JFrog plugin through natural language. Examples are grouped by capability.

When an MCP server requires a sensitive configuration value, the agent cannot set it directly. Instead, it returns a CLI command for you to copy and run in your terminal. Secrets such as API keys, tokens, and connection strings are never exposed in the agent chat history.

The plugin does not log by default. To enable debug logging:

export JFROG_DEBUG_LOGS=true

Logs are written to <project-root>/.opencode/event-log.txt.

• "bundled skills not found" (a toast in the TUI and/or an ERROR line in the log) — the installed package is incomplete or corrupted; reinstall @jfrog/opencode-jfrog-plugin.
• 401 / SSE error for the JFrog MCP in opencode mcp list (or the TUI) — the /mcp endpoint rejected the token. Make sure JFROG_ACCESS_TOKEN is a JWT access token (jf atc), not a 64-char reference token, and that it was issued for the same platform as JFROG_URL (check jf c show). With JFROG_DEBUG_LOGS=true, a non-JWT token also produces a WARNING line in the event log.

For MCP-registry issues, see the JFrog MCP Registry troubleshooting guide.

The skills/ tree is vendored from jfrog/jfrog-skills at the version pinned in sync-skills-vendor.json. To pull a newer upstream release:

1. Bump pin in sync-skills-vendor.json to the new tag (e.g. v0.23.0).

2. Re-sync and commit the refreshed tree:

   node scripts/sync-skills.mjs   # or: mise run sync-skills

   It downloads the pinned tarball from codeload.github.com and replaces the directories listed in paths (today: skills/).

3. Update the pinned-version link in the Prerequisites section so the skill runtime requirements point at the new tag.

4. Cut a plugin release so the new skills ship to users (see Release). Until a release is published, installed plugins keep using the previously vendored skills.

CI runs mise run sync-skills:check, which re-vendors and fails if the committed skills/ tree drifts from the pin. See VENDOR.md for the full picture.

This release changes behavior in ways that are not backward compatible:

• Skill catalog changed. The previous Artifactory skills — skill-install, skill-publish, jfrog-cli, opencode-jfrog-mcp, jfrog-curation, jfrog-packages — are replaced by the canonical vendored skills above. Invocations of the removed skill names no longer exist; that functionality now folds into the jfrog skill.
• Package-manager auto-setup was removed. Earlier versions ran jf setup <pm> automatically on session start; that is gone. Durable package-manager setup is provided by the jfrog-setup-package-managers skill.
• Old skills are not auto-cleaned. The plugin no longer touches ~/.config/opencode/skills. If you used a version < 0.0.3, remove the old managed skill directories yourself under ~/.config/opencode/skills.
• No more runtime artifacts. The plugin no longer injects instructions files or writes local package-manager state, and it no longer downloads skills at runtime.
• Dependencies resolve from public npm. Internal registry references were removed; the build and CI now resolve from public npm.

Tasks are run with mise:

• mise run build — build the module
• mise run test — run the test suite
• mise run typecheck — type-check with tsc --noEmit
• mise run lint — lint with ESLint
• mise run lint:fix — auto-fix lint issues
• mise run format — format with Prettier
• mise run sync-skills — re-vendor the bundled skills (see VENDOR.md)

Releases are automated with release-please: merge Conventional-Commit PRs (feat:, fix:, …) to main, and release-please opens a release PR that bumps the version and updates the changelog. Merging that PR tags the release and publishes to npm. See RELEASE.md for details.

Do not hand-edit the version in package.json — release-please manages it.

Contributions are welcome! See CONTRIBUTING.md. Please file issues or open pull requests on the GitHub repository.

See SECURITY.md for how to report vulnerabilities.

See the LICENSE file for details.

Verified against OpenCode 1.17.7 and newer (the first version confirmed to honor config.skills.paths in object form). Older versions are not supported.