How CLI Coding Agents Work and How to Choose One

What makes one CLI coding agent different from another

Ask a CLI coding agent to fix a failing test and it won’t reply with a suggestion. It reads the test output, opens the file, edits a line, reruns the test, and reports back once it passes. That loop is the product, not the chat window.

The model inside the loop gets most of the attention, and it’s also the part that changes fastest: vendors swap in new ones every few months, and several agents let you pick. What stays put is the harness wrapped around the model — which tools it can reach, how it manages context, what it may run without asking, and where those commands execute. Two agents running the same model can behave very differently because of it. The harness is what you’re actually choosing.

How the agentic loop works

Strip away the branding and every CLI coding agent runs the same cycle:

1. The model receives your request plus whatever context the harness has assembled: open files, recent shell output, project instructions.
2. Instead of only writing text, the model can emit a tool call: “run this shell command,” “write these bytes to this file,” “search for this pattern.”
3. The harness executes that call for real, on your actual filesystem or shell, and feeds the result back into the model’s context.
4. The model reads the result and decides what to do next: call another tool, or answer you.

This repeats until the model decides the task is done. It doesn’t need a finished plan before it acts. It runs a command, reads what happened, and adjusts, which is also why an agent can burn through dozens of tool calls on a task that turned out to be simple.

Nothing here needs a new model architecture. It needs a model that is good at picking which tool to call and when to stop, and a harness that gives it tools worth calling.

What tools a coding agent actually gets

The built-in tool list is short and boring: read a file, write or edit a file, run a shell command, search the codebase by filename or by content, and in many agents, fetch a URL or drive a browser. Refactoring, debugging, writing tests, reading a stack trace: all of that is the model composing these primitives, not a separate feature the vendor built.

The design decisions that matter live in the details. Does “edit a file” require an exact string match against the current contents, which is safer and easier to review, or can the model overwrite the whole file, which is faster and easier to get wrong? Does “run a shell command” execute directly, or inside a sandbox that blocks network access and writes outside the project? Put the same model behind different answers to those two questions and you get agents that feel nothing alike.

How coding agents handle context larger than the window

A real codebase doesn’t fit in a context window, and a long session produces far more tool output than anyone would paste into a prompt. Agents combine several techniques to cope:

• Selective reading. The agent searches for the relevant file or function instead of loading the whole repository, the same instinct you have when you grep before you cat.
• Compaction. When the conversation passes a size threshold, the harness summarizes the earlier turns into a shorter form and keeps working from that, trading detail for room.
• Subagents. A large task gets split into smaller ones, each sent to a fresh model call with only the context it needs. Only the result comes back to the main conversation.
• Retrieval. Some agents index the codebase and use the same retrieval pattern behind RAG to pull in only the chunks relevant to the current question. Others skip the index and rely on search alone.

Compaction is the one that bites. A detail from early in the session, like a flag you mentioned once, can drop out of the summary. If an agent starts ignoring something you told it an hour ago, that’s the usual cause, and a fresh session with the key facts restated fixes it.

What a coding agent can run without asking

The harness decides how far the agent gets before it stops and asks. At one end, every file edit and every shell command waits for your approval. Safe, and slow: the agent interrupts you constantly. At the other end, the agent runs in a sandboxed environment with nobody watching, which suits background work like fixing a flaky test and opening a pull request while you do something else.

Most daily use sits in between. Read-only actions like searching and opening files happen automatically. Anything destructive or outward-facing, such as deleting a file or pushing to a remote, waits for a yes.

This is policy enforced by the harness, not a property of the model. The same model is careful or reckless depending on what it’s allowed to do unsupervised.

How MCP gives a coding agent new tools

Built-in tools cover the filesystem and the shell, but real work often needs more: querying an internal database, or opening a ticket in your issue tracker. The Model Context Protocol (MCP) is the open standard that provides this without each agent vendor writing a custom integration for every service.

An MCP server describes the tools it offers and how to call them. Any MCP-compatible agent can connect, list those tools, and call them exactly like its built-in ones. The agent needs no service-specific code: it reads the tool descriptions and decides when they’re useful, the same way it decides when to run grep.

The cost is context. In many agents, every connected server’s tool descriptions take up space in the window on each turn, so a dozen servers you rarely use make every request heavier. Connect the ones the project needs.

What AGENTS.md and CLAUDE.md files do

Nearly every agent looks for a markdown instruction file at the root of your repository and reads it before doing anything else. AGENTS.md is the vendor-neutral convention; some tools use their own name, like CLAUDE.md. It’s where you write what the model can’t infer from the code: which command runs the tests, and which directories are generated and must not be edited by hand. Anything the agent would otherwise have to guess, and guess wrong, belongs here.

Many agents also read instruction files in subdirectories, so a monorepo can carry a root file plus a more specific one for each package. Whether a deeper file overrides the root or adds to it varies by tool, so check the docs for the one you use.

Ten lines in this file stop the agent from rediscovering your test command every session.

How to compare CLI coding agents

When the loop and the tool list are the same everywhere, feature checklists stop telling you much. These four questions separate the tools in ways that change your day:

Classify the mode, not the brand. One vendor often ships a terminal tool, an editor extension, and a cloud mode that opens pull requests; Claude Code and OpenAI Codex both work this way. The permission and sandbox defaults differ between those modes, so judge the one you’ll actually use.

How to choose a CLI coding agent for your workflow

Skip the leaderboards. Benchmark scores move every few weeks and say little about your repository. Answer two questions instead: do you want the agent in your terminal or in your editor, and do you want it working unattended in the background or in a loop with you approving each step? Those answers cut the field to two or three candidates.

Then write an AGENTS.md for your project, give each candidate the same real task from your backlog, and keep the one whose diff you’d merge with the fewest edits.

Related articles

• What Is RAG: Retrieval-Augmented Generation Explained
• How to Run a Local LLM With Ollama
• What Is Docker and What Is It Used For