On this page#
- What the integration actually does
- The wiring
- Scope
- Invariants
- Required workflow
- Commands
- Completion report
- Commands
- The two things that break it
- Verifying it works
- Team considerations
- Claude Code onboarding
- FAQ
What the integration actually does#
Claude Code can work with IntelliJ, but the integration is a context bridge—not an AI feature built into the IDE. IntelliJ supplies editor state such as the selected code and active file; Claude Code remains a separate agent with its own terminal process, permissions, tools, and model access.
That distinction matters because teams often expect the wrong architecture:
| Assumption | What actually happens | |---|---| | IntelliJ runs Claude Code | The Claude Code process runs separately, usually in the IDE terminal | | The plugin controls the agent | It connects IDE context and IDE-native views to the agent | | Open files are automatically authoritative | Repository files and explicit instructions remain authoritative | | A working plugin means the repository is configured | IDE connectivity and repository operating rules are separate concerns | | Every developer inherits the same setup | Machine-local installation and authentication still belong to each developer |
Claude Code is an agentic coding tool: it can inspect a repository, edit files, run commands, and work through multi-step tasks. The IntelliJ integration improves how that agent receives editor context and presents changes. It does not replace repository-level instructions.
This is why a plugin-only rollout is the wrong approach. It can make one developer’s intellij claude code workflow feel polished while leaving the next developer without the commands, boundaries, or verification rules required to use it safely.
Photo by cottonbro studio on Pexels.
The wiring#
A durable claude code intellij setup has three layers: a machine-local IDE connection, repository-owned operating instructions, and project-owned commands. Only the first layer should depend on an individual workstation. The other two must travel with the repository so another developer gets the same behavior.
Connect IntelliJ to the Claude Code process#
Install the official Claude Code integration through IntelliJ’s plugin interface, then start Claude Code from the terminal inside the repository. Keeping the terminal’s working directory at the repository root removes ambiguity about which project the agent is operating on.
Use this startup pattern:
cd /path/to/repository
claudeThen run the IDE connection command inside Claude Code:
/ideSelect the IntelliJ instance that has the repository open. If more than one IDE window is running, do not choose by position or habit; confirm the project path. The official Claude Code documentation is the authority for installation and supported IDE behavior, while the repository must define how the agent should work after connection.
The plugin and authentication are machine-local. Do not commit IDE caches, credentials, tokens, or generated connection state just to make onboarding appear automatic.
Put operating rules in the repository#
Create a repository-level CLAUDE.md that explains the project’s invariants and gives the agent deterministic commands. This is not a style guide or a prompt scrapbook. It is the shortest reliable operating contract for anyone—or any agent—changing the code.
A useful starting point is directly pasteable:
# Repository operating rules
## Scope
Work only inside this repository unless the developer explicitly approves otherwise.
*Photo by ThisIsEngineering on [Pexels](https://www.pexels.com/photo/female-software-engineer-coding-on-computer-3861951/).*
## Invariants
- Preserve public interfaces unless the task explicitly changes them.
- Do not bypass validation, authorization, or migration checks.
- Keep generated files generated; edit their source instead.
- Do not add dependencies without explaining why existing ones are insufficient.
## Required workflow
1. Read the nearest relevant code and tests before editing.
2. Make the smallest coherent change.
3. Run the narrow verification command first.
4. Run the full repository check before declaring completion.
*Photo by Al Nahian on [Pexels](https://www.pexels.com/photo/computer-program-on-computer-screen-7325498/).*
## Commands
- Install: `<project install command>`
- Focused test: `<focused test command>`
- Full test: `<full test command>`
- Lint: `<lint command>`
- Type-check: `<type-check command>`
- Build: `<build command>`
## Completion report
State:
- files changed;
- commands run;
- failures or skipped checks;
- assumptions that still require human confirmation.Replace every placeholder with a real repository command before committing it. Empty ceremony is worse than no instructions because it creates false confidence.
Claude Code’s overview explains the agent’s capabilities, but it cannot document your repository’s invariants. If the team needs a fuller starting contract, the PairFoundry Agent Operating Kit is designed for that repository-owned layer.
Make verification commands stable#
Do not tell the agent to “run the tests” when developers must remember several package-manager flags or change directories first. Give both humans and agents a stable project entry point, using whatever task runner the repository already owns.
For example:
verify:
<lint command>
<type-check command>
<full test command>
verify-focused:
<focused test command>Then reference those targets from CLAUDE.md:
## Commands
- Focused verification: `make verify-focused`
- Full verification: `make verify`The exact commands are repository-specific, so inventing them in an article would be irresponsible. The important configuration is the interface: one documented command for fast feedback and one for the completion gate. See the broader Wiring It In guidance for keeping agent behavior attached to project mechanics.
The two things that break it#
Most failed setups come from one of two boundaries: Claude Code cannot discover the intended IntelliJ instance, or it reaches the IDE but operates with the wrong repository context. Reinstalling everything treats both failures as one problem and usually hides the actual cause.
“No available IDEs detected”#
This error means the Claude Code process cannot see a compatible, connected IDE instance. It does not mean the model is unavailable, the repository is invalid, or authentication necessarily failed.
Fix it in this order:
- Confirm the official integration is enabled in IntelliJ.
- Keep the intended project window open.
- Start Claude Code from that project’s IntelliJ terminal.
- Run
/ideagain. - If multiple windows appear, select the one matching the repository path.
Starting the agent in an unrelated external shell is a common cause because the process and IDE no longer share an obvious project context. Use the connection workflow described in the official Claude Code docs before changing repository configuration.
The connection succeeds, but context is wrong#
This failure is more dangerous because nothing looks broken. Claude Code may be connected to a different IntelliJ window, launched from a parent directory, or given a selection from a file that is not the intended source of truth.
Stop and verify three identities:
IDE project: /path/to/repository
Terminal cwd: /path/to/repository
Git worktree: /path/to/repositoryThose paths should describe the same checkout. If they do not, exit the agent, move to the correct repository root, restart it, and reconnect with /ide.
Do not solve this by granting broader filesystem access. Wider access makes the mismatch harder to notice and increases the impact of a mistaken edit. The agent capabilities described in the official overview are useful precisely because they are powerful; project identity must therefore be explicit.
Verifying it works#
A successful connection indicator is insufficient. Verification must prove that editor context reaches the intended agent, edits land in the intended worktree, and repository checks—not visual confidence—decide whether the result is acceptable.
Use a harmless, reversible verification sequence:
- Open a tracked source file in IntelliJ.
- Select a distinctive method or block.
- Ask Claude Code to identify the selected symbol and its file without editing anything.
- Ask for a one-line temporary change.
- Confirm the diff appears against the correct file.
- Revert that temporary change.
- Ask Claude Code to name the repository’s focused and full verification commands from
CLAUDE.md.
A complete pass proves four separate facts:
- IDE selection context is reaching Claude Code.
- The agent is attached to the intended IntelliJ window.
- File changes target the intended Git worktree.
- Repository instructions are discoverable from a fresh session.
Finally, run the repository’s full verification command. Claude Code’s documented workflow does not make a green IDE indicator equivalent to a green build.
Team considerations#
The second developer will not inherit the first developer’s plugin installation, authentication, terminal state, permissions, or IDE window selection. They should inherit repository instructions and stable commands. A rollout that stores essential knowledge only in one person’s IntelliJ settings is not a team setup.
Commit:
CLAUDE.md;- stable verification entry points;
- repository-specific safety boundaries;
- required generated-file and migration rules.
Do not commit:
- credentials or tokens;
- user-specific absolute paths;
- IDE caches;
- personal permission overrides;
- assumptions about which IntelliJ window is open.
Add a short onboarding check:
## Claude Code onboarding
1. Open this repository in IntelliJ.
2. Start Claude Code from the repository-root terminal.
3. Run `/ide` and select this project.
4. Read `CLAUDE.md`.
5. Perform the reversible context check.
6. Run the full verification command before real work.For developers who are not ready for a packaged operating system, the free PairFoundry foundations track provides the next step. Teams comparing broader workflow assets can use the PairFoundry packs overview.
Related reading#
FAQ#
Can Claude Code work with IntelliJ?#
Yes. Claude Code can connect to IntelliJ through its IDE integration, receiving editor context and supporting an IDE-aware workflow. Claude Code still runs as a separate agent process; IntelliJ does not replace its terminal, permissions, repository instructions, or model access. See the official Claude Code documentation.
Is the Claude Code free in JetBrains?#
Installing an IDE integration does not automatically provide Claude Code model access. Treat the plugin, Claude Code access, and any applicable usage arrangement as separate concerns. Check the official Claude Code overview rather than assuming IntelliJ includes the service.
Is IntelliJ a Russian company?#
No. IntelliJ is an IDE product, not a company. JetBrains is the company behind IntelliJ. That distinction has no effect on the wiring described here; teams should evaluate the IDE, plugin, data boundaries, and repository permissions as separate technical controls.
What IDE to use with Claude Code?#
Use the IDE your repository and team already support well. IntelliJ is a strong choice when the project depends on JetBrains inspections, navigation, or language tooling. The agent still needs repository-owned commands and invariants; changing IDEs does not repair a weak operating contract.
Does Claude Code have IDE?#
Claude Code is not itself a full IDE. It is an agentic coding tool that can integrate with an IDE such as IntelliJ. The IDE supplies editing and navigation surfaces, while Claude Code supplies the agent workflow described in the official overview.