Agent Harness Landscape 2026 — Comparing Copilot, Codex, Claude Code, Cursor, and OSS on 12 Axes

Introduction

A list of product names and feature checkboxes says little about which agent harness to adopt. For an adoption decision, the model a product uses and its ability to edit files matter less than whether it executes work safely, makes that work observable, and recovers cleanly from failure. That comes down to five questions:

• Where does it run, what state does it hold, and how isolated is it?
• Who controls tool calls, and at what point can they be stopped?
• How is context collected, compressed, persisted, and forgotten?
• Can long-running and parallel work be tracked without losing control?
• When it fails, what can be reproduced, audited, and rolled back?

This article compares representative commercial and OSS products without scoring or ranking them. For each of the following 12 axes, it asks which design responsibilities a product takes on and which remain with the user or organization:

1. Execution locus (local / cloud / hybrid)
2. Orchestration openness
3. Tool extensibility
4. Permission control
5. Context strategy
6. Long-running tasks
7. Multi-agent design
8. Git/PR integration
9. Observability
10. Enterprise governance
11. OSS transparency
12. Evaluation readiness

The scope includes GitHub Copilot (cloud agent / IDE Agent Mode / CLI sandboxes), OpenAI Codex, Anthropic Claude Code, Cursor, Cline, Aider, OpenHands, SWE-agent / mini-SWE-agent, and Continue as a historical reference. Continue is not treated as a primary current contender because, after its final 2.0.0 release, the public repository moved to read-only status.

The comparison reflects public documentation as of September 10, 2026. Pricing, plan boundaries, limits, model availability, and beta features change quickly; verify the primary sources before making an adoption decision.

Executive Summary

In 2026, agent harnesses fall into three design centers. Local versus cloud is only part of what separates them.

The table classifies ways of using a product, not products, because one brand can behave very differently across its CLI, IDE, cloud, and SDK surfaces. GitHub Copilot cloud agent and Copilot IDE Agent Mode, for example, differ sharply in execution responsibility, auditability, latency, and human intervention points.

What an Agent Harness Is

An agent harness is the execution framework that lets an LLM perform software development work. The model is only one of its components; a harness normally also has the pieces below.

Products differ in which of these pieces they build out and which they leave to the user or organization.

Product Map

The "Strong axes" column lists the axes or features where, judging from the comparisons in the axis sections, a product offers more than the others; "Watch carefully" lists constraints or burdens likely to matter at adoption. Both columns are this article's assessments. The numbers refer to the 12 axes listed in the introduction.

How to Read the 12 Axes

Start from the operating model closest to your situation; you do not need to read every axis in order.

Each axis section describes how the products handle the axis, then lists details to inspect, common failure modes, and research findings.

Axis 1: Execution Locus

"Local or cloud" hides several separate decisions. For engineering purposes, split execution locus into at least five layers:

1. Where model inference runs
2. Where tool execution runs
3. Where filesystem changes happen
4. Where network traffic exits
5. Where session state is stored

GitHub Copilot cloud agent starts from a GitHub-hosted session and works in a GitHub Actions-backed ephemeral environment. Execution environment, identity, audit records, and artifacts all stay on one platform, and the work arrives as commits on a branch, logs, and a PR. In exchange, the agent works only within GitHub-hosted repositories, produces one branch and PR per task, and is subject to platform time limits.

Local-first systems such as Codex, Claude Code, Cline, and Aider make the opposite tradeoff. They read and edit the user's working directory, reuse local CLIs and authenticated sessions, and can immediately run local tests and builds. Iteration is fast, but you must deliberately decide how far the agent can reach into secret files, dirty worktrees, local services, and authenticated CLIs, and which external side effects it may cause.

Sandboxed interactive execution narrows the gap. Copilot CLI sandboxes (public preview) and Codex permission profiles (beta) try to combine local iteration with technical containment. Copilot local sandboxing uses OS-specific isolation, while Copilot cloud sandboxing runs in GitHub-hosted ephemeral Linux environments. Codex permission profiles describe filesystem and network access as named profiles, such as :read-only, :workspace, and :danger-full-access. They govern local sandboxed command execution; MCP servers, cloud settings, and approved escalations need separate controls.

Inspect these details:

• Are edits made in the local working tree, an isolated worktree, or a cloud checkout?
• Is network access default-deny, domain allowlisted, or broad by default?
• After a session stops, is its state kept, snapshotted, resumable, or discarded?
• Do intermediate results become branches, commits, PRs, or only chat logs?
• Can the agent reach .env, SSH keys, Docker sockets, or cloud CLI credentials?

Failure modes:

• A local agent can read .env or ~/.ssh because the workspace boundary is too broad.
• A cloud agent cannot reproduce local-only services or secrets, so verification fails.
• A sandboxed command passes locally but fails in CI due to environment differences.
• Multiple agents edit the same working tree and collide.

