Editor agents

What it is

This entry is a category, not a product. It covers the agent loops that live inside an editor rather than in a terminal — the panel on the right that reads your project, proposes edits, and shows them as a diff you accept or reject. Because it is a category, the spec fields above read as ranges: mixed licensing, various models, and isolation that amounts to "the workspace the editor has open".

Cursor

A fork of VS Code built around the agent rather than bolting one on. The most aggressive of the three on multi-file editing and codebase indexing; proprietary, subscription-priced.

Zed

A fast native editor with an open-source core and an agent panel that takes bring-your-own-key seriously. The choice if editor performance and an auditable client both matter.

GitHub Copilot

The incumbent. Weaker as an autonomous agent than the dedicated tools, stronger on being already installed, already procured, and already tied to your pull requests.

Others arrive and disappear constantly. The shape is what matters, not the brand.

How the loop works

Mechanically it is the same cycle as every other harness on this board: the model asks for a tool, the tool runs, the result comes back. The difference is what the tools are wired to. An editor agent does not have to guess at project structure, because the editor already has an index, a language server and a symbol graph. "Find every caller of this function" is a precise query rather than a hopeful grep, and edits arrive as a reviewable diff in the buffer you are already looking at rather than as a completed write to disk.

That feedback loop is the real product. You see each change in context, at the moment it is proposed, in the place you would normally read code — which is why editor agents catch a category of subtle wrongness that terminal agents get to commit first and explain later.

Isolation and permissions

The workspace is the boundary, and it is a softer one than it sounds. Edits are scoped to the open project and staged for approval, which genuinely limits accidental damage to your files. But most of these tools can also run terminal commands, and once they can, the sandbox is your user account and every credential in it. Approval prompts for shell commands are the only real control, and they are subject to the same fatigue as anywhere else.

The data question is separate and often skipped. Indexing means your code is read, embedded and in some products stored server-side; some vendors offer privacy modes or local indexing, and the details differ per product and per plan. If your code cannot leave the building, read the vendor's data-handling page before installing, not after.

Who it is for

Developers who are working alongside the agent rather than dispatching it: careful changes to code you own, work in an unfamiliar area where you want to read every diff, and anyone who reviews better in an editor than in a terminal. It is the right default for most people most of the time, and the wrong tool the moment you want an unattended twenty-minute job, a scripted run in CI, or several agents working in parallel.

Limits

• You are the bottleneck. Approve-each-diff is the safety mechanism and the throughput ceiling at once.
• Weaker at long autonomy. Session persistence, compaction and subagents are generally behind the dedicated CLI agents.
• Not scriptable. No headless mode worth the name, so nothing here belongs in a pipeline.
• Lock-in is to the editor, not just the vendor. Adopting one usually means adopting its editor, keybindings and extension ecosystem too.
• Opaque pricing behaviour. Per-seat plans with request or credit limits underneath make heavy days end in throttling rather than a clear bill.
• Fast-moving field. Any specific claim about a specific product here ages in weeks; the category description is what will still hold.

Alternatives on this board

• Claude Code — the terminal reference, with IDE surfaces of its own if you want both.
• Codex CLI — when you want a hard sandbox instead of a soft workspace boundary.
• Amp — CLI plus editor, aimed at codebases too large to index casually.
• OpenCode — the same loop in a terminal, with the model left up to you.