I found Claude Code by accident.
I was already in VS Code, working on something unrelated, when I noticed there was a Claude panel I hadn't paid much attention to. I opened it. I asked it a question. I watched it edit a file in my project, run a test, suggest a fix. By the end of that afternoon I'd shipped a working feature. By the end of that week I was doing real work in it daily.
Then I went looking for tutorials, and almost every one of them assumed I was using the terminal version — claude typed at a shell prompt, working in some directory, no IDE in sight. The tutorials referenced slash commands, skills, MCP servers, settings files. They showed ~/.claude/ paths. I had no idea whether any of it applied to me.
For about a week I wasn't sure if I was using the same product everyone was talking about, or some stripped-down VS Code preview that happened to share a name.
Here's what I figured out.
Same Engine, Different Cabin
Claude Code is one product. It runs as a process on your machine, identical regardless of where it was launched from. The terminal version, the VS Code extension, the JetBrains plugin, the web client at claude.ai/code — all four are the same Claude Code, hosted by different shells.
The shell does two things. First, it provides the I/O surface — how you type at it, how output appears, what shortcuts the host claims for itself. Second, it can layer in context the host knows about — your cursor position, what file you have open, what code you've highlighted. The VS Code extension does both. The terminal CLI does the first only, but in a way that rewards a different working mode.
The engine — model, tools, skills, slash commands, MCP servers, configuration, memory — lives in the Claude Code process. Same engine across all hosts. Different cabins around it.
The proof is sitting in your home directory. Open ~/.claude/ and look around. You'll see folders for commands/, plugins/, projects/, a settings.json, a CLAUDE.md. Those files are read by Claude Code at startup regardless of which host launched it. The slash commands you wrote for the terminal work identically in the VS Code panel. The skills you install apply to both. The brain you import via @-references loads everywhere. There is no second copy of any of this for the IDE.
The literal proof, if you want to be precise: when Claude is running inside the VS Code extension, it knows. Its system prompt contains an explicit "you are running inside a VSCode native extension environment" section, with rendering rules and IDE-context conventions baked in. Same Claude, different cabin — and Claude is aware of which cabin it's in.
What VS Code Adds
The IDE knows things the terminal doesn't, and the extension feeds them in.
It tells Claude when you open a file. So if you've just opened server.py and you ask "what does this do?", Claude doesn't have to guess what this is. The opened-file notification arrived before your message did.
It tells Claude what you've selected. Highlight a function, ask "simplify this," and Claude already has the function in context as a structured selection. The terminal version would need you to paste it.
It renders Claude's output as live markdown — which means file paths Claude mentions become clickable links that jump to the file at the line number it cited. A reference like server.py:108 becomes a one-click hop. In a terminal, the same reference is flat text.
These aren't features the terminal is missing. They're features the editor is granting. The terminal CLI doesn't get them because there's no IDE there to grant them.
What The Terminal Adds
The terminal rewards a different working mode.
Status-line glanceability. The bottom of your terminal can show you state — current branch, dispatch count, session info — persistently while you keep typing. The VS Code panel doesn't have that real estate without making you context-switch to a different chrome.
Raw keybinding power. The terminal owns its keystrokes. Multi-key chord shortcuts work cleanly. The VS Code host claims many chords for itself before Claude can see them, so the keybindings.json file matters more in terminal than in the IDE.
Scriptability. claude -p "do this thing" > result.txt for one-shot dispatches you can run from a Makefile, a CI step, a cron job, or another Claude. The VS Code chat panel is interactive-only; you can't pipe it into anything.
Lower startup overhead. The terminal version doesn't carry the editor's process weight. If you spin up many Claude sessions across many projects in a day, that adds up.
When To Pick Which
The choice isn't capability — they have the same capabilities — it's workstyle.
Pick VS Code when you're inhabiting a single project. You want the editor's view of your code to be the same view Claude has. You want clickable navigation. You want the chat next to the lines you're talking about. You're not orchestrating across many things; you're working in one thing.
Pick the terminal when you're orchestrating. You want low-overhead startup. You want a status line. You want to script Claude into pipelines and recurring jobs. You're crossing many projects in a day, not living inside one.
Some days I want both in the same hour, for different work. They share the same brain, the same skills, the same configuration. Switching cabins doesn't lose state — they're reading from the same files.
The Meta Frame
The mental block that trapped me for a week — and traps a lot of people — is treating different hosts as different products. The naming overlap makes it worse. Claude, Claude Code, Claude Code CLI, Claude in VS Code, Claude Desktop — these phrases all sound like they could be separate things, and the marketing is still catching up to the reality.
The reality is simpler than the names imply: there is one product called Claude Code. It runs in different chairs. The chairs differ in what context they pull in and what shortcuts they claim, but the engine you're talking to is the same engine. Anything you learn from a terminal-focused tutorial works in the IDE. Anything you learn from an IDE-focused tutorial works in the terminal. Skills are skills, slash commands are slash commands, the brain is the brain.
If a tutorial shows you something that doesn't work for you, it's almost never because the feature is missing. It's because the host you're sitting in handles that thing slightly differently — keybindings get intercepted, output renders differently, status line lives somewhere else. Look at the host layer before you conclude you're using a different product.
You're not. You're sitting in a different chair, in front of the same workshop.
Related: Six Claudes walk into your terminal — the higher-level surface map across the whole Claude family. Same engine, different cabin zooms into the Claude Code slice of that map.