The reason I run Claude Code in a plain terminal instead of an IDE has nothing to do with aesthetics. It is arithmetic: the model does the heavy work on Anthropic's servers, so the only job your local tooling has is to display text and not get in the way. An IDE brings a rendering engine, extension host, and language tooling to that job. A terminal brings a text grid. When you run one AI session, the difference is comfort. When you run three or four in parallel — which is my normal working state — the difference decides whether your laptop stays usable.
Ghostty is the terminal I settled on for this after trying the IDE extensions, the desktop app, and the usual terminal suspects. Here is the workflow, with numbers from my own machine rather than vibes.

The Numbers, Measured on My Mac
While drafting this update I pulled the process list on my MacBook Pro (M3 Pro, 18 GB RAM) during an ordinary working session. What was running:
- Ghostty itself: about 24 MB of resident memory — hosting everything below.
- Three concurrent Claude Code CLI sessions: roughly 230 MB, 230 MB, and 500 MB each, the big one mid-task on a heavy job.
- VS Code, sitting idle in the background: about 1.3 GB across twenty-six helper processes, doing nothing.
That is the whole argument in three lines. The terminal hosting three live AI sessions costs less memory than a single idle editor window's smallest helper process. The Claude sessions themselves cost what they cost wherever you run them — the variable you control is everything wrapped around them, and Ghostty's wrapper is close to free. Scale that to five or eight projects and the IDE route turns a fast laptop into a space heater while the terminal route does not register.
Ghostty gets its efficiency honestly: it is a native, GPU-accelerated terminal written by Mitchell Hashimoto (the Vagrant and Terraform creator), not an Electron shell. Input latency is imperceptible, and scrolling through thousands of lines of agent output never stutters — which matters more than it sounds once reviewing long diffs in the terminal becomes your main reading activity.
There is also a strange 2026 footnote that says something about the author's standards: Hashimoto pulled the Ghostty project off GitHub over reliability concerns in April. Whatever you think of the decision, the person maintaining your terminal caring that much about infrastructure dependability is the right kind of obsessive.
Why CLI-First Beats Extensions Anyway
Even ignoring resources, three things keep me on the CLI:
Features land there first. Claude Code's terminal client is the reference implementation; wrapper integrations trail it. Every notable capability I use daily appeared in the CLI before anywhere else.
It forces better prompting. With no GUI affordances to lean on, you learn to front-load context — what file, what constraint, what done-looks-like. That habit alone improved my results more than any tool choice.
Sessions are cheap, so parallelism becomes the default. When another session costs a keystroke and ~250 MB, you stop thinking of Claude as one assistant you wait on and start thinking in terms of a small team you orchestrate. That mental shift, more than speed, is what changed how I build. I have compared this honestly against the Claude desktop app — the desktop client is genuinely good for non-code work, but for parallel engineering sessions the terminal wins on density alone.
The Ten-Minute Setup
- Install Ghostty from ghostty.org — drag to Applications on macOS.
- Install Claude Code:
npm install -g @anthropic-ai/claude-code, then runclaudeonce to authenticate. - Configure Ghostty — and here is a genuinely underrated point: I barely have. My config is nearly the shipped template, because the defaults are actually good. If you want the classics:
theme = catppuccin-mocha
font-family = JetBrains Mono
font-size = 14
- Learn four keybindings:
Cmd+Dsplit right,Cmd+Shift+Dsplit down,Cmd+Tnew tab,Cmd+[/Cmd+]to move between splits. They are muscle memory within a day.
That resistance to fiddling is the quiet win. I have lost real days of my career to terminal configuration. Ghostty is the first one where the productive move was to stop.
The Working Layout
My standard arrangement per project: one large split running claude, one narrow split below it running the dev server or log tail. Claude edits, the server reloads, errors surface in the lower split, and I paste them straight back into the session with full stack trace. That loop — error visible to fix requested in under ten seconds — is worth more than any autocomplete.
Each additional project gets a tab: cd into the repo, claude, done. Context stays fully preserved per tab, and switching is instant. On a typical agency day I hold three to five of these: a Laravel backend, a client dashboard, an automation script, this blog.
For parallel work on the same repository, tabs alone will burn you — two sessions writing to one working tree is a conflict machine. The fix is git worktrees, one per session:
git worktree add ../project-tests feature/tests
git worktree add ../project-docs feature/docs
Each worktree gets its own tab and its own Claude session; one builds the feature while another writes tests against a separate checkout, and nothing collides until merge. I wrote up the full pattern in my worktrees-plus-parallel-agents guide — it is the single highest-leverage habit in this whole workflow.
Long-running tasks need no babysitting: kick off the refactor, switch tabs, check back. The workflow is naturally asynchronous, so I am almost never blocked on a model thinking.
Where the Terminal Is Not Enough
Honesty section. I still open an editor several times a day — for surgical manual edits, for staging complex diffs, for reading a file the way a human reads. The difference is that VS Code is now a tool I open per file (code app/Services/ContentProcessingService.php), not an environment that owns my machine. In AI-assisted development the agent types most of the code; you review, redirect, and occasionally intervene by hand. The tooling should match that ratio, and terminal-first with an editor on call matches it exactly.
Two smaller tips that took me too long to discover: claude --resume reattaches the previous session after an accidental tab close, and claude --print "prompt" > notes.md captures a one-shot answer to a file without entering the interactive UI. Both pair well with the CLI tools I keep alongside Claude Code — jq, ripgrep, gh — because an agent that lives in your shell composes with everything else that lives there. That composability is the deep reason terminal-first keeps winning for me: it is not a Claude feature, it is forty years of Unix pipe design that the extensions simply cannot inherit.
Should You Switch?
If you run one Claude session at a time inside an IDE you already love, the gain is modest — take the desktop app or extension and be happy. The switch pays for itself the day you want a second concurrent session, and compounds from there. Ten minutes of setup, four keybindings, and the parallel-agent workflow stops being something you read about and becomes your default.
Once you are running parallel sessions, the next multiplier is giving each one better capabilities — the skills I install across my own sessions are collected in the Agent Skills Marketplace, and they slot into this exact terminal workflow with a single install command.