The cloud setup, under the microscope.

The blocks, re-examined

The guide is three self-contained blocks, not a six-step spine. Each made one choice for clarity. Here's the reasoning and the roads not taken.

The editor route — cloud-native dev environments

In the cloud the editor question splits in a way it doesn't anywhere else: you can bring the editor (your laptop's VS Code talks to the cloud VM over Remote-SSH), or you can buy the editor as a service (GitHub Codespaces, GitPod, etc. — full IDE in a browser tab, billed by the minute). Both work; they trade ownership for convenience and add a new failure mode the other OS guides don't have: the bill. Here's the honest breakdown of every path that's still alive in May 2026.

• Path A — VS Code on your laptop + Remote-SSH into the cloud VM. The Linux-guide pattern, lifted to the cloud. Install VS Code locally, install the Remote Development extension pack, Connect to Host… the cloud VM's IP (or Tailscale name). The cloud bill stays at "one VM-hour"; you don't pay extra for the editor.
• Path B — GitHub Codespaces. The cloud-native fully-managed answer: GitHub spins up a Linux box, runs full VS Code in your browser against it, persists it between sessions. Real terminal, real extensions, real Copilot, no local install. Bills per active minute; auto-stops when idle. Locks you to GitHub.
• Path C — code-server inside the cloud VM you already pay for. Run code-server on the same VM as your agents, reach it in a browser over Tailscale. You're already paying for the VM-hour; the editor adds no new bill. You own everything.
• Path D — GitPod, AWS / Google / JetBrains cloud editors. Same idea as Codespaces, different vendor. GitPod is the strongest non-GitHub option; the major-cloud editors come and go (AWS Cloud9 was deprecated in 2024; Google Cloud Workstations and JetBrains Space are still alive). Niche unless your shop standardizes on one.

• Open SSH on the VM — already done if you followed Block 1. Use SSH key auth and a non-root user (see Part 2 and Part 5).
• Install VS Code on your laptop + the official Remote Development extension pack. Add the VM to your ~/.ssh/config for one-click connect.
• If the VM is behind Tailscale (recommended), connect by tailnet hostname — no public SSH needed.
• Open a real project folder on the VM. Every AI extension scopes context to the open workspace.

• Open any GitHub repo → Code → Codespaces → Create codespace on main. A full VS Code in a tab boots in 30–60 seconds.
• Set the machine size in your account's Codespaces settings — 2-core is plenty for most work; bigger costs more per minute. Cap your monthly spend in Billing → Spending limits before you start.
• Set "Default idle timeout" to 30 min (or shorter) in Codespaces settings — the single most important step to prevent runaway billing.
• Install Copilot, Cline, or Claude Code for VS Code from the extensions panel; they work normally because Codespaces is a real VS Code.
• Add .devcontainer/devcontainer.json to your repo to pin the toolchain, extensions, and post-create scripts — your next codespace boots into a configured environment, not a blank Linux.

• SSH into the VM, install code-server: curl -fsSL https://code-server.dev/install.sh | sh.
• Bind to 127.0.0.1:8080, not 0.0.0.0: edit ~/.config/code-server/config.yaml and set bind-addr: 127.0.0.1:8080.
• Reach it over Tailscale only. Open http://your-vm-tailnet-name:8080 from a tailnet device. Never publish 8080 with a public name; never put it behind a cloud reverse proxy with a public address.
• Run it as a non-root user. Enable as a user systemd service (systemctl --user enable --now code-server); never as root.
• Install Cline, Continue, or Claude Code for VS Code from the extensions panel — code-server is a full VS Code, so they work.

• Codespaces + Copilot is the most polished combo, but Copilot is a separate subscription on top of the Codespaces minutes — read your bill carefully.
• Codespaces + Claude Code for VS Code works fine; the extension talks to Anthropic's API the same way your laptop would. Your Anthropic bill stays separate from the GitHub bill.
• code-server + Cline pointed at OpenRouter or Bedrock is the cleanest "your cloud, your bill" setup — Cline uses the cloud account you set up in Block 2, so models, compute, and storage all hit one cloud invoice.
• Don't run the heavy local-model loop inside Codespaces. A 2-core codespace is not where you want a 70B-parameter model to live; put Ollama on a GPU instance from Block 3 instead.

• Zero local install. Codespaces and code-server let you start a new project from any browser anywhere.
• Per-project environments. Each repo can have its own pinned toolchain (devcontainer.json) — no more "works on my laptop."
• Spin up and tear down at will. A bug-bash session on a heavy VM costs $0.50 if you remember to stop it; same on Codespaces, billed by the minute.
• Real AI inside, not a sandboxed web build. Codespaces and code-server both run full VS Code extensions; Copilot, Cline, Claude Code all work properly.
• Tailscale + code-server = a private cloud editor your team can share without ever exposing a port to the open internet.
• Remote-SSH is the lowest-risk on-ramp — same editor as your laptop, just pointed at a cloud box.

