A chat assistant answers questions about work. A coding agent does the work. You give it a goal — fix this bug, write a script that renames these files, explain why this deploy failed — and it reads your project, makes a plan, edits files, runs commands, checks the results, and iterates until the job is done or it needs your input. All three major labs now ship one, and all three run in the same unglamorous place: the terminal.

If 'the terminal' sounds like something only engineers should touch, hold that thought until the end of this guide. The short version is that these tools have quietly become useful well beyond software teams, because an agent that can read files and run programs can automate an enormous amount of ordinary office drudgery.

Meet the three

  • Claude Code is Anthropic's coding agent. It installs with `npm install -g @anthropic-ai/claude-code`, and beyond the terminal it also runs as a desktop app on macOS and Windows, in a web version, and inside VS Code and JetBrains IDEs. Access is included with Claude's paid plans, or through an API account for usage-based billing. Official docs: claude.com/claude-code.
  • Codex is OpenAI's equivalent. It follows the same multi-surface pattern — a CLI, IDE integration, and a cloud mode that runs tasks on OpenAI's infrastructure — and access is included with ChatGPT's paid plans. Official docs: developers.openai.com/codex.
  • Gemini CLI is Google's entry, and the outlier in two ways: it is fully open source, and it has a genuinely free tier — sign in with a personal Google account and you get a substantial daily allowance at no cost, which makes it the lowest-friction way to try this category at all. It installs with `npm install -g @google/gemini-cli`. Official repo: github.com/google-gemini/gemini-cli.

Capabilities, pricing, and included allowances shift constantly in this category — faster than anywhere else in AI right now. The shape above is durable; the details on any given week belong to the official pages.

What working with one is actually like

You open a terminal in a project folder, start the agent, and type what you want in plain language. The agent reads the relevant files, proposes changes, and asks permission before doing anything consequential — editing a file, running a command, installing something. You approve, it proceeds, and the loop continues: it runs the tests, reads the failure, fixes its own mistake, and tries again.

Two things surprise people on first contact. First, how much context these agents gather on their own — you rarely paste code into anything; the agent goes and reads what it needs. Second, how far 'coding' stretches. In practice these are general-purpose computer agents with a permission system, which is why they are covered in a workplace track and not just a developer one. The conceptual background — what makes something an agent rather than a chatbot — is covered in [agents and tool use](/guides/agents-and-tool-use/).

Trying one safely

The permission prompts are the safety model, and a few habits make them meaningful:

  • Work in version control. Git is the undo button. An agent working in a repository can be wrong at length and cost you nothing but a discarded branch. If a project is not in git, that is worth fixing before the agent arrives, not after.
  • Read the diff, not just the summary. Agents narrate their work well, and the narration is not the work. Before accepting changes, look at what actually changed — the same discipline as reviewing a colleague's pull request.
  • Keep approvals on until trust is earned. Every agent offers some way to reduce how often it asks permission. Resist that for the first weeks. The prompts are how you learn what the tool actually does under the hood.
  • Start on chores, not the crown jewels. Renaming files, writing a one-off script, summarizing a log, drafting tests — high-volume, low-blast-radius work is where the tools shine immediately and where mistakes are cheap.

Not just for engineers

The non-obvious workplace value is everything that is *almost* programming: the analyst with four hundred inconsistently named files, the ops person hand-assembling the same weekly report, the marketer who needs every image in a folder resized. These have always been five-line-script problems, and the people who have them have never been script writers. A terminal agent closes exactly that gap — describe the chore, approve the steps, keep the script it wrote for next time.

A reasonable pattern for a rollout is a small pilot with technical staff first, then a second circle of operations-minded volunteers with a [use policy](/work/ai-use-policy/) in place. It rarely needs a big program beyond that: these tools spread on demonstrated usefulness or not at all.

What security will ask

Three questions come up in every review of this category, and all three have workable answers:

  • What leaves the machine? Code and file contents the agent reads are sent to the provider's models to generate responses. That makes the account tier decisive: under a [business plan's](/work/business-ai-plans/) data commitments, that traffic is not training data. Same rule as chat, higher volume.
  • What can it execute? Commands the user approves. The permission model, plus ordinary user-account restrictions, is the enforcement boundary — agents run with the permissions of the person driving them, so existing access controls keep meaning what they already meant.
  • Can we audit it? Sessions are logged locally, and the git history of agent-made changes is itself a better audit trail than most human work leaves behind.

The honest summary for a security team: this category moves real work through an AI provider and executes real commands locally, both under explicit user approval. It deserves the same review as any powerful developer tool — and it passes that review at organizations with serious security postures, which is part of why it has spread as fast as it has.