Research findings:

• For sandboxed systems, the location of execution matters less than how they represent filesystem boundaries, network boundaries, and snapshot and deletion semantics.
• Cursor Cloud Agents and OpenHands Cloud show cloud execution turning into a service surface that bundles GitHub integration, team controls, usage reporting, and permission management with the remote compute.

Axis 2: Orchestration Openness

Orchestration is the control loop that decides what the model does next. There are four broad levels.

More openness gives more control and more responsibility. The Claude Agent SDK, for example, exposes Claude Code-like tools, hooks, subagents, MCP, and sessions from Python or TypeScript. If you expose an agent built on it to users, you own authorization, tenant isolation, logging, consent, and recovery.

GitHub Copilot cloud agent goes the other way. It hides much of the internal control loop but lands work into an organizationally familiar issue/branch/PR flow. It optimizes for a reviewable software process rather than programmable loop internals.

Codex and Claude Code sit in the middle: both expose lifecycle hooks and subagents. Codex hooks include events such as SessionStart, PreToolUse, PermissionRequest, PostToolUse, PreCompact, SubagentStart, and Stop. In current Codex releases, however, command handlers are the primary supported handler type, and PreToolUse / PostToolUse cover only supported paths such as Bash, apply_patch, and MCP tool calls. Hook input still carries transcript_path, permission_mode, and tool input/output, which is enough for automation. Claude Code exposes a broader set that reaches beyond tool calls, including InstructionsLoaded, ConfigChange, FileChanged, TaskCreated, TaskCompleted, and WorktreeCreate.

Inspect these capabilities:

• Can you intercept before tool execution (PreToolUse)?
• Can you intercept before an approval prompt (PermissionRequest)?
• Can you inspect tool output after execution (PostToolUse)?
• Can you prevent the agent from stopping before completion (Stop)?
• Can you observe compaction boundaries?
• Can you observe subagent start/stop events?

Hook event names are product-specific. Codex and Claude Code use PascalCase names such as PreToolUse and PermissionRequest. GitHub Copilot hooks, defined in repository and personal hook files, use lower-camel names such as sessionStart, preToolUse, postToolUse, and agentStop; the public Copilot hook type list does not include a PermissionRequest event. Compare hook systems by capability rather than by event name: whether each offers pre-execution control, post-execution observation, and feedback before completion.

Design implications:

• UI-led systems are easy to adopt but harder to customize deeply.
• SDK-led systems integrate well but make you responsible for multi-tenancy, auditing, and authorization.
• Hook scripts and HTTP endpoints become part of your attack surface.

Research findings:

• Even when a UI-led system hides its internal loop, the organization can still get strong operational control if the work is emitted as reviewable PRs, logs, checks, and comments.

Axis 3: Tool Extensibility

Tool extensibility is converging on MCP, but "supports MCP" does not distinguish one product from another. The differences appear in six layers:

1. Transport: stdio, HTTP, SSE, remote executor
2. Authentication: bearer token, OAuth, local env, managed secret
3. Tool allowlist: server-level or tool-level
4. Approval: auto, prompt, approve, deny per MCP tool
5. Instructions: how MCP server instructions reach the model
6. Distribution: personal, repository, team, organization, marketplace

Codex MCP supports stdio and streamable HTTP servers, bearer tokens, OAuth, tool allowlists/denylists, and per-tool approval modes. Claude Code treats MCP tools like normal tools in hook events, using names such as mcp__server__tool. Cursor centralizes plugins, skills, MCPs, subagents, rules, commands, and hooks through its Customize surface and Marketplace model. GitHub Copilot extends MCP across IDE chat, CLI, Copilot app, cloud agent, and code review, while tying availability to organization policy.

Among OSS systems, Cline emphasizes plugin/MCP/SDK extensibility. Aider is less MCP-centered and more focused on provider flexibility, repo maps, and Git integration. OpenHands moves toward an agent platform that you operate yourself, adding tools at the platform level through its SDK, Cloud, and Enterprise surfaces.

Failure modes:

• Too many MCP servers bloat tool descriptions and reduce tool-selection accuracy.
• Similar tool names cause unstable tool selection.
• OAuth tokens or environment variables do not propagate consistently across local, cloud, and subagent contexts.
• Plugin-bundled hooks or MCP servers are enabled without review.

Questions to ask:

• Is read-only access enough for this MCP server?
• Can write tools be isolated into a separate server or toolset?
• Can approval behavior be configured per tool?
• Are server instructions short and self-contained within the first few hundred characters?
• Who can update, disable, or distribute this extension?

Research findings:

