ECC Ships v2.0.0: A Cross-Harness Agent System for Claude Code, Cursor, and Codex

Most developers running Claude Code and Cursor maintain two separate config setups. Two CLAUDE.md files, two rule sets, two hook approaches, and a growing gap between them every time one gets updated and the other doesn't.

ECC is an open-source agent system that aims to collapse that surface into a single install. It works across Claude Code, Cursor, Codex, OpenCode, Gemini, Zed, and GitHub Copilot, packaging 67 agents, 271 skills, hooks, rules, and a security scanner into a single maintained repo. The v2.0.0 stable release in June 2026 marks the project's shift from config pack to something closer to an agent operating system, with its own framing and one that's harder to dismiss given 218K stars and 268 contributors.

What Happened

Maintainer Affaan Mustafa shipped the 2.0.0 line as stable in June 2026. The release adds a control-pane substrate with session adapters and an MCP inventory, a worktree-lifecycle service, the orch-* orchestrator family, and a Discord community.

The project started as a Claude Code config pack and grew over 10+ months of daily use building production apps. It now ships as a Claude Code plugin (ecc@ecc) and an npm package (ecc-universal). A separate Rust control-plane prototype lives in ecc2/ and exposes dashboard, start, sessions, status, stop, resume, and daemon commands as an alpha.

Two things worth flagging in the contributor list: both @claude and @Copilot appear alongside 266 human contributors. Co-authorship between humans and AI agents is increasingly visible in production repos, and ECC is a clear example of that pattern.

Key Features

• Cross-harness parity: The same agents, skills, and rules are installed across seven harnesses. A DRY adapter pattern lets Cursor reuse Claude Code's hook scripts without duplication, so a TypeScript rule or TDD workflow defined once applies everywhere.
• Selective install: A manifest-driven pipeline lets you install only the components you need. Run npx ecc consult "security reviews" --target claude to get matching components and preview commands before committing.
• AgentShield security scanner: npx ecc-agentshield scan audits CLAUDE.md, settings.json, MCP configs, hooks, and agent definitions across five categories: secrets detection, permission auditing, hook injection analysis, MCP risk profiling, and agent config review. The --opus flag runs three Claude Opus 4.6 agents in a red-team/blue-team/auditor pipeline (1,282 tests, 98% coverage, 102 static analysis rules).
• Token controls: Runtime flags like ECC_HOOK_PROFILE, ECC_SESSION_START_MAX_CHARS, and ECC_DISABLED_HOOKS tune hook strictness and context size without editing files.
• Continuous learning: An instinct-based system extracts patterns from your sessions with confidence scoring, then clusters them into reusable skills via /evolve.
• GateGuard: Gates destructive shell commands, including rm, force git checkout, and destructive find -exec before they run.

Why It Matters

Teams switching between Claude Code, Cursor, and Codex usually maintain separate configs for each. ECC standardizes that surface, so coding standards, security checks, and TDD workflows follow you across tools. The AGENTS.md file at the repo root serves as the universal context file that Claude Code, Cursor, Codex, and OpenCode automatically read.

Three things I keep coming back to:

• The security scanner is the more practical draw: AgentShield treats your own agent setup as an attack surface. Misconfigured hooks, leaked secrets in prompts, and risky MCP servers are real risks once agents run shell commands. An exit code of 2 for critical findings means you can gate on it in CI.
• The installation surface is complex enough to warrant caution: the README explicitly warns against stacking installation methods. Running the full installer after a plugin install creates duplicate skills and runtime behavior. That warning exists because people kept doing it. Pick one path and stay on it.
• The cross-harness data isolation is a detail most people will miss until it bites them: If you run ECC in both Claude Code and Cursor on the same machine, set ECC_AGENT_DATA_HOME="$HOME/.cursor/ecc" for Cursor, or the two environments will overwrite each other's session files.

Example Use Case

You run a Next.js app and use Claude Code as your primary harness, Cursor for pair work. Install the plugin with /plugin marketplace add https://github.com/affaan-m/ECC, then /plugin install ecc@ecc. Copy rules/common and rules/typescript into ~/.claude/rules/ecc/.

Before a production push: run /security-scan to audit your config, then run the e2e-testing skill for Playwright flows, and finally run /test-coverage to confirm 80%+ coverage. When you move to Cursor, set ECC_AGENT_DATA_HOME="$HOME/.cursor/ecc" so session memory stays isolated. The same TypeScript rules and review agents apply in both tools without any additional setup.

This is the workflow I'd show an engineering lead who's tired of the "it works in Claude Code but not in Cursor" conversation.

Competitive Context

Cursor and Claude Code are the harnesses ECC sits on top of, not direct competitors. Feature coverage varies by harness: Claude Code gets all 67 agents and 271 skills with 8 hook event types; Cursor shares those agents and skills, plus 15 hook event types, via the DRY adapter; Codex runs instruction-based, with no hook parity yet; OpenCode gets 12 agents, 37 skills, and 11 hook event types.

Compared to maintaining ad hoc CLAUDE.md files or per-tool rule sets, ECC is a single maintained source that ships weekly across harnesses. GitHub Copilot support is deliberately thinner, limited to .github/copilot-instructions.md and prompt files, because Copilot has no hook or subagent API to build on.

The closest alternative remains the manual approach: maintain your own config files per tool, update them separately, and hope they stay in sync. The 218K stars suggest that it isn't working well enough for most people.

My Take

ECC 2.0.0 is a serious attempt to solve a real problem. The security scanner that audits your own setup is the most practically useful part. The cross-harness parity is the architectural bet, and it mostly holds. For developers running more than one harness, or anyone who's found a misconfigured hook or leaked secret in a prompt, it's worth a close look.

What I'm less sure about is that the install complexity scales with the repo's ambition. 67 agents, 271 skills, and seven harnesses are a large surface to understand before you commit to it. The "pick one install path" warning is good advice, but it implies that the default for many developers will be a broken setup followed by a cleanup session.

I'm curious whether teams land on ECC as a managed standard or as a starting point they fork and trim. Both seem like valid outcomes, and the answer probably changes the value proposition significantly.