JFrog for Coding Agents

JFrog plugin for JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, GoLand, Rider, and others). It delivers the JFrog Agent Skills bundle and a JFrog (remote) MCP server to Junie — artifact management, security scanning, supply-chain best practices, and Agent Guard for MCP governance.

Status: the JFrog skills bundle and the JFrog (remote) MCP server are delivered to Junie automatically on IDE startup.

Preview Notice: This Plugin is in preview and licensed under the Apache License 2.0. For clarity: This software is provided "as-is" without warranty of any kind, and without support obligations or service level commitments. Behavior, APIs, conventions, and structure may change without notice between releases. JFrog makes no guarantees of backward compatibility during the preview release cycle. Use in production environments is at your own risk.

Scope

This plugin targets Junie, JetBrains' native coding agent, specifically. IntelliJ's AI Assistant chat also lets you drive external agents (Claude Agent, Codex, Gemini CLI) via the Agent Client Protocol — those are out of scope here and manage their own configuration independently. If you want JFrog tooling in one of those, install claude-plugin / codex-plugin into that tool directly.

Features

Component	Feature	Description
Skill	JFrog Platform	Interact with Artifactory repositories, builds, permissions, users, access tokens, projects, release bundles, and platform administration via the JFrog CLI and REST/GraphQL APIs. Also covers security audits, CVE lookups, and Advanced Security exposure queries.
Skill	Package safety & download	Check whether npm, Maven, PyPI, Go, and other packages are safe, curated, or allowed, then download them through Artifactory remote caches or curation-aware package managers.
Skill	Agent Guard	Manage MCPs through the JFrog Agent Guard — discover, install, configure, update, and remove MCP servers from the JFrog AI Catalog approved for your project.
MCP (remote)	JFrog MCP server	The remote JFrog MCP server (OAuth, no API keys), auto-added to Junie's ~/.junie/mcp/mcp.json. See How delivery works.

Prerequisites

• A JetBrains IDE on 2025.2+ with Junie installed.
• JFROG_PLATFORM_URL environment variable set to your JFrog instance (e.g. mycompany.jfrog.io). The plugin uses it to fill in the JFrog MCP server URL.
• Node.js (≥ 18) with npx on your PATH (used by Agent Guard).
• Skill runtime (when using the skills) — jf CLI, jq, and curl on PATH, plus a configured JFrog instance. For the minimum versions, see the upstream skills Requirements.
• JFrog Platform access (optional) — the Agent Guard feature needs the AI Catalog entitlement on your subscription.

Installation

Install JFrog for Coding Agents from the JetBrains Marketplace (Settings | Plugins | Marketplace, then search for it), or build the zip from source and install it via Settings | Plugins | ⚙ | Install Plugin from Disk...:

./gradlew buildPlugin # produces build/distributions/*.zip

How delivery works

The plugin materializes its assets into your global Junie home on IDE startup (JfrogJunieDeployer):

Written to	What	Notes
~/.junie/skills/	The vendored jfrog-skills bundle	Refreshed when the plugin version changes; other (non-JFrog) skills in the folder are left untouched.
~/.junie/mcp/mcp.json	A jfrog remote MCP server entry	Merged, not clobbered — Junie's own idea entry and any other servers survive. The URL is resolved from JFROG_PLATFORM_URL, falling back to your JFrog CLI config.

Junie discovers these by convention (skills from .junie/skills/, MCP servers from .junie/mcp/mcp.json). The first JFrog MCP call in Junie triggers a one-time browser OAuth login.

Invoking jfrog-init in Junie. In the Junie IDE agent panel, run it by asking for it — type /jfrog-init or "run jfrog-init", and the panel loads the skill on that explicit request. (Custom /name slash commands are a Junie CLI-only feature, not an IDE one.)

Host resolution. The jfrog URL host is resolved in this order:

1. The JFROG_PLATFORM_URL environment variable, if set.
2. Otherwise your JFrog CLI config (~/.jfrog/jfrog-cli.conf.v*): the server marked default, or — if only one server is configured — that single server.
3. If neither is available, the placeholder https://<JFROG_PLATFORM_URL>/mcp is written.

