JetBrains Junie vs Claude Code

Junie is JetBrains’ coding agent. It runs inside JetBrains IDEs, as a plugin or through AI Assistant’s chat, and as a standalone CLI that can connect back to the IDE. Claude Code is Anthropic’s agent, a CLI that reaches IntelliJ IDEA, PyCharm and the rest through a plugin. The practical difference is where the intelligence about your project comes from. Junie leans on the IDE itself: its indexes, inspections, refactorings and test runner. Claude Code leans on its own loop of searching, reading and running commands, and borrows little from the IDE beyond diffs and diagnostics. Junie also runs models from several providers, while Claude Code runs Claude. If you live in a JetBrains IDE and want the agent to use what the IDE knows, try Junie first. If you want the strongest agent loop on Claude models and the same tool in every editor and terminal, use Claude Code.

What Junie is today

Junie’s documentation has moved to junie.jetbrains.com, and the older jetbrains.com/junie and jetbrains.com/help/junie addresses redirect there. It now describes several surfaces:

• Junie in AI Chat: one of the agents inside JetBrains AI Assistant’s chat, the installation route the documentation recommends.
• The Junie IDE plugin: a separate tool window from the JetBrains Marketplace, in IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, RubyMine, RustRover, CLion, Rider and Android Studio.
• Junie CLI: a terminal agent for Linux, macOS and Windows, installed with a script and started with junie in the project folder.
• Automation: a GitHub Action, GitLab CI/CD, a headless mode for scripts, and an ACP mode (junie --acp true) for editors that speak the Agent Client Protocol.

The CLI and the IDE are connected, not separate products. According to the page on Junie CLI and JetBrains IDE integration↗ (opens in a new tab), when the Junie plugin is running in a supported IDE on the same project, the CLI finds it automatically and uses it for symbol-aware search, code inspections, test discovery and execution, and refactorings; /ide shows the connection state. Without an IDE, the CLI still works, only without those features.

Modes and approvals

• In the IDE plugin: Code mode plans and carries out multi-step changes, Ask mode is read-only for questions and exploration, and Auto lets Junie choose.
• In the CLI: Plan mode (Shift+Tab, /plan or --plan) explores read-only and writes a design document with requirements, technical design, testing and delivery steps, which you confirm before any code changes. Debug mode drives a live debugger session in a connected IDE.
• Approvals: Junie asks before terminal commands, MCP tools, edits outside the project and reading files that may hold secrets. The Action Allowlist in ~/.junie/allowlist.json pre-approves commands by prefix or pattern.
• Brave mode: in the CLI it has three levels, Off, Auto (a safety check approves commands it judges safe) and On (everything runs without asking), switched with /brave or Ctrl+B.

The Junie CLI allowlist page↗ (opens in a new tab) is worth reading before you trust it: chained commands are checked part by part, commands inside $(...) are checked too, and a command spread over several lines always asks. Rules are read top to bottom and the first match wins, so put the narrow ask rules above the broad allow ones.

Guidelines: .junie/AGENTS.md first

Junie used to read .junie/guidelines.md. It now reads AGENTS.md, and the old file is the legacy fallback. Junie’s guidelines page↗ (opens in a new tab) gives the order it looks in:

