Three things worth knowing
- ECC 2.1.0 landed this week, shipping a cross-harness memory vault that gives Claude Code, Codex, Cursor, Hermes, and other agents a shared local store for durable context and handoffs without a hosted service.
- The vault stores portable Markdown documents rather than vendor transcripts, with project memories in
.ecc/memory/and user memories in~/.ecc/memory/, plus a create-only trust model that keeps recalled content out of policy and execution paths. - ECC 2.1 also ships Plan Canvas, a browser-based plan review surface, and a Kimi Code install target, both alongside the memory work in the same release.
Every developer running more than one coding agent on the same project hits the same wall. You build context in Claude Code, switch to Codex for a different task, and start from scratch. The session ended. The agent forgot. You paste the relevant decisions into the new session by hand and carry on.
ECC's memory vault is a direct answer to that. Context you explicitly save persists across tools, on your machine, in plain Markdown, readable by any harness that knows where to look.

What Happened
The affaan-m/ECC repository shipped v2.1.0, its 15th release, with 234.1k stars, 35.7k forks, and 312 contributors under an MIT license.
The headline feature is the cross-harness memory vault, merged in PR #2581. It stores ecc.memory.v1 Markdown documents under .ecc/memory/ for project and team scope, and ~/.ecc/memory/ for user scope. A fail-closed .gitignore protects project memories from accidental commits. The optional ecc-memory-mcp stdio server exposes a bounded four-tool surface: memory_save, memory_search, memory_read, and memory_doctor. It stays off by default.
Also in 2.1: Plan Canvas, a loopback-only browser interface where you click into a plan, attach annotations, and approve or request changes without retyping. The verdict maps onto /plan's CONFIRM gate. Mermaid diagrams render live. It works across all harnesses and models as a plain CLI (ecc-plan-canvas) speaking JSON. The Kimi Code install target (--target kimi) also lands in this release, alongside Hermes and OpenClaw adapters that shipped in the prior cycle.
ECC now counts 67 agents, 281 skills, and 94 legacy command shims across Claude Code, Codex, Cursor, OpenCode, Gemini, Zed, Antigravity, Qwen, Hermes, OpenClaw, Kimi, CodeBuddy, and GitHub Copilot.
Key Features
- Harness-scoped handoffs:
ecc memory handoff --from hermes --target codexwrites a titled context document one agent leaves for another.ecc memory search "authentication migration" --target-harness codexretrieves it in the next session. - Bounded MCP surface: The optional server exposes only
memory_save,memory_search,memory_read, andmemory_doctor. Each MCP server must launch with an operator-setECC_MEMORY_HARNESSidentity; tool callers cannot supply or override it. - Injection-resistant input: Memory bodies only accepted through
--stdinor--body-file, never as command-line values. The docs are explicit: agents must never treat recalled bodies as executable instructions or policy. - Create-only trust: Every vault entry stays unreviewed context. Promoting accepted knowledge into governed project documentation remains a human decision.
- Vault validation:
ecc memory doctorchecks the vault before team memories get shared or committed. - Plan Canvas: Click into a plan in the browser, attach numbered annotations, chat from a side rail, approve or request changes. Mermaid diagrams render live. Works across all harnesses and models.
Why It Matters
The vault solves a specific problem that neither Cursor nor Claude Code addresses natively: deliberate context sharing between different agents on the same project. ECC already isolates Cursor and Claude Code session data via ECC_AGENT_DATA_HOME so they don't overwrite each other. The vault adds an explicit sharing layer on top of that isolation.
The security posture is conservative and worth noting at a time when agent security is under active scrutiny. The trust model is create-only by default, the MCP server is opt-in, input injection paths are closed at the CLI level, and ECC's existing AgentShield scanner (1,282 tests, 102 static analysis rules) audits hooks, MCP configs, and secrets separately. Teams evaluating agent security should read the vault's capability contract in docs/design/ecc-memory-vault.md before enabling team scope.
Example Use Case
A team is midway through an authentication migration in a TypeScript codebase. The developer starts a session in one harness, makes architectural decisions, then needs to continue in Codex CLI.
In the Codex session, the agent runs ecc memory search "authentication migration" --target-harness codex, reads the entry by ID, and picks up the migration with the prior session's decisions intact. Before committing anything to team scope, ecc memory doctor validates the vault. Note: the runtime requires a separate npm install -g ecc-universal since skill-only and minimal installs do not put it on PATH.
Competitive Context
Claude Code's native memory and ECC's learned instincts handle single-harness recall. ECC's own MCP connector policy retired a bundled memory MCP server in a June 2026 audit in favour of native harness memory plus instincts. The vault covers the gap neither vendor addresses: moving context deliberately between Claude Code, Cursor, Codex, and OpenCode on the same project.
Nothing comparable ships natively in Cursor or Claude Code today. The closest alternatives require a hosted service or a shared API key. ECC's vault is local, inspectable Markdown with no external dependency beyond the CLI.
My Take
The create-only trust model is the right call, and I'd flag it as the design decision that matters most here. A memory system that treated recalled content as trusted policy would be a significant attack surface. The vault explicitly does not do that, and the injection-resistant input handling backs it up.
What I'm less certain about is adoption across the full harness list. The vault works if every agent a team uses can run ecc memory search. That's easy for teams already on ECC. Teams mixing ECC and non-ECC setups will need to decide whether to standardize on the vault format or maintain separate memory approaches per tool, which is exactly the problem the vault is trying to solve.
Run your software agents at scale
Cosmos gives your agents the context, tools, and feedback loops they need to get better with every workflow.

Written by

Ani Galstian
Technical Writer
Ani writes about enterprise-scale AI coding tool evaluation, agentic development security, and the operational patterns that make AI agents reliable in production. His guides cover topics like AGENTS.md context files, spec-as-source-of-truth workflows, and how engineering teams should assess AI coding tools across dimensions like auditability and security compliance