If the placeholder was written (the host couldn't be resolved automatically), you must set it yourself — the plugin does not guess. Either:

• set JFROG_PLATFORM_URL (or run jf config add) and restart the IDE so the plugin fills it in on next startup, or
• edit ~/.junie/mcp/mcp.json directly, replace <JFROG_PLATFORM_URL> with your instance host (e.g. mycompany.jfrog.io), and restart the IDE.

Skills

Skill	Description
jfrog	JFrog Platform operations via CLI and APIs (Artifactory, Xray, access, projects, and more).
jfrog-package-safety-and-download	Check package safety and download via Artifactory.
jfrog-ai-catalog-skills	Discover, install, manage, and publish agent skills from the JFrog AI Catalog via jf skills and Agent Guard.
jfrog-mcp-management	Install, list, and remove MCP servers/tools via JFrog Agent Guard, and browse the JFrog MCP catalog.
jfrog-reference-architecture	JFrog Platform topology, sizing, deployment, and HA/DR guidance from the official Reference Architecture site.
jfrog-setup-package-managers	Set up and bind package managers (npm, pip, Maven, Gradle, Go, Docker, Helm, …) to Artifactory via jf setup.

Skill content is vendored under .junie/skills/ and bundled into the plugin — see VENDOR.md.

Usage

Once the IDE has started (and OAuth is completed on first use), interact with the JFrog plugin through Junie in natural language.

Ask Junie…	What happens
"List my Artifactory repositories."	Returns repositories via the JFrog CLI / MCP.
"Run a security audit on this project."	Runs an Xray / Advanced Security audit and summarizes findings.
"Which MCP servers can I install?"	Returns MCP servers approved for your project (Agent Guard).
"Add the GitHub MCP server."	Installs an approved MCP server and syncs its tool policies locally.
"Remove the Slack MCP server."	Removes the server and its stored credentials.
"Is lodash@4.17.21 safe to install?"	Checks JFrog Public Catalog signals and curation policy.

Troubleshooting

• ⚠️ Junie can't find a command (e.g. node / npx / jf "command not found"), or an installed MCP fails to start. Junie may not pick up configuration from ~/.zshrc / ~/.bashrc, so tools installed via nvm or Homebrew can be missing from its PATH. This is mainly a macOS issue. To see which folders Junie does have, run echo $PATH in a Junie chat (often just /usr/local/bin and the system dirs); symlink your tools into one of those, then restart the IDE. For example, with Homebrew: sudo ln -sf /opt/homebrew/bin/{node,npm,npx,jf} /usr/local/bin/. The JFrog skills need node, npx, and jf on the PATH, so make sure at least those are symlinked. With a version manager like nvm whose paths change per version, first give it a stable path (e.g. nvm's NVM_SYMLINK_CURRENT) and symlink from that.

  On Linux/Windows the IDE normally inherits your PATH; if a tool is still missing, add its folder to your OS user PATH (Linux: ~/.profile; Windows: Edit environment variables for your account) and restart the IDE.

• Where are the MCP servers / tools? In the IDE: Settings → Tools → Junie → MCP Settings. There is no interactive /mcp command in the IDE (typing /mcp in the Junie chat is treated as plain text).

• Agent Guard keeps asking for a JFrog project key. That's by design — it never guesses. Set the JF_PROJECT environment variable to skip the prompt.

• For platform-side MCP issues, see the JFrog MCP Registry troubleshooting guide.

Updating the vendored skills

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

1. Bump pin in .github/scripts/sync-skills-vendor.json to the new upstream tag.

2. Run the sync script from the repo root:

   node .github/scripts/sync-skills.mjs

   It downloads the pinned tarball from codeload.github.com, extracts it, and replaces .junie/skills/.

3. Bump VERSION and the matching version in gradle.properties so the published plugin — and the startup deployer's version marker — pick up the new bundle.

4. Commit the pin bump, the regenerated .junie/skills/ tree, and the version bump together, and open a PR.

See VENDOR.md for the full picture.

Repository layout

jetbrains-plugin/
├── build.gradle.kts / settings.gradle.kts / gradle.properties
├── src/main/resources/META-INF/plugin.xml       # plugin manifest
├── src/main/kotlin/com/jfrog/jetbrains/
│   └── startup/       # JfrogJunieDeployer (materializes skills + MCP into ~/.junie)
├── .junie/skills/     # vendored Agent Skills (see VENDOR.md)
├── .junie/mcp/mcp.json # JFrog MCP server template (${JFROG_PLATFORM_URL})
├── .github/scripts/   # sync-skills vendoring
├── LICENSE
├── README.md
└── VENDOR.md

Check it locally

node scripts/validate-jetbrains-plugin.mjs   # fast: manifest + skills + MCP template
./gradlew verifyPlugin                        # plugin structure + compatibility checks
./gradlew buildPlugin                         # produces build/distributions/*.zip

Then install the built zip in a real IntelliJ + Junie and confirm the JFrog skills + JFrog MCP surface. (The runIde sandbox can't run Junie end-to-end.)

Publishing to JetBrains Marketplace

Publishing is signed + token-based (configured in build.gradle.kts). Run it from the Publish to JetBrains Marketplace workflow (workflow_dispatch), or locally with ./gradlew publishPlugin.

It requires four repository secrets — add them under Settings → Secrets and variables → Actions:

Secret	What	Where to get it
PUBLISH_TOKEN	Marketplace upload token	Marketplace profile → My Tokens
CERTIFICATE_CHAIN	Signing certificate chain (PEM)	Plugin Signing
PRIVATE_KEY	Signing private key (PEM)	Plugin Signing
PRIVATE_KEY_PASSWORD	Private-key password (only if the key has one)	—

The first version must be uploaded manually at plugins.jetbrains.com → Upload plugin (JetBrains reviews the first submission). Token/CI publishing only works after the plugin listing exists.

Releasing

VERSION at the repo root is the source of truth, and version in gradle.properties has to match it — PRs fail the Validate plugin check if the two disagree.

Every merge to main must bump both files. .github/workflows/release.yml fails when the version is not newer than the latest vX.Y.Z tag, and it creates the tag and the GitHub Release (with the built plugin zip attached) when it is. If no release tags exist, the first merge publishes the version already in those files.

License

Apache License 2.0 — see LICENSE.