• Codex lets users set allow/deny lists and approval modes per server and per tool, so operating it centers on managing that configuration. UI- and Marketplace-oriented systems shift the work toward distribution and lifecycle management.
• Because Claude Code treats MCP tools as regular tools in lifecycle events, names like mcp__server__tool work in hooks and permissions. MCP tools then fall under the same governance as built-in tools.
• Cursor's Customize surface manages plugins, skills, MCPs, subagents, rules, commands, and hooks in one place. Extensibility there becomes closer to supply-chain management than to local configuration.

Axis 4: Permission Control

Permission control shows the quality of a harness most clearly. Whether an approval dialog exists says little; what matters is which layer enforces the boundary. The layers form a stack, and each covers different failure modes:

Codex permission profiles are concrete: they define filesystem and network boundaries, support read, write, and deny, workspace roots, network domain allow/deny rules, and local/private network handling. Claude Code layers permission modes, allow/deny rules, hooks, managed settings, and subagent-specific tools/permission modes. GitHub Copilot cloud agent distributes permission concerns across GitHub policy, Actions environments, repository settings, hooks, MCP settings, and audit logs.

Cline's editor experience defaults toward explicit approval for actions, with Plan/Act and checkpoints supporting human control. CLI/headless and Kanban workflows can use auto-approval or experimental permission-bypass patterns, so defaults need to be checked per surface. Aider relies on Git recovery more than on hard sandboxing: auto-commits, /undo, and separation of dirty user changes make rollback easy.

Common misunderstandings:

• Hooks are not sandboxes; equivalent side effects may occur through another path.
• PostToolUse is after-the-fact; it cannot undo side effects.
• Instructions are not enforcement. Use permissions, sandboxes, or hooks for hard blocks.
• danger-full-access and bypass modes are useful for experiments but dangerous as team defaults.

Practical default posture:

1. Start with read-only or workspace-write without network.
2. Add network access through domain allowlists.
3. Deny .env, keys, cloud credentials, and package-manager hooks.
4. Where supported, block destructive commands with PreToolUse or an equivalent pre-execution control.
5. Require human approval for deployment, migrations, and production database access through PermissionRequest equivalents or approval UI.
6. Use Stop hooks to prevent "done" before tests or validation run.

Research findings:

• Codex permission profiles turn local command boundaries into explicit filesystem and network policy data. deny wins over write and read, and rules apply relative to workspace roots.
• Claude Code's layering makes it possible to separate static allowlists from dynamic checks.

Axis 5: Context Strategy

Context strategy affects cost, latency, security, and reproducibility as well as output quality.

Common mechanisms:

1. Repository-wide structural summaries
2. Local search, grep, and semantic retrieval
3. Explicit rules and instructions
4. Long-term memory
5. Compaction and summarization

For a closer comparison, context strategy can be modeled as a composition of data structures. The types below are normalized for comparison; products do not necessarily implement these exact types internally.

type ContextLayer =
    | InstructionLayer
    | RepoMapLayer
    | RetrievalLayer
    | MemoryLayer
    | TranscriptLayer
    | CompactionLayer
    | SubagentLayer
    | ToolMetadataLayer;
 
type ContextItem = {
    id: string;
    source: "repo" | "memory" | "rule" | "tool" | "transcript" | "mcp";
    scope: "user" | "project" | "local" | "managed" | "session" | "subagent";
    content: string;
    tokenEstimate: number;
    freshness: "startup" | "lazy" | "live" | "compacted" | "stale-risk";
    authority: "hint" | "instruction" | "policy" | "evidence";
};

In this structure, source, scope, freshness, and authority matter as much as content. CLAUDE.md and AGENTS.md are authority: "instruction", not enforcement. Deny rules and sandbox policies should be modeled separately from context. Tool output is authority: "evidence", but transcript-derived evidence may still be freshness: "stale-risk".

Repository Maps

Aider's repo map is a representative example of compressing context as a symbol graph rather than full files. Conceptually, it looks like this:

type RepoMap = {
    files: FileNode[];
    edges: DependencyEdge[];
    tokenBudget: number;
};
 
type FileNode = {
    path: string;
    symbols: SymbolDef[];
    rank: number;
};
 
type SymbolDef = {
    name: string;
    kind: "class" | "function" | "method" | "type" | "constant";
    signature?: string;
    keyLines: string[];
    references: number;
};
 
type DependencyEdge = {
    from: string;
    to: string;
    kind: "imports" | "calls" | "references";
    weight: number;
};

Aider uses tree-sitter to extract definitions and references, then ranks important snippets over a graph where files are nodes and dependencies are edges, so the model can see likely entry points before reading full files. A token budget such as --map-tokens constrains which SymbolDef.keyLines reach the prompt. Repo map designs differ in retrieval quality and also in which information they discard.

