How Claude Code, Antigravity, and Cursor Actually Work

An agentic coding IDE is not magic — it's a model stuck in a loop, holding a handful of carefully designed tools, running inside a carefully locked-down shell. Claude Code, Google Antigravity, and Cursor all implement roughly the same architecture. They look different on the surface because of how they package it — a CLI binary, a VS Code fork, a standalone desktop app — but if you strip away the UI, you find the same four primitives every time: terminal access, structured file operations, efficient code search, and a loop with a stopping condition. That's the whole job.

This post breaks down each primitive in enough detail that you could build a toy version yourself. We'll also point you to the open-source projects — aider, Cline, OpenHands, SWE-agent — that expose every piece in code you can actually read.

The Three Major Agentic IDEs

Before we get to the internals, know what we're comparing. The three dominant agentic coding environments as of April 2026 each have a distinct packaging model.

The surface differences matter less than you'd think. Once you peek at the tool definitions each one sends to its model, they all look nearly identical: a bash or shell tool, file read/write/edit tools, a search tool built on ripgrep, and a way to spawn sub-agents. The interesting engineering is in what happens when those tools get called.

How Agents Actually Access the Terminal

Terminal access is the primitive everything else is built on. If the agent can't run a shell command, it can't compile, can't run tests, can't install dependencies, can't deploy. Every serious agentic IDE has a shell tool. The question is how it's implemented and what constraints it enforces.

The pattern, stripped to its essentials, looks like this.

import subprocess, shlex

def run_command(
    cmd: str,
    cwd: str = ".",
    timeout_s: int = 120,
    allow_patterns: list[str] = None,
) -> dict:
    # Permission gate — only run if command matches an allowed pattern
    if allow_patterns and not any(p in cmd for p in allow_patterns):
        raise PermissionError(f"Command not allowed: {cmd}")

    # Spawn as subprocess with captured stdout/stderr
    result = subprocess.run(
        cmd,
        shell=True,
        cwd=cwd,
        capture_output=True,
        text=True,
        timeout=timeout_s,
    )

    return {
        "stdout": result.stdout[:30_000],  # Truncate to fit context
        "stderr": result.stderr[:10_000],
        "exit_code": result.returncode,
    }

That's the whole primitive. Everything else is policy around it.

The three real-world implementations each add guardrails. Claude Code uses a permission mode that either runs automatically (for trusted commands), prompts the user interactively (for unknown commands), or refuses (in restrictive sandbox mode). Cursor gates shell access behind user confirmation by default. Antigravity puts commands in a staged queue that the user approves before execution.

Output streaming matters too. A long-running command — say, pytest tests/ with 2,000 tests — will blow up your context window if you wait for it to finish and then dump the whole log. The right pattern is to stream output into a ring buffer, truncate to a sensible tail (last 30,000 chars is a common cap), and show the exit code prominently.

Efficient Search Through the Terminal

Once you have a terminal, the next problem is searching for things. Large codebases have millions of lines. A naive grep -r across a monorepo will take tens of seconds and return more output than any model context can hold. Agentic IDEs solve this by standardizing on a small set of modern search tools that are much faster and return structured output.

Here is the speed comparison on a 500k-line Python repo. Representative wall-clock numbers from a warm cache on a modern laptop, not vendor marketing.

Ripgrep (rg) is the default across all three agentic IDEs. It's written in Rust, uses SIMD, respects .gitignore by default, has built-in file-type filters, and outputs line numbers in a format an agent can parse without regex gymnastics. Claude Code's internal Grep tool is a thin wrapper around rg. Cursor uses rg. Antigravity uses rg. When you see an agent search your code, it's rg underneath.

The efficiency isn't just about raw speed — it's about output size. A good search tool returns only the matches an agent needs. A bad one dumps 5,000 lines into context and burns 40,000 tokens.

# File discovery (replaces find)
fd -e py -e ts src/          # All .py and .ts files under src/
fd --changed-within 1d       # Files modified today

# Content search (replaces grep)
rg "useAuth" --type tsx      # Only .tsx files
rg "TODO|FIXME" -n          # Line numbers, regex alternation
rg "def process_" -l        # Only file names, not matches

# Syntax-aware search (replaces regex for code)
ast-grep --pattern 'async def $NAME($$$)' --lang python

# Limit output size — critical for agent context budget
rg "pattern" | head -50

