Linux setup — analysis, alternatives & what we left out

Part 1

The steps, re-examined

Each guide step made one choice for clarity. Here's the reasoning and the roads not taken.

SSH, apt & Node — the foundation

We chose: SSH in as root@droplet, apt for system packages, and Node LTS via the official NodeSource repo.

Why: apt is built into Ubuntu/Debian — no extra installer to trust. NodeSource gives a current Node because three of the agents are npm packages and distro Node is often years stale.

Alternatives worth knowing

nvm or fnm instead of a single system-wide Node — let you switch Node versions per project and install without sudo. We skipped this to avoid an extra layer, but it matters the moment two projects need different Node versions.
NodeSource repo vs. distro packages: we used NodeSource for a modern LTS. The distro's own nodejs package is simpler but usually too old for the agents — a real tradeoff, not a no-brainer.
dnf / pacman on non-Debian distros — if you're on Fedora/RHEL it's sudo dnf install, on Arch sudo pacman -S. Same idea, different package manager; the guide assumes apt.
The curl … | bash installers vs. native packages — several tools here (Node setup, Tailscale, Ollama, the Claude native installer) are one-line pipe-to-shell scripts. Convenient, but you're executing remote code as you fetch it; where a signed apt/dnf package exists, it's the more auditable path.

2–4

The three agents (Claude Code · Codex · Gemini)

We chose: npm global installs of each, with the headless URL-login flow.

Why: one consistent install method across every OS, easy to teach — and the print-a-link login is exactly what a desktop-less server needs.

Alternatives & notes (May 2026)

Claude Code now runs on Opus 4.7 (87.6% on SWE-bench Verified) with Agent Teams, Agent View, /goal workflows, and auto mode — worth turning on once you're comfortable. The native binary installer (curl -fsSL https://claude.ai/install.sh | bash) avoids needing Node at all.
Codex got a GPT-5.5 refresh that several 2026 rankings now place at #1 for raw coding — a real reason to keep it in the rotation, not just as a backup.
The browser-login URL flow is the right call on a headless server, but note: each tool prints a one-time link you open on your laptop or phone. If you're behind a corporate proxy or the link expires, re-run the login — don't paste an API key onto the server unless you have to.
All three also have VS Code extensions — and on a remote box those are arguably more useful than the editor would be on your laptop, because Remote-SSH lets your local VS Code drive the agent on the server. Covered in full as the editor route below.

✦

Hermes — the bonus 4th agent

We chose: the native one-line installer (or pip install hermes-agent).

Why: on Linux, Hermes installs natively — the installer sets up everything it needs (Python, Node, ripgrep, ffmpeg), so there's no compatibility shim to worry about.

Notes

It's model-agnostic — point it at Nous, OpenAI, Anthropic, or OpenRouter, so you can reuse an account you already have rather than adding a fifth login.
The pip path is the cleaner one if you already keep a Python environment; the curl installer is faster if you don't.

Tailscale — the network

We chose: Tailscale, signed-in with one account across devices, plus tailscale up --ssh on the server.

Why: --ssh is the quiet hero here — it lets you reach the box from any device and means you can close public SSH entirely. That's the single biggest security win in the whole guide.

Alternatives

ZeroTier and Netbird — open-source mesh-VPN competitors; Netbird is self-hostable end to end.
Raw WireGuard — maximum control, much more manual.
Cloudflare Tunnel — exposes one service publicly without opening ports; different job than Tailscale (publish vs. private mesh).
We didn't cover Tailscale ACLs in the guide — they're how you stop, say, the kids' laptop from reaching your Ollama or SSH-ing into the droplet. Covered in Security below.

Ollama — local models

We chose: Ollama + llama3.2 as a safe first model, with a systemd override to expose it across the tailnet.

Alternatives & better models

LM Studio (friendly app window), Jan (open-source offline ChatGPT), llama.cpp/llamafile (lower-level) — all run local models; though on a headless server, terminal-native Ollama is the natural fit.
Better models to pull now: qwen3-family (Qwen 3.6 is a standout for coding, with MCP-native tool use and huge context), deepseek-r1 for reasoning, gemma3 for small/fast. llama3.2 is a gentle starting point, not the ceiling.
The systemd override matters — and so does GPU. Editing ollama.service to listen on 0.0.0.0 is how you share it across the tailnet, but it also exposes a server with no password (see Security). And most cheap droplets have no GPU, so keep models small there; for real speed, GPU drivers (NVIDIA/CUDA) on a home box or GPU cloud do the heavy lifting.

