Overview & Prerequisites

By the end of this lesson, you’ll have a working Node.js environment and understand how API keys work — the two things every CLI tool in this module depends on.

What you’re about to install

In the next four lessons, you’ll install and try each of the major LLM CLI tools:

You don’t need to install all of them. But we recommend trying at least two — each has different strengths, and knowing multiple tools makes you a more flexible orchestrator.

Why Linux?

If you’re on a Windows machine — especially in a Windows-centric organization — you might wonder why this course keeps pointing toward Linux and WSL. Fair question. Here’s the direct answer:

These tools were built for Linux first. Claude Code, Gemini CLI, and Codex CLI originated on Linux and macOS. Their plugin ecosystems, sandboxing features, and community tooling assume a Unix-like shell. Windows-native support has matured significantly in early 2026 (see the table below), but the ecosystem still leans Linux — docs are Linux-first, community answers assume bash, and most tutorials assume a Unix shell.

Industry at scale runs Linux. Netflix, Amazon, Google, every major cloud provider, most CI/CD pipelines, and the vast majority of production servers run Linux. The agentic CLI tools are built by and for people in that ecosystem. This is not niche — it is the mainstream of modern software infrastructure.

WSL is Microsoft’s own answer to this reality. Windows Subsystem for Linux is not a workaround or a hack. Microsoft built WSL2 because they recognized that developers need Linux tooling. It ships with Windows, runs a real Linux kernel, and integrates seamlessly with VS Code. Using WSL is not “leaving Windows” — it is using Windows the way Microsoft designed it for development work.

Learning Linux fundamentals is a career investment. Even if your day job is Windows-only today, the commands you learn here (bash, ssh, git, npm) transfer to cloud environments, CI/CD pipelines, Docker containers, and server administration. These are durable skills, not a detour.

Windows Native vs WSL

As of early 2026, some tools now offer Windows-native support. Here’s the current state:

Our recommendation: use WSL. Not because Windows-native doesn’t work, but because WSL gives you a consistent environment across all four tools, matches the commands in every tutorial you’ll find online, and builds transferable Linux skills. If you already have WSL set up from Module 3, stay in it.

Windows-native is a viable fallback if WSL isn’t an option (corporate lockdown, IT policy, personal preference). Each tool lesson below notes the Windows-native path where applicable.

Prerequisites

In this course, we use Node.js Node.js A platform that runs JavaScript outside the browser. Learn more → -based install paths for all CLI tools, so Node.js is required for this module. Node.js is a platform that lets JavaScript run outside the browser — it powers the installer ( npm npm Node Package Manager — installs JavaScript tools and libraries. Learn more → ) that these CLI tools use.

Preflight check

Before installing anything, let’s make sure your environment can reach the tools you need. Run each of these:

# Can you reach the npm registry?
curl -s https://registry.npmjs.org/ | head -c 100

# Do you have git?
git --version

# What shell are you in?
echo $SHELL

If curl is not installed, run sudo apt install curl (Linux/WSL) or brew install curl (macOS). If curl to the npm registry fails, you may be behind a corporate proxy or firewall — see the troubleshooting section at the bottom of this lesson.

Check if you already have Node.js

If you completed Module 3, you may already have Node.js installed. Let’s check:

node --version

If you see something like v20.11.0 or higher, you’re good — skip to the “API Keys” section below.

If you see “command not found” or a version below v18, install it using the method below. If you skipped Module 3, don’t worry — we’ll walk through it now.

Installing Node.js with nvm (recommended)

nvm (Node Version Manager) is the best way to install Node.js because:

• It doesn’t require sudo or admin rights
• It installs Node in your home directory (no permission issues)
• You can easily switch between Node versions later

This works on macOS, Linux, and WSL:

# Install nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

# Reload your shell config
# bash users:
source ~/.bashrc
# zsh users (macOS default):
source ~/.zshrc

# Install the latest LTS version of Node.js
nvm install --lts

# Verify
node --version
npm --version