1. .junie/AGENTS.md in the project root, used on its own when it exists.
2. Otherwise AGENTS.md in the project root, combined with .junie/playbook.md and every .junie/rules/*.md file.
3. Otherwise the legacy .junie/guidelines.md file or .junie/guidelines/ folder, still supported.

Global guidelines go in ~/.junie/AGENTS.md, and project guidelines win where the two conflict. The IDE plugin has a Guidelines path setting, which the documentation says to set for monorepos. On first opening a project, Junie CLI also looks for other agents’ instruction files and offers to import them into .junie/AGENTS.md. Think before accepting: a copy in .junie/AGENTS.md means Junie stops reading your root AGENTS.md, and two copies drift. If your team already keeps its rules in the root AGENTS.md, leave .junie/AGENTS.md out and let Junie read the shared file, which is also what Claude Code reads when there is no CLAUDE.md. How the other tools resolve their files is in AI context files compared.

MCP and models

Junie is an MCP client. The CLI reads servers from .junie/mcp/mcp.json in the project and ~/.junie/mcp/mcp.json for you, in the familiar mcpServers shape: a command and args for a local server, or a url with optional headers for a remote one. Servers that need OAuth are authorised through the installation assistant under /mcp. In the IDE plugin, the MCP Settings page opens the same kind of mcp.json and shows each server’s status and tools.

Models are the bigger difference from Claude Code. By default Junie picks a model for you that JetBrains changes as new ones arrive, and you can choose models from OpenAI, Anthropic, Google and xAI, Claude among them. The CLI adds bring-your-own-key for OpenAI, Anthropic, Google, xAI, OpenRouter and GitHub Copilot, and custom or local endpoints such as Ollama, LM Studio and LiteLLM. The IDE plugin itself does not take your own key; the documentation points you to AI Assistant’s chat for that.

Junie vs Claude Code for JetBrains users

• IDE depth: Junie uses the IDE’s own indexes, inspections, refactorings and test runner. Claude Code’s JetBrains plugin shows diffs in the IDE viewer, sends your selection, and lets Claude read inspection results when it asks for them.
• Models: Junie offers several providers, your own keys and local models. Claude Code runs Claude, through Anthropic or a cloud provider.
• Instructions: Junie reads .junie/AGENTS.md or the root AGENTS.md. Claude Code reads CLAUDE.md, and AGENTS.md when there is no CLAUDE.md. A root AGENTS.md serves both.
• Approvals: Junie has Ask and Code modes, an allowlist file and three brave levels. Claude Code has permission modes, starting in auto from v2.1.283, with allow and deny rules in settings.
• Ignored files: Junie respects an .aiignore file. In Claude Code the equivalent is a Read deny rule.
• Reach: Claude Code is the same agent in VS Code, a desktop app, the web and CI. Junie is at its best in JetBrains IDEs, though its CLI and ACP mode work elsewhere.

You do not have to choose one tool per IDE. JetBrains’ agents page for AI Assistant↗ (opens in a new tab) lists Junie, Claude Agent, Codex and GitHub Copilot in the same chat, plus any agent that speaks ACP. The table there has details that matter: Claude Agent reads CLAUDE.md, Junie and Codex read AGENTS.md, and only Junie respects .aiignore. Running the full Claude Code CLI with its JetBrains plugin is a different setup, covered in Claude Code in JetBrains IDEs.

Junie vs Codex, briefly

Codex is OpenAI’s agent: a CLI, an IDE extension and the ChatGPT desktop app, and one of the agents in JetBrains AI Chat with Read-only, Agent and Agent (full access) modes. Both Junie and Codex read AGENTS.md, so one file serves both. Codex keeps its MCP servers in ~/.codex/config.toml, shared across its surfaces, according to OpenAI’s Codex MCP documentation↗ (opens in a new tab), while Junie uses mcp.json. Codex runs OpenAI models; Junie offers several providers. Pick Codex if your team is already on ChatGPT and wants the same agent in the cloud; pick Junie if IDE awareness in a JetBrains project matters more. The wider comparison is in Claude Code vs Codex.

The same board for both

Whichever agent you use, the work outlives the session. fenbs is a task board both can reach over MCP at https://fenbs.ai/api/mcp. Claude Code connects with claude mcp add and a browser sign-in. For Junie, add the server to .junie/mcp/mcp.json, either through /mcp or with a token issued under Settings, which has a name, the scopes you tick and an optional expiry. Each agent then reads the next task, moves it across To Do, Next Up, In Progress and Completed, fills in how it was tested, and signs every change with its own name.

{
  "mcpServers": {
    "fenbs": {
      "url": "https://fenbs.ai/api/mcp",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}