Instructions, Rules, and Memory

Claude Code's CLAUDE.md, .claude/rules/, and auto memory can be separated into three data structures.

type InstructionFile = {
    path: string;
    scope: "managed" | "user" | "project" | "local";
    loadMode: "startup" | "lazy-by-path" | "imported";
    pathGlobs?: string[];
    content: string;
};
 
type MemoryIndex = {
    entrypoint: "MEMORY.md";
    loadedPrefixLimit: { lines: 200; bytes: 25_000 };
    topics: Array<{ path: string; summary: string; lastTouched?: string }>;
};
 
type MemoryNote = {
    topic: string;
    fact: string;
    evidence?: string;
    staleWhen?: string;
};

InstructionFile content enters the context window at startup or lazy-load time, while detailed MemoryNote files are read on demand. Auto memory is therefore closer to a small knowledge base indexed by MEMORY.md than to a long-term memory that recalls everything. Without a staleWhen-style review condition, old learnings can linger.

Transcripts and Trajectories

To evaluate context strategy, you also need to inspect conversation history. Claude Code and Codex hooks expose fields such as session_id, transcript_path, tool_name, and tool_input. mini-SWE-agent stores .traj.json files with info and messages; SWE-agent stores trajectory turns with thought, action, observation, state, and query.

Normalized, this looks like:

type AgentTranscript = {
    sessionId: string;
    messages: AgentMessage[];
    artifacts: ArtifactRef[];
};
 
type AgentMessage = {
    role: "system" | "user" | "assistant" | "tool" | "exit";
    content?: string;
    toolCalls?: ToolCall[];
    extra?: {
        cost?: number;
        timestamp?: number;
        returncode?: number;
        actions?: Array<{ command: string }>;
        response?: unknown;
    };
};
 
type ToolCall = {
    id: string;
    name: string;
    input: unknown;
    output?: unknown;
    approvalState?: "auto" | "prompted" | "approved" | "denied";
};
 
type ArtifactRef = {
    kind: "file" | "patch" | "log" | "pr" | "screenshot";
    uri: string;
    hash?: string;
};

When history is recorded in this structure, you can determine which files were read before an edit, which tool result influenced the final answer, and which evidence disappeared after compaction.

Compaction and Subagent Context

Compaction turns conversation history into the state that the next inference step works from. Claude Code subagent transcripts remain separate from the main conversation, and compaction boundaries can record metadata such as trigger and preTokens.

type CompactionRecord = {
    trigger: "manual" | "auto";
    preTokens?: number;
    summary: string;
    preservedFacts: string[];
    droppedArtifacts: ArtifactRef[];
};
 
type SubagentContext = {
    agentId: string;
    agentType: string;
    parentSessionId: string;
    startupContext: {
        systemPrompt: string;
        taskMessage: string;
        inheritedInstructions: boolean;
        inheritedGitStatus: boolean;
        preloadedSkills: string[];
    };
    transcriptPath?: string;
};

Subagent designs differ in whether a subagent starts from fresh context, inherits the parent through a fork, returns only a summary, or can resume its full transcript. Fresh context reduces context pollution but increases explanation cost. Forks reduce explanation cost but inherit parent noise.

MCP Tool Metadata

Besides calling tools, MCP puts tool metadata into the model's context. Compare at least this structure:

type McpServerContext = {
    name: string;
    transport: "stdio" | "http" | "sse";
    instructions?: string;
    tools: Array<{
        name: string;
        description: string;
        inputSchema: unknown;
        approvalMode?: "auto" | "prompt" | "approve";
        enabled: boolean;
    }>;
};

The instructions field, tools[].description, and input schemas directly affect tool selection. Long descriptions, similarly named tools, and unused tools increase context cost and misselection risk. When evaluating an MCP server, check how much context its metadata consumes and how often it causes wrong tool selection, in addition to whether its tools work.

Products and What to Check

Claude Code combines CLAUDE.md, .claude/rules/, auto memory, subagent memory, and compaction. If auto memory is not audited and curated, stale learnings can conflict with team standards.

Codex has AGENTS.md, rules, hooks, session transcripts, and subagent context. GitHub Copilot cloud agent uses repository instructions, Copilot Memory (when enabled and available under the relevant plan and public-preview conditions), and MCP-provided context such as issues and pull requests. Cursor brings rules, skills, subagents, MCP, and plugins into its Customize surface.

Inspect these details:

• What context loads at startup?
• Are path-specific rules lazily loaded?
• Who writes memory, and who can delete it?
• What survives compaction?
• Does a subagent inherit parent context or start fresh?
• How does the harness find important files in large repositories?

Failure modes:

