Claude Code + Your IDE: A Workflow That Compounds
Where the terminal agent beats the IDE, where it doesn't, and how to run both for maximum output.
In Part 9, you learned how to run Claude Code headless in CI for automated fixes. Now we close the loop: how to bring the same agent into your daily IDE (integrated development environment) workflow so the terminal and the editor amplify each other. This article explains how the integration works and gives practical strategies to make the two compound rather than compete.
Claude Code is an agentic harness that runs models and tools on your machine; your IDE is a high-fidelity context provider and diff viewer. Both of Claude Code's IDE integrations run the same Claude Code engine you use in the terminal, and they read the same settings, CLAUDE.md files and conversation history. Many engineers treat the IDE panel as a chatbot, but the real power comes from treating it as a shared feedback loop: the terminal agent handles broad orchestration while the IDE handles fine-grained edits, under the same rules.
How do I set up the IDE integration?
VS Code (version 1.94.0 or later): open the Extensions view, search for "Claude Code", and install Anthropic's extension. The first time you open it, you sign in with a paid Claude plan (Pro, Max, Team or Enterprise) or a Claude Console account; no API key is needed. The extension bundles its own copy of Claude Code for its chat panel, but it does not put claude on your PATH. If you also want the CLI in a terminal, install it separately as Part 1 showed.
Cursor and other VS Code forks: the same extension installs in Cursor, which has a direct install link, and in other forks such as Kiro through the Open VSX registry. If you are weighing Cursor's own agent against Claude Code, Claude Code vs Cursor: How Each One Thinks compares the two; this article is about using Claude Code inside whichever editor you prefer.
JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, GoLand and others): install the Claude Code plugin from the JetBrains Marketplace and restart the IDE. The plugin runs the claude command in the IDE's terminal and connects to it, and it does not bundle the CLI, so install the CLI first, according to the JetBrains integration guide.
How does Claude Code actually integrate with your IDE under the hood?
There are two ways in, and they work differently.
The VS Code extension gives you a native graphical chat panel. Behind that panel runs the copy of Claude Code that the extension bundles, so the agent loop (gather context, call the model, run tools, verify results) is the same one as in the terminal. If you prefer the CLI look inside VS Code, the extension's Use Terminal setting (claudeCode.useTerminal) switches to it.
The other way is the CLI connecting to your editor. Run claude in the IDE's integrated terminal and it connects automatically; from an external terminal, run /ide inside Claude Code to connect it. The connection goes this direction: the extension or plugin runs a small local MCP server named ide, and the CLI connects to it. Through it, the CLI opens diffs in the editor's native diff viewer, sees your current selection and the path of the active file, and can ask the editor for its diagnostics, the errors and warnings from your language servers, as the VS Code integration guide describes.
Either way, the panel and the terminal are separate Claude Code processes that share configuration and history, not one process seen through two windows. This design keeps the agent core independent of the interface. When you select a broken React signup form in your side project and ask Claude Code about it from the JetBrains plugin, the IDE shares the selection and the TypeScript errors. The agent reads the surrounding file, proposes a fix, and shows you the diff in the IDE's own diff viewer. You approve or reject without leaving the editor. Throughout, the agent is bound by the same permission rules and the same CLAUDE.md instructions as in the terminal.
The IDE adds a safety net: it presents diffs as ordinary editor changes you can inspect, and the extension keeps checkpoints so you can rewind Claude's edits. The heavy work, reading and editing files, running shell commands and calling MCP servers, happens in Claude Code itself, wherever you started it.
Where does the terminal agent outperform the IDE?
The terminal agent excels at autonomous, multi-step tasks that span many files and need shell commands. In your web app, after a database schema change, you can ask Claude Code in the terminal to "run the full test suite, fix any failing tests, and update the API (application programming interface) endpoints to match the new columns." In auto mode, now the default starting mode in the terminal and in VS Code, the agent iterates with few interruptions: a classifier reviews each action while Claude reads test output, edits source files, re-runs the suite, and repeats until green. The terminal agent can also start subagents to scan many files in parallel and summarize findings without bloating the main context window.
Be precise about the other modes, because they behave differently in that loop. acceptEdits auto-approves file edits and a fixed set of filesystem commands (mkdir, touch, rm, rmdir, mv, cp, sed) inside your project, but running the test suite still asks, unless you allow it, for example with --allowedTools "Bash(npm test *)" or an allow rule. The terminal shines when you chain tools like database migrations, linters, build scripts and MCP (Model Context Protocol) connectors to your issue tracker. Some features exist only in the CLI, such as the ! shell shortcut and the full set of commands, which is another reason to keep a terminal open.
Where does the IDE agent shine brighter?
The IDE integration gives you pinpoint precision for single-file edits. When refining a complex React component's styling in your side project, you select the JSX block and ask Claude Code to "improve the responsive layout." The IDE shares exactly that selection and the file it sits in. The agent proposes a diff directly in the editor, and you review it with the same view you use for git diffs. This tight loop keeps you in flow without switching windows.
The IDE also acts as a guard rail. The diff viewer lets you inspect every change before it lands. When you work in Manual mode, Claude asks before each edit, which suits delicate refactors where you want to review every transformation. Unless you pin it, a new conversation in the extension starts in the mode you last picked, or the defaultMode from your user settings, or else the built-in default, which is auto mode in current versions. To pin Manual, set claudeCode.initialPermissionMode to default in your VS Code user settings. Diagnostics from TypeScript, ESLint or Pyright are available to the agent through the editor, so "fix the errors in this file" works on the errors your language servers already found. The IDE's language servers catch issues that the agent might miss between test runs.
How to combine both for maximum output
- Autonomous multi-file refactors
- Schema migrations with shell scripts
- Long loops in auto mode
- Pinpoint single-file edits
- Diff review in the editor
- Approving changes one at a time
Treat the terminal and the IDE as two interfaces to the same agent system, each for a different phase. Start broad planning in the terminal with plan mode from Part 7. For your side project, ask the terminal agent to "analyze the impact of changing the authentication library" and review the plan. Once you agree on the approach, approve it and let the terminal agent carry out the backend refactor, updating the API, middleware and tests. Then switch to the IDE for the frontend forms. Select the new login component and ask Claude Code to "adjust the component to use the updated session format." The IDE's diagnostics will catch any mismatches. Finish by running the acceptance tests in the terminal.
Keep both environments on the same CLAUDE.md files and settings, which they read from the same places. The extension and the CLI also share the same conversation history: to continue a conversation from the extension in the terminal, run claude --resume and pick it from the list. Use focused sessions: start a new session for each distinct workstream to keep context fresh. The extension supports several conversations in separate tabs, so you can keep a terminal session for the backend refactor and an IDE conversation for the UI polish without collision. Just do not open the same conversation in two places at once, which can mix up its messages.
How do permissions and sandboxing affect the terminal vs IDE choice?
The same permission rules apply in both environments, because both run Claude Code and read the same settings files. Switching to the IDE does not change what the agent can access. The main difference is how you see approval prompts: as text in the terminal, as a dialog in the IDE. The underlying policy is identical.
Sandboxing is a feature of the Bash tool, enforced by the operating system, and independent of the interface. The terminal invites faster modes like auto or acceptEdits because the feedback loop is quicker, while the IDE's diff review suits Manual mode, where each edit needs your approval. For heavy shell work, like running database migrations, auto mode keeps the task moving while its classifier reviews each command, and a locked-down sandbox adds a second boundary. For careful edits in shared code, use Manual mode in the IDE with step-by-step review.
Quick Reference
| Property | Value |
|---|---|
| VS Code extension | "Claude Code" in the Extensions view; VS Code 1.94.0 or later; bundles its own CLI for the chat panel |
| Cursor and other forks | Same extension (Cursor install link, or the Open VSX registry) |
| JetBrains plugin | From the JetBrains Marketplace; runs claude in the IDE terminal; install the CLI first |
| Connect an external terminal | /ide inside Claude Code |
| Context shared by the IDE | Current selection, active file path, diagnostics, diffs in the native viewer |
| Account | Pro, Max, Team or Enterprise plan, or a Claude Console account |
| Shared between extension and CLI | Settings, CLAUDE.md files, conversation history (claude --resume) |
| Permission modes | default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions |
| Pin the extension's starting mode | claudeCode.initialPermissionMode in VS Code user settings |
| Sandboxing scope | Operating system limits on the Bash tool's files and network |
| Primary terminal advantage | Autonomous multi-step orchestration, shell command chaining |
| Primary IDE advantage | Pinpoint selection edits, diff review, diagnostic feedback loop |
What you can do now
This is the last part of the series, so here is what the ten parts add up to:
- What Claude Code Actually Is (an Agent in Your Terminal): install it, run a first session, and understand the agent loop and its permission modes.
- CLAUDE.md: How Claude Code Thinks About Your Project: write a CLAUDE.md that loads where it should, and know it is guidance, not enforcement.
- Skills and Slash Commands: Teach It Your Workflows: package repeatable workflows as skills, and pre-approve only the tools they need.
- Hooks: Run Your Rules on Every Action: enforce rules on every tool call with hooks that exit 2 to block.
- MCP Servers: Give Claude Code New Powers: connect databases and services through MCP servers, at the right scope.
- Subagents and Parallel Work: fan work out to subagents, with worktrees when they write.
- Plan Mode and the Art of Not Letting the Agent Run Wild: plan before editing, and approve the plan on your terms.
- Memory and Sessions: Continuity Across Days: pick up yesterday's work with resume, CLAUDE.md and auto memory.
- Headless Claude Code: CI, Scripts, and Automation: run Claude Code in scripts and CI, safely, with bare mode and exact permissions.
- This part: combine the terminal and the IDE so each does what it is best at.
Where to go next: plugins bundle skills, subagents, hooks and MCP servers into one unit you can install or share with your team (run /plugin to browse them), and agent teams, an experimental feature, let one lead session coordinate several Claude Code sessions.
Frequently Asked Questions
Q: Can I run both the terminal and IDE agent simultaneously on the same project? Yes. They run as separate Claude Code sessions that share your project's rules and settings, so they can work on different tasks side by side. Avoid editing the same file from both at once, and do not open the same conversation in two places.
Q: Do the IDE plugins use different models than the terminal CLI?
No. Both use the same Claude models and the same Claude Code engine. The VS Code extension bundles its own copy of Claude Code, and the JetBrains plugin runs the claude you installed.
Q: If I make a change in the IDE, will the terminal agent see it immediately? Your edits are saved to disk, so the next time the terminal agent reads the file, it sees them. Claude Code also tells Claude when a file it read earlier has changed on disk, so it knows to read it again.
Q: Does the IDE integration reduce the need for CLAUDE.md? No. CLAUDE.md holds the conventions both environments share. The IDE benefits from it just as much as the terminal, especially when you ask the agent to work on new areas of the codebase.
Q: Can I use the IDE plugin without paying for a Claude plan? No. The extension and the plugin need a paid Claude plan (Pro, Max, Team or Enterprise) or a Claude Console account with API credits; companies can also connect them to a cloud provider such as Amazon Bedrock. The integration itself costs nothing extra beyond that usage.
Test yourself
Your side project's authentication system needs a major refactor: move from JWT-based sessions to opaque tokens stored in Redis, update the backend API and middleware, and adapt the frontend login form. You have an hour before a demo. How do you divide work between the terminal agent and the IDE?
Answer: Start in the terminal in plan mode to scope the changes: let the agent inspect the auth middleware, the API handlers and the current token code, and review its plan. Approve it with auto mode (or, if you prefer acceptEdits, allow the test command with a rule so the loop is not stopped by prompts) and let the terminal agent carry out the backend refactor: token generation, Redis integration, middleware, and the existing auth tests. While it works, open the login form in the IDE, select the submit handler, and ask Claude Code in the editor to adapt it to the new token format, reviewing each diff as it comes. Use the IDE's diagnostics to catch mismatches between the new API response and the frontend types. If backend tests fail, go back to the terminal and let the agent iterate. Finish by running the full integration suite in the terminal.
If you want this kind of breakdown every week, how real systems actually work under the hood, subscribe to Internals Decoded at internalsdecoded.com.
Sources
- Use Claude Code in VS Code
- JetBrains IDEs
- Choose a permission mode
- Configure the sandboxed Bash tool
- Manage sessions
- Create custom subagents
- Plugins overview
- Orchestrate teams of Claude Code sessions