Both should print version numbers. You’re ready.

Alternative: Direct install (if nvm doesn’t work)

If you can’t use nvm (corporate restrictions, etc.):

macOS with Homebrew:

brew install node

Ubuntu/Debian (WSL or server):

sudo apt update && sudo apt install -y nodejs npm
node --version

After installing, check the version with node --version. The default Ubuntu repositories often contain older versions of Node.js. If apt installs a version lower than v18, download the LTS version directly from nodejs.org or use the NodeSource repository instead.

Or download from nodejs.org — grab the LTS version.

What’s npx?

You’ll see npx in some installation instructions. The difference:

• npm install -g tool — downloads and permanently installs a tool
• npx tool — downloads and runs a tool temporarily

For CLI tools you’ll use regularly, npm install -g is better so you don’t re-download every time.

API keys — what they are and how to handle them

Most AI CLI tools require an API Key API Key A secret string that authenticates your account with an AI service. Learn more → — a secret string that identifies your account and lets the tool talk to the AI service. You’ll get this from each provider’s website.

Key safety rules

• Never share your API key with anyone
• Never paste it into a public chat, email, or code repository
• Never put it in a file that gets committed to git (add .env to your .gitignore)
• If you accidentally expose a key, revoke it immediately from the provider’s dashboard

Storing keys safely

Most CLI tools store your key in a local config file automatically. But if you need to set one manually:

# Set for your current session
export ANTHROPIC_API_KEY="sk-ant-your-key-here"

# Make it permanent (add to your shell config)
# bash users:
echo 'export ANTHROPIC_API_KEY="sk-ant-your-key-here"' >> ~/.bashrc
source ~/.bashrc
# zsh users (macOS default):
echo 'export ANTHROPIC_API_KEY="sk-ant-your-key-here"' >> ~/.zshrc
source ~/.zshrc

Authentication over SSH (the browser problem)

Some tools (like claude or gh auth login) want to open a web browser for authentication. If you’re SSH’d into a remote server, there’s no browser to open. Solutions:

1. Device flow: Some tools show a URL and a code. Open the URL on your local machine’s browser, enter the code, and the remote tool gets authenticated.
2. API key directly: Set the API key as an environment variable before starting the tool — this bypasses browser-based auth entirely.
3. Authenticate locally first, then copy: Run the tool on your local machine to authenticate, then copy the generated config file to your remote server (usually in ~/.config/ or a tool-specific directory). This works for some tools only — prefer device flow or API key env vars unless the tool’s docs explicitly support config-file transfer.

Each tool lesson will cover authentication specifically.

Troubleshooting: Proxy and network issues

If you’re on a university network, corporate VPN, or government network, you may hit issues with SSL certificates or blocked registries.

Symptom: npm install fails with certificate errors

error SELF_SIGNED_CERT_IN_CHAIN

This usually means your network is doing SSL inspection. Fixes:

# Option 1: Tell npm to use your system's certificate bundle
npm config set cafile /etc/ssl/certs/ca-certificates.crt

# Option 2: If you have a specific corporate cert file
npm config set cafile /path/to/your/corporate-ca.pem

# Option 3 (last resort, NOT recommended for production):
npm config set strict-ssl false

Symptom: Network timeout / can’t reach registry

Your network might require a proxy:

npm config set proxy http://proxy.example.com:8080
npm config set https-proxy http://proxy.example.com:8080

Ask your IT team for the proxy address. Or use GitHub Codespaces to bypass network restrictions entirely.

Ready?

If you can run node --version and npm --version and see version numbers, you’re set. Let’s install your first tool.

Key Takeaways

• This module’s CLI tools use Node.js install paths — install it with nvm to avoid permission headaches
• API keys are passwords — never commit them to git, never share them publicly
• Network restrictions are common on university and government networks — know how to configure proxies and certificates
• You don’t need every tool — try at least two and pick the ones that fit your workflow
• SSH environments skip the browser — use API keys or device flow for remote authentication