• CLAUDE.md grows so large that adherence drops.
• Memory contains an obsolete build command and causes repeated failures.
• A path-specific rule did not load but the user assumes it did.
• A subagent lacks needed context and repeats exploration.
• Compaction drops evidence or unfinished work.

Research findings:

• Context strategies differ most in what each system leaves out. Aider compresses code into symbol-level repo maps, Claude Code separates instructions, memory, and subagent context, and SWE-agent-style systems preserve trajectories for replay.
• Modeling rules and memory with scope and loadMode makes them easier to compare. Startup instructions, lazy path-scoped rules, and post-compaction reinjection behave very differently.
• Transcripts and trajectories serve both as model input history and as debugging datasets. mini-SWE-agent's .traj.json structure, with config, messages, cost, and submission data, directly supports later failure analysis.

Axis 6: Long-Running Tasks

Long-running work depends less on how long the model can reason than on whether the harness can split work, wait, resume, and observe progress.

GitHub Copilot cloud agent runs in the background and lands work on branches and PRs. It can be started and followed on GitHub, then iterated through comments, but platform time limits and the one-repository, one-branch, one-PR shape constrain what a single task can cover.

Claude Code spans CLI, desktop, web, and IDE surfaces, and offers background agents, scheduled tasks, subagents, hooks, the Agent SDK, and Managed Agents. Stop and TaskCompleted hooks can define what "done" means. Codex supports subagents, non-interactive execution, hooks, and cloud-connected workflows. Cline emphasizes watching long-running processes such as dev servers and test watchers. OpenHands Cloud/Enterprise pushes this toward service-style multi-user, multi-task operation. Aider remains an interactive terminal pair-programming tool optimized for short Git-backed iterations; its thin support for long asynchronous work follows from that design choice.

Inspect these capabilities:

• Does idle work stop, resume, or persist?
• Can dev server and watcher output be monitored continuously?
• How are rate limits and tool failures retried?
• Are intermediate states stored as transcripts, branches, task cards, or snapshots?
• Can a user steer the session while it is running?

Failure modes:

• A huge task is held in one turn until context rot appears.
• Long tests run synchronously in hooks and stall the agent.
• Background task output never returns to the model.
• Cloud time limits leave half-finished branches.

Research findings:

• Long-running support is mostly about where unfinished state is stored. GitHub Copilot cloud agent stores progress in branches, PRs, and logs; Claude Code and Codex store it in sessions, transcripts, and subagents; OpenHands stores it in Cloud/Enterprise session infrastructure.
• Watcher-style long-running work differs from cloud-PR-style work. Watchers center on stdout/stderr and process monitoring, while cloud PR workflows center on branch state, checks, and review artifacts.
• Synchronous hooks are the wrong place for long validation. Claude Code's async hook pattern shows a useful split: keep the agent loop moving, then return validation output as later context.

Axis 7: Multi-Agent Design

Multi-agent setups pay off only when task boundaries are clear, each worker has scoped permissions and outputs, and integration is planned.

Claude Code subagents have strong context isolation. Built-in Explore and Plan agents are read-focused and keep large search output out of the main conversation. A custom subagent definition is a small execution profile rather than just a prompt: it can specify a name and description, tools, disallowedTools, model, permissionMode, MCP servers, hooks, memory, background behavior, and worktree isolation. Forks inherit the parent conversation, reducing explanation cost but weakening isolation.

Codex subagents spawn when explicitly requested, inherit the sandbox policy, and support parallel investigations or experimental CSV-style worker batches. Cline uses SDK subagents and Kanban (Research Preview) for per-card and per-worktree parallel work. Multiple Copilot CLI cloud sandbox sessions, multiple GitHub cloud agent sessions, and Cursor Cloud Agents also serve as parallel work entry points.

Good decompositions:

• security reviewer / docs researcher / code mapper for parallel review
• frontend reproduction / backend trace / test fixer for a bug
• one worker per file for repeated audits

Bad decompositions:

• multiple agents editing the same file
• parallel implementation before requirements are stable
• more reviewers without a clear final decision owner

Design decisions:

• Who is the coordinator?
• Are workers read-only or allowed to edit?
• Does each worker start fresh or fork parent context?
• Is the output a diff, report, or PR?
• Who resolves conflicts during integration?

Research findings:

• The central design question is which state a worker inherits. Claude Code named subagents start with fresh context, while forks inherit parent context. Codex subagents inherit sandbox policy and runtime overrides.
• Task-board systems such as Cline Kanban and Cursor Cloud Agents map parallel work onto visible work items. SWE-agent and mini-SWE-agent map parallelism into batch runs and trajectories for experiment reproducibility.
• Fan-out increases cost, latency, and integration work, so it pays off mainly for exploration, review, and repeated audits.

Axis 8: Git/PR Integration

An agent harness becomes operationally useful when it produces reviewable diffs.

