OpenClaw vs Claude Code: An Architectural Comparison

TL;DR

Someone leaked the Claude Code source on GitHub. OpenClaw, the open-source AI coding agent with 346k stars, solves the same problem with a completely different architecture. I compared both codebases at the structural level. The verdict: these are independent implementations that converge on the same tool-use patterns because that is what the problem demands — not because one copied the other.

Background

In late March 2026, a repository appeared on GitHub containing what appears to be the full source code for Anthropic’s Claude Code — the terminal-based AI coding agent I wrote about switching to last month. The repo has two commits (“init” and “add readme”), 1,932 files, and weighs 43MB.

Around the same time, OpenClaw — the open-source AI agent platform — crossed 346k GitHub stars and hit version 2026.3.31. I run OpenClaw on my k3s cluster as an autonomous ops agent, so I know its architecture from the deployment side. Seeing both codebases side by side raised an obvious question: how similar are they really?

This is not a feature comparison or a “which is better” post. It is a structural analysis of two systems that solve the same core problem — give an LLM access to tools and let it work autonomously — and arrived at meaningfully different designs.

The Core Problem Both Solve

Every AI coding agent has the same inner loop:

1. User sends a message
2. System assembles context (instructions, files, history)
3. LLM generates a response, possibly requesting tool calls
4. System executes the tool (run bash, read a file, search code)
5. Tool result goes back to the LLM
6. Repeat until the task is done

The interesting differences are not in this loop — everyone implements it. The differences are in everything around it: how tools are organized, how permissions work, how context is managed, how the system extends, and what the UX model assumes about the user.

Tech Stack

Both are TypeScript. Both use Ink for terminal rendering. After that, the choices diverge. OpenClaw runs on Node.js with pnpm workspaces; Claude Code uses Bun. OpenClaw has native mobile apps and a web UI; Claude Code is terminal-first with a VS Code extension bolted on. OpenClaw stores data in sqlite-vec for vector search; Claude Code uses flat JSONL files and markdown.

The runtime choice alone — Node.js vs Bun — is a foundational decision you would not casually diverge on if copying a codebase.

Tool Architecture

This is where the implementations are most visibly different.

Claude Code: Class-Per-Tool

Claude Code organizes tools as individual directories under tools/, each containing a self-contained tool implementation:

tools/
├── BashTool/
├── FileReadTool/
├── FileEditTool/
├── FileWriteTool/
├── GlobTool/
├── WebFetchTool/
├── WebSearchTool/
├── AgentTool/
├── MCPTool/
├── NotebookEditTool/
├── EnterPlanModeTool/
└── ... (45 total)

Each tool is a discrete unit. There is a base Tool.ts interface, and each implementation handles its own schema, execution, and result formatting. Permission checks happen via hooks in the tool lifecycle. It is a straightforward object-oriented pattern — one class, one responsibility.

OpenClaw: Catalog + Policy + Adapter

OpenClaw takes a compositional approach:

src/agents/
├── pi-tools.ts           # Main tool definitions
├── pi-tools.schema.ts    # JSON Schema for parameters
├── pi-tools.read.ts      # Read-category tools
├── tool-catalog.ts       # Central registry
├── tool-policy.ts        # Access control per tool
└── pi-tool-definition-adapter.ts  # Adapts to provider formats

Tools are defined in grouped files, registered in a catalog, filtered by policy, and adapted to different LLM provider formats through an adapter layer. The policy system means the same tool can have different access levels depending on context — a tool might be read-only in one agent mode and read-write in another.

Dangerous tools get their own file (security/dangerous-tools.ts) with explicit flagging and audit trails.

The design reflects OpenClaw’s multi-channel nature. The same tool catalog serves a Telegram bot, a Slack integration, a web UI, and the terminal — each with different permission profiles. Claude Code only needs to serve one context (the terminal), so a simpler per-tool-class pattern works fine.

Agent Orchestration

Claude Code: QueryEngine + Tasks

Claude Code’s agent loop flows through:

