What's a terminal?

The one idea that fixes everything

Every "terminal" is actually two pieces of software stacked on top of each other:

A useful analogy: the shell is the engine; the terminal is the car body around it. You can put the same engine in different bodies, or different engines in the same body. On Windows you can run cmd or PowerShell or Git Bash inside either conhost or Windows Terminal — nine combinations.

How to tell which one you're in

This is the question everyone asks first. Look at the title bar, the prompt, and one quick command.

1. Look at the title bar

The window title usually announces what's running inside. A few common ones:

• "Windows PowerShell" — the built-in Windows 5.x PowerShell, hosted in classic conhost.
• "PowerShell 7" or anything with pwsh — modern cross-platform PowerShell, usually in Windows Terminal.
• "Command Prompt" or C:\WINDOWS\system32\cmd.exe — old-school cmd, classic conhost.
• "MINGW64:/c/Users/you" — Git Bash, in its own mintty window.
• Tabs across the top — you're inside Windows Terminal (or, on Mac, iTerm2 / a tabbed Terminal.app).

2. Look at the prompt

The line waiting for your input is a giveaway:

3. Run one command to be certain

If you're still not sure, type one of these:

• On any shell that might be bash-like (Git Bash, bash, zsh): echo $SHELL
• On PowerShell: $PSVersionTable
• On cmd: ver

And to see which terminal window is hosting you, on Windows:

$env:WT_SESSION    # PowerShell — has a value only inside Windows Terminal
echo $WT_SESSION   # Git Bash / bash — same idea

If it prints a long string, you're in Windows Terminal. If it prints nothing, you're in classic conhost.

Windows: the full lineup

Windows is where the host-vs-shell distinction matters most, because Microsoft kept three of each lying around for compatibility. Here they are.

The two windows (hosts)

The shells

Which one should you actually use?

# Install both in one go (PowerShell, as you):
winget install Microsoft.WindowsTerminal
winget install Microsoft.PowerShell
winget install Git.Git

How to open a new tab on Windows

Tabs only exist if your host supports them. On Windows that means Windows Terminal.

• Inside Windows Terminal: Ctrl+Shift+T — new tab with the default profile.
• To pick which shell to open in the new tab: click the v arrow next to the + in the tab bar.
• Split panes (two shells in one tab, side by side): Alt+Shift+D.
• Cycle tabs: Ctrl+Tab.
• Close a tab: Ctrl+Shift+W.

In classic conhost (the old Command Prompt window), there are no tabs. The only way to get a second one is a second window: Win+R, type the shell name, Enter.

Mac: the simpler picture

macOS has one built-in terminal (Terminal.app), one popular replacement (iTerm2), and one default shell (zsh). Almost everyone has the same setup.

The Mac shell

Since Catalina (2019), zsh is the default. Before that it was bash. They're close enough that day-to-day commands (cd, ls, grep) work identically. Differences only show up in scripting and prompts.

How to open a new tab on Mac