Aider is the clearest Git-first design. It auto-commits edits, separates dirty user changes before editing, and exposes /diff, /undo, and /commit. Cline emphasizes diff review, checkpoints, and reverts inside the IDE. Claude Code combines Git operations, commits, PR creation, worktree isolation, and hooks. GitHub Copilot cloud agent handles branch creation, commits, PR creation, and iteration through review comments on GitHub.

Beyond whether a product can create a PR, ask:

• How does it handle a dirty worktree?
• Can agent changes be separated from human changes?
• Is author/committer attribution clear?
• Does it respect branch protection and required checks?
• Can it include rationale, test results, and evidence in the PR body?
• Can a human take over mid-task?

GitHub Copilot cloud agent's advantage is that the work starts inside GitHub's collaboration model. Its limits are GitHub-centric operation and weaker fit for multi-repository changes. Cursor's GitHub integration uses a GitHub App with repository, PR, issues, checks/actions, and branch-protection-related permissions. Enterprise setups may involve GitHub Enterprise Server, IP allowlists, AWS PrivateLink, or Cloudflare Tunnel.

Failure modes:

• The agent overwrites human dirty changes.
• A PR exists but lacks rationale or evidence.
• Branch protection prevents the agent-created PR from being mergeable.
• Generated commits are too large to review.
• Rollback only covers Git state and ignores database or external side effects.

Research findings:

• Git/PR integration differs in how much provenance it preserves. The more a system connects rationale, commits, test evidence, related issues, and agent logs, the easier its changes are to review.
• Claude Code worktree isolation and subagent worktrees help separate parallel attempts.
• Git history alone is not enough for external side effects. Database migrations, cloud resource changes, and deployments need separate evidence and recovery procedures.

Axis 9: Observability

Observability decides whether agents can be used in production: a demo can work without it, but an organization cannot. You need to know why a command ran, who approved it, which MCP tool was called, and with what arguments.

At minimum, observe these events:

• session start/end
• user prompt
• tool request / approval / denial
• tool output / failure
• file edit
• command execution
• subagent start/stop
• compaction
• memory load/write
• config change
• PR/commit/check status

Claude Code hooks expose fine-grained fields such as prompt IDs, session IDs, transcript paths, tool names, durations, and subagent transcripts. Codex hooks include session IDs, turn IDs, permission modes, transcript paths, model names, and tool input/output. Cline Enterprise advertises OpenTelemetry, Datadog, Grafana, and Splunk integrations. GitHub Copilot cloud agent naturally aligns with GitHub logs, PRs, Actions, usage metrics, and audit logs.

Chat transcripts are not audit logs. Transcripts help restore model context, whereas audit logs need tamper resistance, retention policy, searchability, secret/PII redaction, and the identity of whoever approved each action.

Practical logging pattern:

• Save tool calls as JSONL.
• Store approval/deny events with user ID, reason, timestamp, and tool.
• Separate shell stdout/stderr summaries from large raw artifacts.
• Run secret scanning on logs too.
• Link session ID to PR number and commit SHA.

Research findings:

• The core of an observability schema is its join keys: session_id, user_id, tool_name, tool_args_hash, approval_state, artifact_ref, and commit_sha. Without these, conversations, tools, PRs, and CI results cannot be joined reliably.
• Enterprise products tend to push observability toward OpenTelemetry, external logging systems, dashboards, and usage reports. OSS/local systems leave more of the log schema to the user.

Axis 10: Enterprise Governance

Enterprise governance is invisible in personal use and decisive in organizational adoption.

Evaluate these areas:

1. Identity, SSO, and RBAC
2. Model allowlists and denylists
3. MCP server allowlists and denylists
4. Managed hooks and permission configuration
5. Network controls
6. Audit logs
7. Cost and budget controls
8. Data retention and region posture
9. Alignment with PR and branch protection
10. Developer device management such as MDM or Intune

GitHub Copilot cloud agent connects naturally to GitHub Business/Enterprise policy, Actions, repository MCP settings, usage metrics, AI credits, GitHub App behavior, and audit logs. Copilot cloud/local sandboxes add local sandbox policy and cloud sandbox access policy considerations.

GitHub Copilot content exclusions do not apply to cloud agent. If exclusions are treated as a cloud-agent access boundary, excluded files can still be seen or updated.

Claude Code has managed settings, managed CLAUDE.md, model allowlists, MCP allow/deny controls, hooks, and permissions. Codex has managed requirements.toml, permission profiles, and managed hooks. Cursor Team/Enterprise includes GitHub integration, Protected Git Scopes, private connectivity, Marketplace/Team Marketplace, Cloud Agents, and Bugbot. OpenHands Cloud/Enterprise emphasizes RBAC, permissions, usage reporting, budgeting enforcement, and multi-user support. Cline Enterprise advertises SSO, RBAC, model/tool controls, remote configuration, and observability.