If you want to see how Claude Code wraps these in its Grep tool, open any session and watch the tool calls — it routes everything through rg with explicit flags for head limits, file type filters, and output mode (content, files_with_matches, or count).

Spinning Up Agents with Git Worktrees

This is the part people find most magical, and it is the simplest once you see it. You can have multiple agents working on the same repository in parallel without them stepping on each other — not because of any clever coordination protocol, but because of a 15-year-old git feature called worktrees.

The command is one line:

# Create an isolated working directory for a new branch
git worktree add ../myproject-feat-auth feat/auth
git worktree add ../myproject-feat-search feat/search
git worktree add ../myproject-bugfix-rate-limit bugfix/rate-limit

# Each worktree is a full working dir pointing at the SAME repo
# Run a different agent in each one, in parallel
cd ../myproject-feat-auth && claude-code "implement OAuth login" &
cd ../myproject-feat-search && claude-code "add fuzzy search" &
cd ../myproject-bugfix-rate-limit && claude-code "fix the 429 loop" &

# List active worktrees
git worktree list

# Clean up when done
git worktree remove ../myproject-feat-auth

Claude Code exposes this directly. When you spawn a sub-agent via the Agent tool with isolation: "worktree", it automatically creates a temporary worktree, runs the sub-agent there, and cleans up when the sub-agent finishes (or leaves the worktree in place if the agent made changes, so you can review them).

How Agents Know When to Stop

Giving an agent a loop is easy. Giving it a loop that knows when to stop is the hard part of production agent engineering. Left to their own devices, agents will happily iterate forever, chasing a goal they can't quite reach or spinning on a test that will never pass. Every serious agentic IDE uses a combination of four stopping conditions, usually with priority ordering.

In practice you combine them. A typical production agent loop looks something like: "Run until the tests pass, OR until 20 iterations, OR until 100k tokens, whichever comes first. If any of those trigger, return the current state and let the user decide whether to continue."

def run_agent(
    task: str,
    max_iters: int = 20,
    max_tokens: int = 100_000,
    success_check=None,
) -> dict:
    tokens_used = 0
    messages = [{"role": "user", "content": task}]

    for i in range(max_iters):
        response = llm.step(messages, tools=AGENT_TOOLS)
        messages.append(response)
        tokens_used += response.usage.total_tokens

        # Stop 1: explicit completion tool call
        if response.called("done"):
            return {"status": "complete", "iters": i + 1}

        # Stop 2: success check (e.g. tests pass)
        if success_check and success_check():
            return {"status": "success", "iters": i + 1}

        # Stop 3: budget cap
        if tokens_used >= max_tokens:
            return {"status": "budget_exhausted", "iters": i + 1}

        # Execute any tool calls the model issued
        for tc in response.tool_calls:
            result = execute_tool(tc)
            messages.append({"role": "tool", "content": result})

    # Stop 4: max iterations reached
    return {"status": "max_iters", "iters": max_iters}

The Open-Source Projects That Show How It Works

Everything above is reverse-engineered from observation and from the open-source projects that implement the same patterns in code you can read. If you want to see an agent loop actually run, these four repos are the best starting points.

Read Cline first. It's the shortest path to understanding the loop. Then read aider for the git integration patterns, then SWE-agent for the insight about tool design, then OpenHands for the production-scale architecture.

What You Actually Need to Know

Everything in this post boils down to five things. If you understand these, you can debug any agentic IDE when it misbehaves and you can build your own when you need to.

1. The shell tool is sacred. Treat it like a loaded gun. Allowlist, timeout, captured output, user confirmation for destructive commands. Every production agent has this. Every toy agent skips it and eventually regrets it.
2. Modern search tools are non-negotiable. Replace grep with rg, find with fd, regex with ast-grep for code. The efficiency difference is 10–50×, and more importantly the output is structured and bounded.
3. Git worktrees are the coordination primitive. Parallel agents don't need clever message passing. They need isolated working directories. Git gives you that for free.
4. Stopping is harder than starting. Combine explicit completion, success checks, budget caps, and iteration limits. Every serious agent uses all four.
5. The open-source projects are better than any blog post, including this one. Read Cline. Read aider. Read SWE-agent. The patterns are in the code.

The Bottom Line

The best way to learn how these tools work is to build one. Grab Cline's source, strip it to the bare loop, replace the model with Claude Sonnet 4.6 via the Anthropic API, and see what happens. In two hours you will know more about agentic IDE internals than 99% of people who use them every day.