⚠The big one: the guide connects as root@droplet. For clarity the guide SSHes in and installs everything as root. That's a real security smell — every agent, every curl … | bash, and every model server then runs with full system privileges. The better practice on any server is a non-root user with sudo: create one, install and run the agents as that user, and only elevate with sudo when you actually need to. This is the most important critique on the page — see Part 2 and Part 5.

Optional · the editor route

The editor route — VS Code on your laptop, code on the server

On a headless Linux box, running a graphical editor on the server is usually the wrong call — it adds a desktop you don't need, eats RAM, and slows the box you're paying for. The right pattern is different: run VS Code on your laptop and reach the server via Remote-SSH, so the editor lives on your desk and the agent lives on the box. Or, if you specifically want a browser-based editor on the server, code-server is the right tool. Here is the honest, fully-detailed editor path for a Linux setup.

The two real paths on Linux

Path A (the right one): VS Code on your laptop + Remote-SSH into the server. Install VS Code locally (Mac, Windows, or another Linux box), install the official Remote Development extension pack, then Connect to Host… The agent CLI keeps running on the server; your editor shows its files, terminal, and AI extensions as if they were local. This is the path the guide implicitly recommends.
Path B (when you really want browser-based on the server): code-server. A full VS Code in a browser tab, served by the Linux box itself. Install: curl -fsSL https://code-server.dev/install.sh | sh, then run it bound to 127.0.0.1 and reach it over Tailscale. Useful for a shared dev server, a Chromebook workflow, or when your "laptop" is an iPad.

Install VS Code (for the local-editor path)

Debian/Ubuntu (Microsoft repo):
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/code stable main" | sudo tee /etc/apt/sources.list.d/vscode.list
sudo apt update && sudo apt install code
Snap (any distro with snapd): sudo snap install code --classic
Fedora/RHEL: sudo dnf install code after adding the Microsoft repo at /etc/yum.repos.d/vscode.repo.
Arch: yay -S visual-studio-code-bin (AUR) or use the open-source build code-oss from the official repos.
Privacy-conscious alternative: VSCodium — same editor, MIT binary, no Microsoft telemetry. Some Microsoft-published extensions (notably Remote-*) are license-restricted to Microsoft's own VS Code build; everything else works.

Pick one or two AI extensions, not all of them

Claude Code for VS Code (Anthropic, official) — a companion to the same Claude Code you installed in the terminal, with diffs applied straight into your open files. The natural pick if Claude Code is already your driver.
GitHub Copilot + Copilot Chat — autocomplete plus a chat panel that backs onto multiple models (Claude Sonnet 4.6, GPT-5.5, Gemini 2.5 — switchable per chat). Subscription required.
Cline (formerly Claude Dev) — agentic coding inside VS Code; bring your own key (Anthropic, OpenRouter, OpenAI, or the local Ollama you installed in Step 6). The closest in-editor analog to Claude Code's autonomous mode.
Continue — open-source, bring-your-own-model, deeply configurable; the right pick for a fully-local Ollama setup with no cloud round-trip.
Codex VS Code extension (OpenAI, official) and Gemini Code Assist (Google, official) — the editor companions to the CLIs you already installed.

Five minutes to set it up well

Prefer Remote-SSH over an exposed code-server. If you do run code-server, bind it to 127.0.0.1 and reach it via Tailscale. Never publish port 8080 (or any code-server port) to the public internet.
Open a real project folder, not single files — every AI extension scopes context to the open workspace.
Lock down what extensions can read. Add .env, .git, node_modules, .secrets/, and any private folders to files.exclude in .vscode/settings.json so extensions don't index them. Same hygiene as the CLI permissions in Part 5.
Don't install the editor as root. Run VS Code (or code-server) as the non-root user the analysis page recommends — anything else inherits the very root-runs-everything problem we're trying to fix.
Turn on Settings Sync (built-in, signed in with GitHub or Microsoft) so your local extension list and settings move with you between machines.