By contrast, lightweight OSS or research-oriented tools such as Aider and mini-SWE-agent offer flexibility and reproducibility but leave governance largely to you. They can fit enterprise environments if you supply SSO, RBAC, audit retention, exception workflows, kill switches, and cost controls yourself.

Decide these before rollout:

• Who can enable agents?
• Which repositories are in scope?
• Which models are allowed?
• Which MCP servers are allowed?
• Who can distribute and update hooks?
• What happens on budget overrun?
• How long are audit logs retained?

Failure modes:

• Users add arbitrary MCP servers and leak internal data.
• BYOK spreads personal API keys across machines.
• Hooks exist only locally, so team policy is inconsistent.
• Transcripts expire before audit investigations complete.
• Subagent fan-out causes uncontrolled spend.

Research findings:

• How policy is distributed separates the products. Personal config, repository config, team marketplaces, managed config, and MDM-delivered hooks enforce policy to very different degrees.

Axis 11: OSS Transparency

For this comparison, OSS transparency means that you can verify, modify, and audit the harness. Free availability alone does not provide that.

Compare these points:

• What is the license?
• Is the core runtime open source, or only the UI?
• Are enterprise features open, source-available, or closed?
• Can you inspect tool execution and permission logic?
• Is release cadence healthy?
• Can you fork in internal policy?
• Can telemetry and authentication behavior be inspected?

Cline, Aider, OpenHands core, and SWE-agent/mini-SWE-agent are highly transparent. Cline exposes core agent surfaces across SDK/CLI/IDE/Kanban. Aider's Git integration and repo map are inspectable. OpenHands core and agent-server are MIT-licensed, while the Enterprise directory has separate licensing. SWE-agent is MIT and research-driven, with trajectories and batch/eval mechanisms that are easy to inspect. For all of these, Cloud and Enterprise surfaces may still have separate licensing or source-availability constraints.

Continue matters historically, but after its final 2.0.0 release the repository is read-only and no longer actively maintained. Treat it as design lineage and possible fork material rather than a primary adoption target.

OSS gives you more freedom and usually better provider/model portability. In exchange, you own SSO, RBAC, audit, budgets, incident response, and security review.

For closed products, compare audit-log export, configuration export, data-retention documentation, third-party attestations, and evidence availability during incidents as substitutes for code visibility.

Research findings:

• Transparency covers more than code visibility. It includes whether tool execution, permission checks, prompt assembly, memory persistence, telemetry, and provider authentication can be inspected.

Axis 12: Evaluation Readiness

Evaluation readiness lets adoption decisions rest on measurements instead of intuition.

There are three levels:

1. Benchmark evaluation: SWE-bench, ProgramBench, internal task sets
2. Operational evaluation: lead time, intervention count, rollback rate, defect escape
3. Failure analysis: trajectories, transcripts, tool-call logs, root-cause taxonomy

SWE-agent and mini-SWE-agent are strongest here. They are built around SWE-bench, batch mode, trajectory inspection, output files, and YAML configuration. The SWE-agent documentation now recommends mini-SWE-agent as its successor: it matches SWE-agent's performance while being much simpler. That makes mini-SWE-agent a strong default for research/evaluation workflows.

Aider has its own LLM leaderboards for editing capability. GitHub Copilot cloud agent moves evaluation from individual chat turns to the PR lifecycle (branch creation, review, CI, merge, and iteration through comments), so it ties naturally into PR outcomes, merge rates, and time-to-merge data. Developer-facing harnesses such as Claude, Codex, Cline, and Cursor still need separate analysis on real repositories because official benchmarks rarely expose context retrieval, approval flow, rollback, or review quality.

A good evaluation set should:

• Use real past issues.
• Have test or review-based acceptance criteria.
• Mix small, medium, and large tasks.
• Separate read-only research, single-file fixes, multi-file fixes, investigation, and refactoring.
• Measure intervention count and evidence quality, not just success/failure.

Avoid these traps:

• Choosing based on one demo task
• Comparing models and harnesses without separating variables
• Ignoring human review time
• Looking only at successful PRs
• Excluding permission/security failures from the evaluation

Compare candidates with the same model, task set, permissions, and MCP configuration where possible, and record unavoidable differences. Then classify failures into model reasoning, context retrieval, permission blocks, tool failures, human handoff, and the external environment. Unlike a success rate, a failure taxonomy like this shows what to fix, and harnesses that record enough to support the classification are easier to improve.

Research findings:

• SWE-agent and mini-SWE-agent treat the trajectory as a first-class artifact. Structures such as thought, action, observation, state, query, or .traj.json fields like info, messages, and extra make failure analysis and replay possible.
• Aider's editing benchmarks are useful but do not measure organizational governance. Editing capability, reviewability, auditability, and rollback should be analyzed as separate concerns.

