The Windows setup, under the microscope.

The steps, re-examined

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

The editor route — VS Code as your agent cockpit

The main guide is terminal-first because every agent ships its CLI first and best. But many people work better in a code editor with a file tree, inline diffs, and a chat pane on the side. Here is the honest, fully-detailed editor path — install commands, which extensions actually help, what it gives you, what it costs, and when to pick it over (or alongside) the terminal.

• winget (Microsoft-signed, recommended): winget install Microsoft.VisualStudioCode
• Or download from code.visualstudio.com — pick the User Installer so you don't need admin rights.
• Privacy-conscious alternative: VSCodium — the same editor, MIT-licensed binary, no Microsoft telemetry. Most extensions work; the Microsoft-published Remote-* family is the notable exception (license-restricted to Microsoft's own VS Code build).
• Quick first launch: open Windows Terminal, run code . in any project folder — that's the workflow you'll use most.

• 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 and a chat pane that shares the CLI's session. 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: $10/mo individual, free for verified students and open-source maintainers.
• Cline (formerly Claude Dev) — agentic coding inside VS Code; bring your own key (Anthropic, OpenRouter, OpenAI, or a local Ollama endpoint). The closest in-editor analog to Claude Code's autonomous mode.
• Continue — open-source, bring-your-own-model, deeply configurable; the right pick if you want to point at a local Ollama model and stay off the cloud entirely.
• Codex VS Code extension (OpenAI, official) — if you're already paying for Codex or ChatGPT, this surfaces it inside the editor.
• Gemini Code Assist (Google, official) — Google's editor agent; generous free tier still available as of May 2026.

• Sign in once per extension. Each uses its own auth flow — prefer the browser login over pasting API keys (no key on disk).
• 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. This is the same hygiene as the CLI permissions in Part 5.
• Turn on Settings Sync (built-in, signed in with GitHub or Microsoft) so your extension list and settings follow you between machines.
• WSL or Remote-SSH — the killer feature on Windows: install the official Remote Development extension pack, then "Reopen Folder in WSL" or "Connect to Host…". The editor lives on Windows; the agent and files live on the Linux side or remote box. This is the cleanest way to do serious work in WSL2 from a Windows desktop.

• You see diffs visually. When the agent says "I changed these 7 files," you see exactly what changed before accepting.
• One window for everything: file tree, terminal, git history, debugger, AI chat, and a marketplace of extensions for every language.
• Inline autocomplete — Copilot in particular — lowers friction on routine code in a way no CLI can. Half your typing finishes itself.
• Remote-SSH is genuinely a superpower. Edit code on the droplet or NAS from your laptop as if it were local, with the agent running on the remote box.
• 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 — Markdown preview, REST client, mermaid diagrams, GitLens, every linter and language server. The AI extensions inherit all of it.

• It's heavier. 500 MB–1 GB RAM at idle before you even open a project. The terminal CLI is a few hundred KB.
• 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. If you want the bleeding edge, the terminal wins.
• Telemetry, by default. Microsoft VS Code reports usage data; each AI extension reports its own. Switch to VSCodium and tighten telemetry.telemetryLevel if that matters.
• Extension supply-chain risk. A malicious extension can read every file in your workspace and send it anywhere. Stick to publisher-verified extensions with millions of installs; review what permissions each requests.
• Context bloat. An editor with fourteen extensions can make the AI slower and noisier — each one competes for context and CPU. Keep your extension list short.
• It's not designed AI-first. See next bullet — Cursor and Windsurf are VS Code forks that are. If you want the editor experience and aren't deep into VS Code already, those are arguably the better choice and have first-class agent integration baked in.

• Stay terminal-only if: you live in Windows Terminal/tmux, you want every new agent feature the day it ships, the machine is RAM-tight, or you prefer composable Unix-style tools.
• Use VS Code if: you already use it for non-AI work, you want visual diffs, you do a lot of multi-file refactors, or you're working over SSH/WSL against another box.
• Use Cursor or Windsurf if: you want the editor experience and care most about how good the AI feels, not how broad the editor ecosystem is. Both run on Windows; both are full VS Code forks so your extensions mostly carry over (winget install Anysphere.Cursor).
• Use both: the common pattern — long agentic jobs in the terminal, small edits and code review in the editor, both pointed at the same project folder.

What we left out — and why

The guide is deliberately a clean six-step spine. That clarity has a cost: real omissions. 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:

• 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 the install — the part most guides skip

You're installing tools that can read your files, run commands, and reach the internet, plus a private network and a local model server. That's a lot of power. Here's how to keep it from biting you — Windows specifics first, then universal rules.

• 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 login flow (no key on disk) where you can.
• Store any keys in the Windows Credential Manager or environment variables, never in plaintext in a repo.
• Rotate a key the moment you suspect it leaked; give helpers their own keys, never yours.

• 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 machine; only loosen once you trust the workflow. Don't run "auto/yolo" modes in a folder full of irreplaceable files.
• Work inside a project folder, not your whole C: drive — limit what the agent can even see.

• npm install -g and irm … | iex 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.
• winget packages are signed by Microsoft — prefer them when offered.
• Keep everything updated (winget upgrade --all, npm update -g); most agent fixes ship fast.

• Ollama: setting OLLAMA_HOST=0.0.0.0:11434 exposes your model server to the network. Only do this behind Tailscale — never on a public IP or open Wi-Fi. There's no password on Ollama by default.
• 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.

• Run as a standard user for daily work; elevate only when installing.
• Leave Defender + SmartScreen on; turn on BitLocker so keys and code at rest are encrypted if the machine is lost.
• Keep WSL2 patched (wsl --update) — it's a second OS with its own attack surface.