Pros — what the editor route gives you

Remote-SSH genuinely inverts the friction — you get a real editor with diffs, debugger, language servers, and AI chat, while the agent still runs on the powerful Linux box. Best of both worlds.
You see diffs visually. When the agent says "I changed these 7 files on the server," you see the diff before accepting.
Inline autocomplete (Copilot in particular) lowers friction on routine code in a way no CLI can.
code-server unlocks browser/iPad workflows — useful when your only client device is a Chromebook or tablet.
Multi-cursor and structural refactors the agent doesn't bother with — large mechanical renames are still faster as a human editor move.
Rich extension ecosystem — language servers, GitLens, REST client, Docker, Kubernetes, every linter. The AI extensions inherit it all.

Cons — what it costs you

Running an editor on the server is usually a mistake. On a cheap droplet, code-server's RAM and CPU cost eats into what your agent and Ollama need. Reserve it for cases where you really need browser-based.
The extensions lag the CLIs. New agent features (Agent Teams, sub-agents, /goal workflows, auto mode) land in the CLI first and reach the extension weeks later. On a server especially, the CLI is the cutting edge.
Telemetry, by default. Microsoft VS Code reports usage data; each AI extension reports its own. VSCodium and a tightened telemetry.telemetryLevel are the answer if that matters.
Extension supply-chain risk. A malicious extension can read every file in your workspace — over Remote-SSH that means every file on the server. Stick to publisher-verified extensions; review what each requests.
code-server is another network service to defend. If you do run it, treat it like SSH or Ollama: Tailscale-only, never public, kept patched.
It's not designed AI-first. Cursor and Windsurf are VS Code forks that are. Both work over Remote-SSH and may be the better front-end if you want editor-first AI on a server backend.

When to pick which

Stay terminal-only if: you live in tmux on the server, want every new agent feature the day it ships, the droplet is RAM-tight, or you really do prefer composable Unix-style tools end to end. This is the path the guide recommends for a public server.
Use VS Code on your laptop + Remote-SSH if: you want visual diffs and a real editor experience without adding a desktop to the server. Probably the best blend for most people.
Use code-server on the server if: your only client device is a browser (Chromebook, iPad, locked-down work machine), or you genuinely want a shared editor multiple people can use. Otherwise, prefer Remote-SSH.
Use Cursor or Windsurf on the laptop if: you want the editor experience and care most about how the AI feels. Both work over their own Remote-SSH equivalents.
Use both: the common pattern — long agentic jobs in the server's terminal, small edits and code review in the editor on your laptop, both pointed at the same project folder.

🪟The honest take: on a remote box the terminal-first ethos is right because what you want from the server is throughput, not chrome. The editor route's real value on Linux is using your laptop's VS Code to drive the server — keeping the server lean while still getting a window with diffs. Running VS Code on a Linux desktop is fine too; running it on the same box that's serving Ollama and the agents is usually not.

Part 2

What we left out — and why

The guide is deliberately a clean six-step spine. That clarity has a cost: real omissions — and on a public server, some of them are security gaps, not just nice-to-haves. Here they are, honestly, with the reason each was cut.