Selection Framework Across the 12 Axes

Which axes matter most depends on how the agents will be operated. Four common operating models follow.

GitHub-Centric Organization

Primary candidates:

• GitHub Copilot cloud agent
• Copilot IDE Agent Mode / Codex / Claude Code / Cursor as local complements

Focus axes: 1 execution locus, 4 permissions, 8 Git/PR integration, 9 observability, 10 governance, 12 evaluation readiness.

Good fit when:

• Most engineering changes already flow through GitHub Issues and PRs.
• Auditability and permission governance matter.
• Work can be reviewed at PR granularity.
• Tests and builds run in GitHub Actions.

Poor fit when:

• Work spans multiple VCSs or many repositories in one task.
• Core workloads are long-running jobs.
• Verification depends heavily on local-only services.

Small, High-Velocity Product Team

Primary candidates:

• Claude Code
• Codex CLI
• Cursor
• Cline
• Aider

Focus axes: 1 execution locus, 3 tool extensibility, 4 permissions, 5 context strategy, 8 Git/PR integration.

Good fit when:

• Decision makers and implementers are close.
• Tests run quickly on developer machines.
• Rollback is mostly Git-based.
• Speed matters more than centralized control.

Poor fit when:

• Strict separation of duties or centralized audit is mandatory.
• Developer machines hold high-privilege secrets.
• Local-only policy cannot be managed consistently.

Team Building Its Own Agent Platform

Primary candidates:

• OpenHands SDK/Cloud/Enterprise
• Cline SDK
• Claude Agent SDK
• Copilot SDK

Focus axes: 2 orchestration, 3 tool extensibility, 4 permissions, 6 long-running tasks, 7 multi-agent design, 9 observability, 10 governance.

Good fit when:

• You need integration with internal portals or ticketing systems.
• You need multi-user or multi-tenant agent runtime.
• You want tools, hooks, MCP, and telemetry shaped to internal requirements.

Poor fit when:

• There is no team to operate the runtime.
• You cannot maintain sandbox, session, and audit infrastructure.
• A ready-made UI is enough.

Research and Evaluation Team

Primary candidates:

• mini-SWE-agent
• SWE-agent
• OpenHands benchmarks / SDK

Focus axes: 5 context strategy, 7 multi-agent design, 9 observability, 11 OSS transparency, 12 evaluation readiness.

Good fit when:

• You need trajectories for failure analysis.
• You compare models or prompts systematically.
• Reproducibility matters more than daily UX.

Poor fit when:

• Daily development UX is the priority.
• Non-technical users need to operate it.
• SSO/RBAC/audit requirements arrive immediately.

Cross-Cutting Findings

Four trends run across the 12 axes.

First, context and enforcement are becoming separate layers. CLAUDE.md, AGENTS.md, rules, memory, repo maps, and MCP metadata shape model behavior, but they do not enforce boundaries. Enforcement requires permissions, sandboxes, hooks, and managed policy.

Second, transcripts and trajectories are becoming core artifacts. The more a harness records what it read, which tools it called, which observations it received, and where compaction happened, the easier it is to analyze failures later. SWE-agent-style systems make this explicit for research, while Claude Code and Codex expose much of it through hooks and transcript paths.

Third, extensibility is becoming a supply-chain problem. MCP servers, plugins, skills, hooks, and subagents are useful, but each adds tool metadata, credentials, approval boundaries, distribution paths, and update responsibilities. Managing extensions therefore includes being able to disable, scope, and audit them.

Fourth, cloud-first and local-first systems also differ in the artifacts they produce. Cloud systems lean toward PRs, branches, task boards, and usage reports. Local systems lean toward working trees, terminal output, Git commits, and transcripts. The right choice depends on which artifacts the organization wants to review, audit, and retain.

Reproducibility Note (September 10, 2026 Snapshot)

To update this article:

1. Separate each product by surface: CLI, IDE, cloud, SDK.
2. Recheck only the affected axis.
3. Verify official docs for limits, beta notes, and plan boundaries.
4. Update only the relevant section and table cells, then record the verification date.

Closing

In practice, agent harnesses differ less in their model names or claims about autonomous coding than in which responsibilities across the 12 axes each product takes on and which remain your operating burden.

For individual development, a bit of manual approval and local responsibility may be worth the speed. For organizational development, PRs, auditability, policies, cost control, and recovery dominate. For research, trajectories and reproducibility matter most.

So before asking which agent is smartest, answer this:

Which failures are we willing to tolerate, and which failures do we want to make technically impossible?

With that answer, choosing an agent harness becomes an engineering decision.