• New tab: ⌘+T
• New split: ⌘+D (Terminal.app) or ⌘+D / ⌘+Shift+D (iTerm2)
• Cycle tabs: ⌘+Shift+] / [
• Close tab: ⌘+W

Linux: the menagerie

Linux has the most variety because nothing is built-in — every distro picks defaults, and every user replaces them. The shell picture is the same as Mac; the terminal picture is wider.

The terminals (hosts)

The shells

By far the most common on Linux:

• bash — the default almost everywhere. Battle-tested, slightly ugly, completely universal.
• zsh — bash with nicer defaults, better autocompletion, and the famous oh-my-zsh framework on top.
• fish — opinionated, friendly, modern. Different syntax, so scripts written for bash won't run unchanged.

How to open a new tab on Linux

• gnome-terminal: Ctrl+Shift+T
• konsole: Ctrl+Shift+T
• kitty: Ctrl+Shift+T
• alacritty: no native tabs — people pair it with tmux for tab-like sessions

Cloud terminals: DigitalOcean and friends

There's a fourth kind of terminal worth knowing about: the one your cloud provider hosts inside your browser. DigitalOcean has one. So do AWS, Azure, Google Cloud, GitHub Codespaces, Linode, Vultr, and Hetzner. They all work roughly the same way and they all share the same handful of pitfalls.

The model bends the host/shell idea a little:

• The "host" is your browser tab. It's a web app drawing terminal output to a canvas in real time.
• The "shell" is running on the remote server — usually bash, sometimes whichever shell that server defaults to.

Every keystroke you type travels through the network into a process on the far end. That one detail explains every quirk and limitation below.

DigitalOcean Droplet Console

The main star, since this is the one you'll meet first if you've got a droplet. To open it:

1. Sign in to cloud.digitalocean.com.
2. Click into your droplet.
3. Click the Console button (top right of the droplet page) or the "Launch Droplet Console" link.
4. A new browser tab opens with a working bash prompt on your droplet. No SSH key needed — your DigitalOcean login is the authentication.

DigitalOcean actually ships two consoles, and it's worth knowing which is which:

Pros and cons

The verdict for Claude Code

The working pattern, for the common case:

ssh root@your.droplet.ip
tmux new -s claude      # first time
claude                  # start Claude inside the tmux session

# Disconnect any time. Reconnect later from anywhere:
ssh root@your.droplet.ip
tmux attach -t claude   # same session, same state

Now your local terminal has tabs, your remote session has persistence, and the DigitalOcean console goes back to being what it's good for: emergencies and first-time setup.

The other major cloud consoles

If you use a different provider, same model, same trade-offs. Worth recognizing the names so you know what kind of thing you're looking at:

What every shell shares

Whatever you end up in, these basics work the same. Day-one literacy:

The mockup, annotated

Here's what a healthy Windows Terminal session running PowerShell 7 looks like. Note the tab bar across the top, the PS prefix on the prompt, and the version line:

And here's classic Command Prompt in old conhost — no tabs, no WT_SESSION:

Common confusions, resolved

"I typed ls and it said 'not recognized'"

You're in cmd, where the list command is dir. Or switch to PowerShell / Git Bash, where ls works.

"Ctrl+V doesn't paste"

You're in Git Bash (mintty) or old conhost. Use Shift+Insert, or right-click. In Windows Terminal, Ctrl+V works as you'd expect.

"Where did my window go? I can't find tabs."

You opened classic conhost, not Windows Terminal. They look almost identical at first. Check the title bar — if it says "Command Prompt" or "Windows PowerShell", you're in conhost. Install Windows Terminal to get tabs.

"I installed Windows Terminal but wt doesn't run"

That stub file at C:\Users\you\AppData\Local\Microsoft\WindowsApps\wt.exe exists for every Windows user even if Windows Terminal isn't installed. The fix is to actually install the app:

winget install Microsoft.WindowsTerminal

"PowerShell complains 'cannot be loaded because running scripts is disabled'"

The execution policy is blocking a script. The standard fix (run once, in an admin PowerShell):

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

"My commands look right but nothing prints"

You probably forgot to press Enter. Or the command genuinely produced no output (many Unix commands stay quiet on success). Try one that always prints, like echo hello, to confirm the shell is alive.

Where to go next

You don't need any of these on day one. Reach for them when you outgrow the basics.

Bottom line — pros and cons for Claude

You've met every terminal there is. So which one should you actually run claude inside? Strip the question down and one criterion swamps the rest:

Why tabs matter so much for Claude

Claude Code is a back-and-forth that often runs for many minutes at a stretch. You keep wanting a second shell open next to Claude. Three concrete patterns you'll hit on day one:

1. The "let me peek" pattern. Claude is editing a file across ten turns. You want to cat the current state, check git status, glance at a log — without interrupting Claude. Open a second tab. Done.
2. The "second project" pattern. You start claude in ~/projects/A. A question pops up about project B. New tab, cd ~/projects/B, fresh claude, no context-mixing.
3. The "watch the work" pattern. Claude kicks off a build, deploy, or long script. You want to keep typing other things, or tail a log, or hit an HTTP endpoint to see how it's responding. Tabs (or splits) make that a one-keystroke move; a single window makes it a juggling act.

None of these are technically impossible without tabs — you can always open a second window. But two unrelated windows for the same task is friction. Tabs are the right shape for how Claude Code actually feels.

Windows — the verdict

Mac — the verdict

Linux — the verdict

The single best setup, by OS

If you remember nothing else from this page:

Whichever path you pick, you end up in the same place: a window with tabs, a shell you trust, and claude one keystroke away.

One idea, one window, one shell.

Once you know which window you're in and which shell is running inside it, every "weird terminal thing" stops being weird.