ECC 2.0-rc.1 Makes the Case for Portable Agent Harnesses Across Claude Code, Codex, Cursor, OpenCode, and Gemini

Everything Claude Code's 2.0.0-rc.1 materials are easy to underestimate because the project name sounds like a Claude-specific config pile. The interesting part is that the release candidate argues for the opposite: agent behavior should not be trapped inside one vendor's harness. Skills, hooks, MCP conventions, rules, instructions, operator workflows, and audit practices need to become portable assets.

That is a sharper point than it first appears. Teams are no longer using one coding agent. They are using Claude Code for one class of task, Codex for another, Cursor where the editor context matters, OpenCode or Gemini in other workflows, plus local wrappers and MCP servers stitched around all of it. The result is not a clean platform. It is a messy toolbox. Messy toolboxes need shared rules more than they need another magic prompt.

The ECC release candidate was manually verified from the GitHub repository, which was updated on May 11 at 23:48 UTC and pushed shortly before that. The project positions ECC as a reusable substrate for skills, hooks, MCPs, rules, instructions, and workflows, with Hermes documented as an optional operator shell layered on top. The cross-harness architecture names the portability problem directly: Claude Code has native hooks, Codex currently leans more on AGENTS.md and instruction-backed parity, OpenCode uses plugin/event adapters, Cursor needs translated rule and hook layouts, and Gemini is treated as an install/instruction compatibility surface.

Portable behavior beats portable chat history

The most useful idea in ECC is that SKILL.md is the portable unit. Not the transcript. Not the exact slash command. Not a vendor-specific plugin. The skill is the durable behavior: what the agent should do, what constraints apply, what tools are appropriate, what checks matter, and what must never be shipped.

That is how mature teams should think about agent configuration. A Claude Code command, a Cursor rule, a Codex instruction file, and an OpenCode event adapter are loading mechanisms. The real asset is the workflow encoded in human-readable instructions and backed by tool boundaries. If the workflow only exists as a Claude-only command or a Cursor-only rule, it will drift the moment another harness enters the team.

Drift is the hidden tax of multi-agent adoption. One harness gets the security checklist. Another gets last month's version. A third has access to an MCP server that nobody reviewed. A fourth has a helpful local automation pack that quietly assumes the wrong repo layout. The user experience looks productive until the same task behaves differently depending on which agent picked it up.

ECC's argument is not perfect portability. That would be fantasy. Hooks, session semantics, permission models, MCP import behavior, plugin events, and memory conventions differ across harnesses. The practical discipline is “write durable behavior once, adapt at the edge.” Keep the workflow, policy, and quality bar central. Translate only the harness-specific loading and event surfaces.

Cross-harness config without trust boundaries is just a larger attack surface

The security language in the ECC docs is the part builders should not skim. The architecture explicitly warns against shipping OAuth tokens, API keys, raw Hermes exports, personal workspace memory, private datasets, or unsanitized local automation packs. That sounds obvious. It is also exactly the category of mistake teams make when they package “working agent setup” into a reusable bundle.

Agent config is executable in the practical sense even when it is “just text.” It can grant tool access, shape model behavior, define hooks, point at MCP servers, encode local paths, and teach agents which commands are normal. Porting that config across harnesses without a trust model can replicate risk faster than it replicates productivity.

This is where ECC's local-first observability stance is sensible. The readiness materials focus on file-backed checks: loop status, session traces, harness audit scorecards, tool activity logs, and tool-risk ledgers. They cite practical artifacts such as live JSON loop status, session inspection across Claude/dmux/adapters, scorecards for tool coverage and context efficiency, tool-usage.jsonl, and a risk ledger in ecc2/src/observability/mod.rs.

Hosted telemetry is convenient, but agent traces are not ordinary metrics. They can include prompts, file paths, tool arguments, repo names, customer context, and occasionally secrets that should never have been present. Local audit trails are not a rejection of observability. They are a recognition that the first observability requirement for coding agents is not “send it to a SaaS dashboard.” It is “capture enough evidence to debug and govern the system without leaking the system.”

The adapter layer is where teams should invest

The practitioner move is to build a small internal agent-config discipline before the harness sprawl becomes unmanageable. Treat skills as source-controlled artifacts. Review them like code. Put deny rules and tool scopes in the same place as workflow instructions. Version them. Record which harness adapters consume them. Run a lightweight audit whenever a skill is translated into another environment.

That audit should answer boring but necessary questions. Does the Codex version preserve the same “do not run destructive commands” rule as the Claude version? Does the Cursor rule accidentally expose a broader workspace? Does the OpenCode adapter fire hooks on the same events? Do MCP servers have the same environment and credential boundaries? Is the tool-risk ledger updated when a skill gains a new capability?

Teams should also separate portable intent from local capability. “Run tests before proposing a code change” is portable. “Use this private deploy script with these environment variables” is not. “Never commit secrets” is portable. “Read my local memory file” is not. The more explicit that boundary becomes, the easier it is to share useful agent behavior without packaging private infrastructure by accident.

There is a useful analogy to infrastructure-as-code. The cloud provider matters, but the durable asset is the declarative specification and the review process around it. Agent harnesses are moving toward the same shape. Claude Code, Codex, Cursor, Gemini, and OpenCode are execution surfaces. The durable layer should be the team's skills, policies, tool contracts, and audit practices.

ECC is not the biggest framework launch of the week, and it probably will not be the one that trends hardest. But it is pointing at the right future. The agent ecosystem is not converging on one perfect coding agent. It is fragmenting into many useful harnesses with different strengths. In that world, portability is not about pretending every harness is identical. It is about preventing the team's safety rules, workflow knowledge, and quality gates from scattering across five proprietary corners.

The editorial take: cross-harness portability is where serious agent teams are going, whether they have named it or not. Portable skills, explicit trust boundaries, local audit trails, and thin adapters are less glamorous than autonomous coding demos. They are also the difference between a multi-agent workflow and a pile of unsupervised instructions with commit access.

Sources: Everything Claude Code GitHub, ECC 2.0.0-rc.1 release notes, ECC cross-harness architecture, ECC observability readiness, Hermes setup docs