• main.tsx (4,683 lines) — application entry point
• QueryEngine.ts (1,295 lines) — core execution engine
• query.ts (1,729 lines) — query parsing and routing
• Task.ts — base task interface with variants:
  • LocalMainSessionTask — primary local execution
  • LocalAgentTask — sub-agent execution
  • RemoteAgentTask — remote agent execution
  • InProcessTeammateTask — teammate coordination

The bridge/ layer (33 subdirectories) handles communication between the CLI process and various execution contexts. replBridge.ts alone is enormous.

OpenClaw: Embedded Runner + Gateway

OpenClaw’s agent loop is surprisingly thin:

• pi-embedded-runner.ts (~33 lines) — the actual agent runner
• pi-embedded-subscribe.ts — streaming response handler
• acp-spawn.ts — spawns new agent instances
• compaction.ts — context window management
• model-fallback.ts — provider failover

The runner is compact because the heavy lifting lives in the pi-agent-core package. Everything routes through a WebSocket gateway at port 18789 that handles session routing, channel management, and agent pool coordination.

The architectural difference is clear: Claude Code is a monolith where the agent loop, UI, tools, and session management are tightly coupled in one process. OpenClaw is a distributed system with a gateway, agent pool, and channel adapters as separate concerns.

Security Models

These could not be more different in philosophy.

Claude Code: Permission Prompts

Claude Code asks before acting. When a tool wants to run a bash command or write a file, the user gets an interactive prompt: approve or deny. The permission system is configurable — you can auto-approve reads but require manual approval for writes and shell commands. It is a gate-based model: block until approved.

This works because Claude Code assumes a single user sitting at a terminal, watching the output. The human is always in the loop.

OpenClaw: Audit Trails

OpenClaw’s security model is built around transparency, not gates:

src/security/
├── audit.ts                # Runtime audit trail
├── audit-tool-policy.ts    # Tool-level restrictions
├── dangerous-tools.ts      # Explicit dangerous-tool registry
├── dangerous-config-flags.ts
├── temp-path-guard.ts      # Filesystem boundaries
├── scan-paths.ts           # File scanning limits
├── safe-regex.ts           # ReDoS prevention
├── dm-policy-shared.ts     # Channel access policies
├── skill-scanner.ts        # Skill code analysis
└── external-content.ts     # Remote content validation

The philosophy (stated in their VISION.md) is “strong defaults without killing capability” — risky operations are made visible and auditable rather than blocked. This makes sense for OpenClaw’s multi-channel deployment where you cannot always prompt a human for approval. A Slack bot cannot pause mid-message to ask permission.

OpenClaw also has sandbox containers (Dockerfile.sandbox, Dockerfile.sandbox-browser) for untrusted execution — a level of isolation Claude Code does not implement.

MCP Integration

Both support the Model Context Protocol, but differently.

Claude Code has deep, native MCP integration. The services/mcp/ directory contains 15+ files including auth.ts (88k lines), client.ts (119k lines), and config.ts (51k lines). MCP is a first-class citizen in Claude Code’s architecture — it has dedicated tools (MCPTool, ListMcpResourcesTool, ReadMcpResourceTool, McpAuthTool), channel permissions, and a server approval UI.

OpenClaw treats MCP as a bridge, not a core primitive. The src/mcp/ directory has 7 files using mcporter to connect to MCP servers. OpenClaw can both consume MCP tools (as a client) and expose its own tools as MCP endpoints (via plugin-tools-serve.ts). But the implementation is lighter — MCP is one integration channel among many, not the extension mechanism.

Memory and Sessions

Claude Code: File-Based Memory

Claude Code stores everything as files:

~/.claude/projects/<project>/
├── <session-id>.jsonl    # Conversation log
├── memory/
│   ├── MEMORY.md         # Index
│   ├── user_profile.md   # User preferences
│   └── feedback_*.md     # Behavioral corrections

The memdir/ module (21k+ lines for memdir.ts alone) manages a markdown-based memory system with frontmatter metadata. Memory files are loaded into context at conversation start. It is simple, inspectable, and human-editable — you can open your memory files in a text editor.