• The bill is a new failure mode. Every other OS analysis on this site has "RAM" as the worst-case cost; in the cloud it's dollars. A forgotten Codespace at $0.18/hour costs $130/month if left running 24/7. Set idle timeouts and spending caps before doing anything else.
• Vendor lock-in by design. Codespaces ties to GitHub; GitPod ties to GitPod; AWS / GCP cloud editors tie to those clouds. Path A and Path C are the portable answers.
• Latency depends on region. A Codespace in us-east from Hot Springs is fine; from Lisbon it's noticeable. code-server in your own VM lets you pick the region.
• Data residency. Your code is in someone else's data center. For private repos that's fine; for regulated work it's a real conversation with legal.
• Extension supply-chain risk is bigger in the cloud — a malicious extension in a Codespace can read everything the Codespace can read, including any cloud credentials baked into the dev container.
• Cold starts. Codespaces takes 30–60 seconds to boot from cold; code-server is instant once the VM is running but you still pay for VM uptime.
• It's not designed AI-first. Cursor and Windsurf don't have a "Cursor Codespaces" offering yet — if you want editor-first AI in the cloud, you mostly run Cursor on your laptop and Remote-SSH into the cloud VM (Path A).

• Stay terminal-only inside the VM if: the work is mostly autonomous agent runs and you want the cheapest, simplest, most defensible cloud bill. Most agent-heavy workflows don't need an editor at all.
• Use Path A (Remote-SSH from your laptop) if: you already pay for a VM and want one editor that follows you between local and cloud projects. The most portable, lowest-bill option.
• Use Codespaces if: the project is already on GitHub, you want zero-setup onboarding for collaborators, or you're working from a Chromebook / iPad / locked-down work machine. Watch the bill.
• Use code-server in your VM if: you want Codespaces' UX without GitHub lock-in, or your work is on a private cloud (Bedrock, Vertex) where Codespaces would add a third invoice.
• Use GitPod / cloud-vendor editors if: your team standardizes on one. Otherwise the smaller they are, the higher the risk of being deprecated like Cloud9.
• Don't: install a desktop GUI on a cloud VM just to run VS Code there. Use Remote-SSH or code-server instead — never X11 over the internet.

What we left out — and why

The guide is deliberately three clean blocks. That clarity has a cost: real omissions — and in the cloud, the omissions are mostly the things that protect your wallet and your data. Here they are, honestly, with the reason each was cut.

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 on Windows (most happiest in WSL2).

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:

• The cloud is where these models actually live. Specialized models like Mythos are hosted on managed backends — Vertex AI and Bedrock — and heavy security analysis runs at scale on cloud compute, not a laptop. So cloud readiness (IAM, budgets, MCP wired to your repos) is the most direct path to using Mythos-class models the moment access opens. The blocks on this very page are the on-ramp.
• 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.

Securing cloud compute — the part most guides skip

In the cloud you're renting machines that bill by the hour, holding credentials that can spend money, and exposing services to the public internet by default. That's a lot of ways to get hurt. Here's how to keep it from biting you — cloud specifics first, then the universal rules that apply everywhere.

• The most common cloud "incident" is a runaway bill, not a breach. Before you launch anything, go into the provider console and set a budget alert and, where available, a spending cap — so you're emailed (or cut off) long before a forgotten GPU or a misconfigured loop becomes a four-figure surprise.
• This is the single highest-value habit on the whole topic. Do it on day one, on every account, before the first VM.

• Don't use root / owner credentials for daily work. Create a normal user (or service account) with only the permissions the job needs. Owner-level keys turn one leak into a total account takeover — including the ability to rack up bills.
• Give helpers and tools their own scoped identities, never your master credentials.

• Never open SSH (port 22) or Ollama (port 11434) to 0.0.0.0 — that's the whole internet. The provider's default firewall is often more open than you'd want; tighten it.
• Put the VM on Tailscale and reach it over the tailnet, then close the public ports entirely. The machine becomes invisible to internet scanners while staying fully reachable to you. There's no password on Ollama by default — exposing 11434 publicly is handing your model server to anyone.

• The guide's export … env vars are fine to learn with, but a key sitting in plaintext on the box leaks the moment that box is compromised or the shell history is read.
• Store keys in the cloud's secret manager — Secret Manager (GCP), Secrets Manager / Parameter Store (AWS), Key Vault (Azure). Encrypted, access-audited, rotatable without redeploying.

• When a GPU job is done, destroy the instance, not merely stop it. On many GPU clouds a "stopped" instance keeps its storage and can keep charging — and a parked machine is still attack surface.
• Destroying it both stops the meter and removes one more thing that can be broken into. Re-installing next time is a one-liner.

• Turn on encryption at rest for your disks/volumes (most providers offer it as a checkbox) so data on a reclaimed or lost disk isn't readable.
• Understand the real tradeoff of managed backends: routing Claude Code or any agent through Bedrock / Vertex / OpenRouter means your code and prompts leave your premises and are processed in someone else's data center. Great for billing and scale — but a genuine privacy and data-residency decision, especially for client or regulated data. Decide it on purpose.

• 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. Rotate a key the moment you suspect it leaked; give helpers their own keys, never yours.
• Keep the agents on a leash. Configure Claude Code to deny reading .env files, SSH keys, .secrets, and certificates — and not to read its own config. Start in ask-before-acting mode on a new box; don't run "auto/yolo" modes in a folder full of irreplaceable files. Work inside a project folder, not the whole disk.
• Supply chain: npm install -g and curl … | sh run other people's code. Use only the exact official sources; don't paste install one-liners from random blogs or X replies. Keep everything updated.
• Ollama behind Tailscale: setting OLLAMA_HOST=0.0.0.0:11434 exposes your model server to the network — only do it behind Tailscale, never a public IP.
• 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 keep API keys off your devices entirely, behind your tailnet identity.