Left out	What it is	Why it was cut
Hermes Agent	Nous Research's self-improving, model-agnostic coding agent	Genuinely an oversight in v1 — it's newer and niche. Now added as the bonus 4th agent. A good reminder that "the big three" isn't the whole field.
A non-root user	A regular account with `sudo` instead of working as `root`	A real omission, and the important one on a server. The guide runs as root for clarity; you should create a sudo user and run the agents as that user. See Part 5.
A firewall (ufw)	Uncomplicated Firewall — controls which ports the box accepts	Cut to keep the guide short, but a public droplet should run one: `sudo ufw allow OpenSSH && sudo ufw enable`, then close everything else (with Tailscale you can close public SSH too).
fail2ban	Bans IPs that hammer your SSH with failed logins	Deferred. On a public IP you'll see brute-force attempts within minutes; `sudo apt install fail2ban` stops the noise.
unattended-upgrades	Automatic install of security patches	Skipped for simplicity. On a server you won't babysit, auto-patching is exactly what you want: `sudo apt install unattended-upgrades`.
Git	Version control — how you save and undo real work	Installed in Step 1's basics but never taught. The moment you do serious coding you need to actually use it (`git init`, commit, push).
Python + uv	The runtime many AI tools (most MCP servers) need	Skipped to keep Node as the headline runtime. `sudo apt install python3 python3-pip` and `uv` fill the gap (Hermes' installer pulls Python in for you).
MCP servers	The standard plugs that connect agents to your files, GitHub, browser, data	The biggest conceptual omission. MCP is where the real power is going (see the tool map). The guide installs the agents; MCP is the next layer.
Docker	Containers — isolate apps and agents from the host	Cut to avoid a heavy concept early. But it's the clean way to sandbox an agent so it can't touch the whole server: `curl -fsSL https://get.docker.com \| sh`.
OpenCode	The leading open-source CLI agent (150K+ GitHub stars, LSP, multi-session)	Cut to keep the core to vendor-backed tools with simple logins. Arguably the most defensible addition — see Trending below.

🧭The pattern: we cut anything that wasn't needed to get it working fast. On a single laptop that's fine; on a public server it leaves real gaps — server hardening (non-root user, firewall, fail2ban, auto-patching) was deliberately deferred to this page, plus Git, Python, MCP, and Docker on top.

Part 3 · what the AI crowd is actually using

Trending & cool — tools worth a look

Scanning the developer conversation on X and GitHub in May 2026, here's what's hot that the guide doesn't yet mention. All run native on Linux.

OpenCode

The open-source CLI agent everyone's talking about — 150K+ stars, ~6.5M monthly devs. LSP integration, multiple parallel sessions, shareable session links. The strongest "free, bring-your-own-model" alternative to Claude Code.

Warp 2.0

A terminal that's also an agent cockpit — runs Claude Code, Codex, and others in one windowed UI with panes. Nice if the bare terminal feels stark.

Goose · OpenHands

Goose (from Block) and OpenHands are open-source autonomous agents that take a goal and run a long multi-step job. The frontier of "set it and walk away."

GitHub Spec Kit

93K+ stars. A "spec-driven development" workflow that teaches any agent (Claude Code, Copilot, Gemini, etc.) to plan before it codes. Tessl and Kiro play in the same space.

MCP servers

The plug-ins that matter: chrome-devtools-mcp (let an agent drive Chrome), filesystem, GitHub, database connectors. This is the fastest-moving, highest-leverage area right now.

Qwen 3.6-Plus (local)

An agentic open model with a 1M-token context and MCP-native tool use — a serious local option for Ollama if your hardware can handle it.

⚖️Why these aren't in the main guide: they're powerful but move fast, need more setup, or assume comfort with the basics. The guide's job is to get you to "it works." This list is your "now go further." Honorable mentions from the same conversation: Amazon Q Developer CLI, Sourcegraph Amp, Qwen Code, Crush, Plandex, Kimi CLI, Aider, Cline.

Part 4 · the next wave

Getting ready for Mythos

Mythos is Anthropic's first model specialized for one domain: defensive cybersecurity. Announced April 7 2026 as the engine of Project Glasswing, it has already found a 27-year-old vulnerability in OpenBSD and bugs in FFmpeg. It is invitation-only ($25 / $125 per million tokens), shipped to 12 founding orgs and 40+ critical-infrastructure partners — not a download. Full briefing →

So "getting ready" isn't an install — it's preparing your environment so that when domain-specialized models (Mythos and the wave behind it) open up, you can point them at something useful:

Get on MCP now. Specialized models reach your code and infrastructure through MCP. A working MCP setup today is the plug Mythos-class tools will use tomorrow.
Have your code in Git, reachable over Tailscale. A security model is only useful pointed at your systems. Repos in Git + machines on your tailnet = ready to analyze.
Tighten your own security first (Part 5). The irony: you can't safely run a vulnerability-finding model on a sloppy machine. Hardening is the prerequisite, not the reward.
Keep a clean Anthropic account & current Claude Code. Access to new models lands through the same account and tooling you already use.
Watch Glasswing. If you run anything critical (a business, rentals, client sites), the initiative is where defensive tooling will surface first.

🔭Honest take: as an individual you won't get Mythos itself soon. What you can do is build the habits — MCP, Git, a private network, a hardened machine — that make any future specialized model immediately useful. That's the real "future-proofing" (see the tool map).

Part 5 · don't skip this

Securing the install — the part most guides skip

This is the most security-critical guide in the set: a public server, reachable from the internet, running tools that can read files, execute commands, and serve a model — installed as root. That's a lot of power facing a lot of attackers. Here's how to keep it from biting you — Linux/server specifics first, then the universal rules.

⚠Real incident (Feb 2026): Check Point Research disclosed that a malicious config could redirect Claude Code's traffic via the ANTHROPIC_BASE_URL setting and exfiltrate your API key in plaintext. Anthropic patched it before disclosure — the lesson stands: keep Claude Code updated, install only from official sources, and be suspicious of any config that reroutes where a tool "phones home."

Don't run as root

Create a non-root user with sudo and do everything as them: adduser you, usermod -aG sudo you, then SSH in as you@server. Install and run the agents as that user; elevate with sudo only when a step truly needs it.
Running the agents as root means an over-eager (or compromised) agent has the keys to the whole box. A regular user contains the blast radius.

SSH — the front door

Key-only auth. Add your public key (ssh-copy-id you@server), then in /etc/ssh/sshd_config set PasswordAuthentication no and PermitRootLogin no, and reload sshd. No password = no brute-force.
Better still: close public SSH entirely. With tailscale up --ssh from the guide, you can reach the box over your tailnet from any device — then block port 22 publicly and only accept SSH over Tailscale.

Firewall, fail2ban & auto-patching

ufw: allow only what's needed — sudo ufw allow OpenSSH (or skip even that if you're Tailscale-only), then sudo ufw enable. With Tailscale you can close public ports and let tailnet traffic through.
fail2ban: sudo apt install fail2ban — bans IPs that hammer your login. Essential on any public IP.
unattended-upgrades: sudo apt install unattended-upgrades so security patches land automatically on a box you won't log into every day.