OpenClaw: Vector Database

OpenClaw uses PostgreSQL with pgvector (or sqlite-vec locally) for semantic memory:

• memories table with 1536-dim embeddings and HNSW index
• session_snapshots for compacted conversation context
• rag_documents for indexed knowledge chunks
• knowledge graph (nodes + edges) mapping service relationships

This is a proper database-backed memory system with semantic search. You cannot casually inspect it in a text editor, but it scales better and supports similarity queries that flat files cannot.

Multi-Model Support

OpenClaw is model-agnostic by design. It supports Anthropic Claude, OpenAI GPT, Google Vertex, DeepSeek, Llama via OpenRouter, and others through a provider abstraction with fallback chains. The model-catalog.ts and model-fallback.ts files handle provider selection and failover.

Claude Code is Claude-only. There is no model abstraction layer, no fallback chain, no provider adapter. It talks to the Anthropic API and that is it. This makes sense for a product built by Anthropic to showcase their model, but it is a meaningful architectural constraint.

Where They Converge

The similarities between these codebases are real, but they are the similarities you would expect from any two systems solving the same problem:

• Tool-use loop: user -> LLM -> tool call -> result -> repeat. This is how tool-use works in every LLM API. You cannot implement it differently.
• Context compaction: both manage context windows by summarizing or truncating old messages. This is a requirement of finite context windows.
• File/bash/grep/glob as core tools: these are the operations a coding agent needs. Omitting any of them would be a gap.
• Sub-agent spawning: parallel work requires spawning child agents. Both implement this.
• Session persistence: conversations need to survive restarts. Both persist sessions.
• MCP support: it is an open protocol. Supporting it is table stakes.

These convergences are like noting that all web frameworks have routing and middleware. The problem dictates the solution space.

Where They Diverge

The meaningful divergences tell the real story:

These are not surface-level differences. They reflect fundamentally different product visions:

• Claude Code is a power tool for a solo developer sitting at a terminal. It is opinionated, integrated, and optimized for one user doing one thing.
• OpenClaw is a platform for autonomous agents that can serve multiple users across multiple channels. It is modular, channel-agnostic, and designed for deployment at scale.

The Verdict

These are independent implementations. The evidence:

1. Different runtimes (Node.js vs Bun) — you do not switch runtimes when forking
2. Different UX paradigms (multi-channel gateway vs terminal CLI) — the product vision is different
3. Different security philosophies (audit trails vs permission prompts) — these reflect different deployment models
4. Different data layers (vector DB vs flat files) — copying would preserve the data model
5. Different extension models (plugin channels vs native MCP) — the integration architecture differs
6. Different tool abstractions (catalog composition vs class hierarchy) — the design patterns diverge

The convergences are exactly what you would expect from two competent teams solving the same problem independently. The agent loop, the core tool set, and MCP support are dictated by the problem space, not by code sharing.

If anything, the comparison highlights how many valid approaches exist in this space. The “right” architecture depends on what you are building: a focused CLI tool for developers, or a multi-channel agent platform. Both are legitimate designs. Both work. They just serve different visions of what an AI agent should be.

Why This Matters

The leaked Claude Code source is interesting not because it reveals secrets — the architecture is roughly what you would expect — but because it gives us a rare opportunity to compare two production implementations of the same concept.

Most open-source AI tools are either toy demos or thin wrappers around API calls. OpenClaw and Claude Code are both real, production-grade systems with hundreds of thousands of users. Seeing how they each solve context management, tool orchestration, and security is more instructive than any architecture blog post.

The AI coding agent space is young. We have not yet converged on “the right way” to build these systems, the way web frameworks converged on MVC or container orchestrators converged on declarative manifests. OpenClaw’s gateway model and Claude Code’s monolithic CLI represent two points in a design space that is still being explored.

For now, I run both: Claude Code for my daily development workflow, and OpenClaw as an autonomous ops agent on my cluster. They complement each other precisely because they were built for different things.