AI CLI Agents Tutorial
This page is an introductory guide for UIUC economists who want to bring AI agents into real research, presentation, teaching, and learning workflows. It starts with why CLI agents are worth learning now, then covers a few concepts that make installation easier to understand, walks through several common tools, and ends with a few practical questions that often come up.
Why use them
A local agent does more than answer questions. It can read files, search code, edit source files, run commands, and explain what it changed. That makes it feel more like an engineering assistant that can help you get real work done, rather than a web chatbot that can only talk.
You no longer have to manually copy and paste code into a chat window. You can describe the task directly in the terminal and let the tool reason over the real state of the current project.
Many research tasks already map cleanly onto command-line steps: organizing files, batch-processing text, running scripts, calling APIs, checking logs, generating outputs, and exporting intermediate artifacts. If a research workflow can be broken into repeatable commands, a local CLI agent can naturally take over a large share of it.
Agents are powerful, but they are not magic. They over-edit, misread architecture, choose the wrong abstraction, and sometimes continue confidently before they have really thought things through. The healthier mindset is to treat an agent as a very fast collaborator, not as fully trustworthy autopilot.
CLI specificity
They are not a completely different technology from agents inside IDEs, editor companion plugins, or standalone assistant apps. The real difference is more about entry point, boundaries, and workflow design.
Many local assistant apps that look more polished are still doing the same basic things underneath: reading files, running commands, calling models, and showing the result inside a GUI. At the level of working principles, they are not separated from CLI agents by any hard boundary. In many cases, a standalone assistant app is just a CLI agent wrapped in another layer of UI plus some convenience interaction design.
As long as your IDE or editor can open a terminal, it can already work together with a CLI agent. The flow is simple: write code in the IDE, call the CLI agent in the terminal, and let the results land back in the current project. In many cases you do not need an extra plugin or a separate new app.
GUIs can be friendlier for beginners, occasional users, visual review, and collaboration. But an extra UI layer also means an extra layer of synchronization, state management, permissions handling, and context transfer. That is where surprising bugs often appear: stale state, path confusion, permission mismatches, or the UI drifting away from the real file state.
Research work rarely happens inside a single app. You might edit a script in your editor, run an experiment in the terminal, manipulate files, and call an API all in one session. In-app agents are naturally trapped inside their own app, which turns the human into the middleman moving context across tools. CLI agents live closer to the system layer, so they are much better at chaining tools, directories, and applications together. As noted above, they can still run seamlessly inside your IDE's built-in terminal, so they are not inherently separate from the editor environment.
Installation Guide
This section starts with a few concepts that make installation easier to understand, then walks through the installation paths for several common CLI agents. For simplicity, it uses two platform groupings: macOS/Linux and Windows. To keep the page readable, it highlights the shortest and most generally useful path for each platform, not every officially supported variant.
For people who do not write code every day, these words often sound like engineering jargon. That is fine.
A good starting intuition is to think of them as a way to operate a computer with text instead of buttons.
The most common confusion is this: terminal is itself a text interface, while bash and PowerShell are command environments that run inside it.
A shell that runs inside the terminal and interprets the commands you type.
A tool you invoke from the shell. It can further open bash sessions, read and write files, use a browser, and call APIs.
A terminal is best understood as a text interface, or a window specifically for typing commands. Instead of clicking buttons with the mouse, you type commands to make the computer do work. On macOS and Linux it is often literally called Terminal; on Windows the common entry point is Windows Terminal. Many people loosely call a PowerShell window a terminal too, but more precisely, PowerShell is a shell running inside that interface.
They are both shells, more fully command shells, which you can think of as command interpreters that understand what you type and hand it to the operating system. Bash is more common on macOS and Linux; PowerShell is the more common command environment in Windows. The right mental model is not "terminal equals bash," but "the terminal is running bash or PowerShell inside it."
CLI stands for command-line interface. It simply means that instead of clicking through a GUI, you interact with a program through typed commands. A CLI agent is an agent you can invoke from the command line.
A rough analogy helps here. Most people are already used to two software installation patterns: one is like an App Store, where you install from a unified distribution channel; the other is downloading an installer from a website and double-clicking it. CLI agent installation is not fundamentally more mysterious than that. In many cases, it is just the command-line version of those same two ideas.
Roughly speaking, npm and brew behave more like unified distribution channels in the command-line world;
curl ... | bash and irm ... | iex are closer to "fetch an install script, then execute it immediately."
Windows also has a unified distribution tool, winget, but not every CLI agent ships an official winget package.
This analogy is mainly there to build intuition; at the implementation level, these are not exactly the same as an App Store or a double-clicked installer.
npm install -g ...
npm is the package manager that comes with Node.js, a bit like pip in Python.
If a command is written as npm install -g ..., it means install the tool globally so you can call it from any directory.
If your machine does not already have node and npm, you usually need to install them first from the
Node.js website.
brew install ...
brew means Homebrew, a very common package manager on macOS and also available on some Linux environments.
If you already use Homebrew, installing CLI tools with brew install often feels cleaner and fits better with your existing machine setup.
curl ... | bash
This style of command usually means: fetch an install script from the official website, then immediately pass it to bash to execute.
Its advantage is simplicity, but you should understand that you are running a remote script. Many official CLI installers provide this option.
irm ... | iex
This is the PowerShell equivalent on Windows. irm downloads the script and iex executes it.
You can think of it as the PowerShell version of curl ... | bash.
winget install ...
winget is the Windows-side tool that comes closest to a unified package distribution entry point.
But whether you can use winget depends on whether the vendor publishes an official package; not every CLI agent does.
If you only want to install one officially supported tool, winget is often the easiest path. If you plan to try many CLI agents, installing Node.js first is usually more general.
On Windows, installing a CLI agent often has one extra layer of friction. Not because it is harder in principle,
but because documentation may switch between cmd, PowerShell, Git Bash, and WSL.
If you sort out how those environments relate to each other first, the installation commands stop looking like cryptic jargon.
This is not Windows being intentionally contrary to Bash. It is a consequence of history: Windows evolved along the path of cmd and later PowerShell,
while bash comes mainly from the Unix/Linux world. For practical use today, the important question is not which one is more "correct,"
but whether a command was written for PowerShell, Git Bash, or WSL.
cmd
This is Windows' traditional command-line environment, also called Command Prompt. It has a long history and good compatibility,
but compared with modern development workflows it feels old. Many CLI agent docs no longer use cmd as their primary example.
PowerShell
This is the more common and more modern Windows shell today. When official docs show Windows install commands, they usually mean PowerShell.
Everywhere on this page that uses irm ... | iex should be run inside PowerShell.
Git BashThis is a bash environment bundled with Git for Windows. It lets Windows users run many commands that feel closer to the macOS/Linux style. Some CLI tools work there, but it is not the same thing as a full Linux environment, so compatibility still depends on the specific tool.
They are all shells, but with different syntax, ecosystems, and compatibility. When reading install docs, first check whether the vendor means PowerShell, Git Bash, or WSL. Do not assume that a command written for one of them can be copied seamlessly into another.
WSL stands for Windows Subsystem for Linux. A practical mental model is that it opens up a Linux environment inside your Windows machine, so you can directly run many Linux commands and toolchains on Windows. If you want to install it properly, the safest reference is the official Microsoft guide: Install WSL | Microsoft Learn.
Because many development tools were designed and tested primarily for macOS and Linux. For vendors, telling Windows users to use WSL is often more stable and less costly than maintaining a fully separate native Windows compatibility layer.
For the purpose of this guide, you can approximately think of it as "now I am in a Linux environment." That means many install commands, bash commands, and developer tools written for Linux feel more natural and compatible inside WSL.
From the host machine's perspective, yes, you are still on Windows. But from the terminal and tool runtime perspective, you are now inside a Linux user space. So when documentation says "Windows users should run this in WSL," you should read the following commands as Linux commands, not PowerShell or cmd commands.
If a CLI agent explicitly recommends WSL for Windows users, the simplest mindset is: treat the next commands as Linux commands. Do not keep mentally mixing them with PowerShell, cmd, or Git Bash.
WSL is not a completely separate new machine. It is a Linux environment running inside the same Windows computer. So from inside WSL you can usually still access the Windows file system, and very often call Windows programs as well.
Inside WSL, Windows drives are usually mounted under /mnt. For example, the C drive commonly appears as /mnt/c.
So if a file is located at C:\\Users\\name\\Desktop in Windows, you can usually find it at
/mnt/c/Users/name/Desktop inside WSL.
Many Windows executables can be called directly from WSL. The most common pattern is to invoke them with the .exe suffix,
such as notepad.exe or explorer.exe. That means you can stay in a Linux workflow while still handing specific steps back to Windows programs.
You can call them too, but in that case you are launching a Windows-side command environment from inside WSL. The key beginner insight is this: "I am mainly in Linux now, but I can still jump back into the Windows world." Once you do that, though, path formats and command syntax have to be read using Windows rules again.
Treat WSL as Linux by default. Only cross back into Windows when you explicitly need Windows files, Windows apps, or a command that only runs there. That is the easiest way to avoid mixing Linux paths, PowerShell syntax, and WSL behavior into one mental mess.
CLI agents evolve quickly, and this page cannot possibly cover every variant. The safest starting point is usually to begin with a subscription you already have. For example, if you already pay for ChatGPT Plus, start with Codex CLI; if you already live in the Anthropic or GitHub ecosystem, start with Claude Code or GitHub Copilot CLI.
Codex CLI is OpenAI's terminal coding agent. It fits workflows where you want to read code, edit files, run commands, and move through tasks with an approval-oriented flow directly inside a local directory.
According to the official docs, Codex CLI currently supports macOS and Linux.
According to the official docs, Windows support is still experimental. Codex can run natively on Windows or inside WSL2, but OpenAI explicitly recommends using it in a WSL2 workspace for the best Windows experience.
npm i -g @openai/codex
codex# It also supports Homebrew
brew install codex# First enter WSL from PowerShell
wsl
# Then install inside a WSL2 workspace
npm i -g @openai/codex
codexIf Node.js is already installed, this is the most direct path. On first launch, Codex will guide you to sign in with a ChatGPT account or an OpenAI API key.
The point of this command is not “run npm natively on Windows,” but “enter WSL2 first, then read the rest as Linux commands.” OpenAI's Windows docs also explain two native Windows sandbox modes; if you want the official details, see Codex on Windows. But if your goal is simply to get it working reliably, WSL2 is usually the least painful place to start. On first launch, Codex will guide you to sign in with a ChatGPT account or an OpenAI API key.
Claude Code has one of the more mature terminal experiences in this space. Its project-level context handling, workflow design, and day-to-day coding feel are all strong.
According to the official docs, the native install script is currently the preferred path.
According to the official docs, the preferred Windows path is the PowerShell install script.
curl -fsSL https://claude.ai/install.sh | bash
claude# Run in PowerShell
irm https://claude.ai/install.ps1 | iex
claudeIf you already have Node.js or Homebrew set up, you can use an alternative install path instead.
This official script is a PowerShell command, not a cmd command.
# npm
npm install -g @anthropic-ai/claude-code
# Or Homebrew
brew install claude-code# npm is also available on Windows
npm install -g @anthropic-ai/claude-codeIf you primarily work inside WSL, you can also just follow the Linux installation path.
Gemini CLI is Google's terminal agent. It is a natural fit if you already work inside the Google account ecosystem and want to call Gemini directly from the command line.
According to the current official docs, the simplest cross-platform path is npm, so that is the default shown here.
npm install -g @google/gemini-cli
gemini# Run in PowerShell
npm install -g @google/gemini-cli
geminiOn first launch, you will usually choose Sign in with Google. If you are a student, Google often provides student offers for Google AI Pro in some regions, so quotas can be quite generous. If you already use Homebrew or another package manager, you can take an alternative path instead.
On Windows, running npm in PowerShell is usually enough. If you already work inside WSL, you can also read the setup using the Linux path. On first launch, you will usually choose Sign in with Google. If you are a student, Google often provides student offers for Google AI Pro in some regions, so quotas can be quite generous.
# Homebrew
brew install gemini-cli
# For a quick one-off trial, you can also use npx
npx https://github.com/google-gemini/gemini-cli
# The official docs also mention MacPorts, conda, and more# On Windows, npm remains the most unified path
npm install -g @google/gemini-cliIf you only want to try it once, the official docs also support running it via npx; but for long-term use, a global install is usually more stable.
More broadly, we usually do not recommend scattering attention across Google's many overlapping experimental products. If your goal is simply to get started with a stable CLI agent, Gemini CLI is the clearer place to begin.
Even though its name still says GitHub Copilot, the actual experience is not just a tiny GitHub add-on. It is a fairly full-featured CLI agent. One of its practical advantages is model choice: OpenAI, Anthropic, and Google models are all available inside the Copilot ecosystem.
According to the GitHub docs, on macOS and Linux it supports Homebrew, npm, and an official install script, making it one of the most fully documented install paths among the tools here.
According to the GitHub docs, on Windows it supports WinGet and npm, with PowerShell 6 or newer.
# Homebrew
brew install copilot-cli
# Or npm
npm install -g @github/copilot
copilot# Run in PowerShell
winget install --id GitHub.Copilot --exact
copilotIf you already use Homebrew, brew is usually the smoothest path. If you prefer a more uniform cross-platform setup, npm is also perfectly fine. GitHub also provides an official install script. For students, GitHub's student benefits are usually quite generous.
On Windows, WinGet is usually the least painful option if you just want it to work. If Node.js is already installed, npm is fine too. If you prefer manual control, you can also download the official executable directly. For students, GitHub Copilot Student offers free student benefits with plenty of quota.
# Official install script
curl -fsSL https://gh.io/copilot-install | bash# npm (requires Node.js 22+)
npm install -g @github/copilot
# Or download the official executable directly
# https://github.com/github/copilot-cliThe Copilot product line itself is fairly complicated. If you are curious, see this additional reading: How Many Microsoft Copilots Are There? For the official student details, see Copilot Student, and for official model support, see Supported AI models in Copilot.
Many students have already subscribed to Cursor. Although Cursor's main product is still its IDE, if you are already using it, it is entirely reasonable to also experiment with its CLI agent and see whether it fits your terminal and automation workflow.
According to Cursor's own docs, Cursor CLI can run in any environment, connect to your preferred IDE, support headless automation, and access models from Anthropic, OpenAI, Gemini, Cursor, and more.
According to Cursor's own docs, Cursor CLI can run in any environment, including Windows and WSL, connect to your preferred IDE, support headless automation, and access models from Anthropic, OpenAI, Gemini, Cursor, and more.
curl https://cursor.com/install -fsS | bash
cursor-agent# First enter WSL from PowerShell
wsl
# Then install inside WSL
curl https://cursor.com/install -fsS | bash
cursor-agentIf you are a student, Cursor currently offers one year of free Cursor Pro. See Cursor for Students. According to the official materials, the CLI is still in beta and its safety systems are still evolving, so it is best used in trusted environments.
If you are a student, Cursor currently offers one year of free Cursor Pro. See Cursor for Students. According to the official materials, the CLI is still in beta and its safety systems are still evolving; if your goal is simply to get it working reliably, WSL is still the easiest place to start.
# For headless automation, call cursor-agent directly
cursor-agent -p "review this repo"
# This also fits automation and scripting workflows well# If you mainly work inside WSL, read the rest as Linux commands
wsl
curl https://cursor.com/install -fsS | bashCursor CLI shares the IDE-side rules, MCP configuration, and workflow capabilities.
OpenCode's own slogan is “The open source AI coding agent.” If you want something that is fundamentally as capable as Claude Code or Codex, but open source, it is worth a look.
Model support is one of its selling points too: the official site explicitly says it works with Claude, GPT, Gemini, 75+ providers, and even local models.
OpenClaw is built around a somewhat different philosophy from Claude Code or Codex, which are more in the “give it a task, let it proceed carefully” family. OpenClaw is more aggressive, with more emphasis on autonomy, persistence, cross-tool orchestration, and longer-running workflows.
That is also why it feels more like a tool for advanced users. If used carelessly, it can run up costs very quickly and introduce more serious safety risks. It is best treated as something for people who already have some experience and understand what permissions they are handing over. Separately, in our own use, its TUI felt dramatically better than the original browser-based window.
Questions
If you already pay for a particular ecosystem, start there. The best first tool is usually not the one that is theoretically strongest, but the one you can sign into and use today with the least friction.
No. You can absolutely start in a test repository, on a small branch, or in a non-critical directory. Approval mode and version control should both be fully enabled.
In the short run, the more realistic outcome is not full replacement but a reallocation of work. Agents will absorb part of the repetitive labor, searching, boilerplate implementation, and tool operation. You still have to define the task, judge the result, and take responsibility for the outcome.
Large and vague tasks, hidden business logic, weak tests, and structurally messy repositories are the most common failure zones.
No. You do not need to sort out all of that before getting started. We will cover these ideas in the workshop at a practical level, so if those terms still feel fuzzy, just come and listen first.
One serious caution, though: there are already plenty of malicious actors intentionally poisoning third-party skills and MCP servers. If you do not understand what something is doing, do not install third-party plugins or extensions just because someone online told you to.
Web Tools
This is one of the least useful things to feel anxious about. You do not need to force yourself into a new tool just to look more advanced. The tool that has real value is the one that can reliably enter your daily workflow and that you are willing to keep using. Web services, desktop apps, and CLI agents all have legitimate places.
Once you try to do anything more serious, it becomes very easy to turn yourself into the middleman between the website and your local environment. Copying files, pasting logs, restating paths, and manually syncing context all become sources of friction and error.
That is often enough, so web tools are not unusable. But as soon as you want to load in your own workflow—connect local tools, call your own scripts, run your own data-processing chain, or integrate with your own development environment—they stop fitting so naturally.
If your prompts, project history, knowledge assets, and configuration habits accumulate inside one vendor's web product, think early about export, backup, and migration. Otherwise, the worst-case scenario is not that the tool becomes inconvenient, but that one day the service shuts down, the product changes direction, or permissions tighten, and your accumulated digital assets simply vanish.
Sources