Lock down Ollama & Tailscale

Ollama: the systemd override that sets OLLAMA_HOST=0.0.0.0:11434 exposes your model server to the network with no authentication at all. Only do this behind Tailscale — never on the public IP. If ufw is open to 11434 publicly, anyone can use (and rack up load on) your server.
Tailscale ACLs: in the admin console, restrict who can reach port 11434 and who can SSH where. Turn on key expiry so a lost device drops off. Tailscale's new Aperture (alpha) can even keep API keys off your devices entirely, behind your tailnet identity.

Protect your keys & logins

Never paste API keys into files you might share or commit. Anthropic + GitHub run secret-scanning that auto-deactivates leaked Claude keys — helpful, but don't rely on it. Use the browser URL-login flow (no key on disk) where you can.
Store any keys in environment variables or a secrets manager, never in plaintext in a repo.
Rotate a key the moment you suspect it leaked; give helpers their own keys, never yours.

Keep the agents on a leash

Block agent access to secrets. Configure Claude Code's permissions to deny reading .env files, SSH keys, .secrets, and certificates — and to not read its own config (which could be used to manipulate it).
Start agents in ask-before-acting mode on a new server; only loosen once you trust the workflow. Don't run "auto/yolo" modes as root on a box with live sites or client data.
Work inside a project folder, not the whole filesystem — limit what the agent can even see.

Supply chain (the install commands themselves)

npm install -g and curl … | bash run other people's code. Only use the exact official sources in the guide; don't paste install one-liners from random blog posts or X replies.
apt/dnf packages are signed — prefer them over pipe-to-shell when both exist.
Keep everything updated (sudo apt update && sudo apt upgrade, npm update -g); most agent fixes ship fast.

✓ Good shape when: you're a non-root sudo user, SSH is key-only (or Tailscale-only with port 22 closed), ufw + fail2ban + unattended-upgrades are running, no keys in plaintext, agents can't read your secrets, Ollama is Tailscale-only, and Tailscale has ACLs + key expiry. That's a server you can hand a vulnerability-finding model without flinching.

The Linux setup, under the microscope.