Introduction

What is it?

Claxedo Framework is a set of MIT-licensed npm packages for building products on top of coding agents that already exist — Claude Code, Codex, Cursor, OpenCode, and Pi. It gives you one programmable surface over all of them: sessions, turns, a single normalized event stream, workspace file/terminal/git access, and deployment plumbing to run it all locally, on a VM, or behind a relay.

This is a working agent backend:

import { createAgentRuntime } from "@claxedo/agent-sdk-runtime"
import { createMemoryRuntimeStore } from "@claxedo/agent-sdk-runtime/stores/memory"
import { claude } from "@claxedo/agent-sdk-runtime/harnesses"

const runtime = createAgentRuntime({
  store: createMemoryRuntimeStore(),
  harnesses: [claude()],
})

const session = await runtime.sessions.create({
  directory: "/path/to/project",
  harness: { id: "claude", access: "native" },
  model: { providerID: "claude", modelID: "default" },
  title: "hello agent",
})

await runtime.turns.start({
  sessionId: session.id,
  agent: "",
  text: "Reply with exactly: HELLO FROM CLAXEDO",
})

Swap claude() for codex() or cursor() and nothing else changes — the harness is data, not architecture.

Why does it exist?

Coding agents became the way software gets written — but each one is a closed, vendor-shaped CLI. If you build a product, a team workflow, or internal tooling around them, you hit the same four walls:

1. Every harness speaks its own dialect. Claude Code, Codex, and Cursor each have their own session model, event stream, and wire protocol. Code written against one is a rewrite away from the next.
2. Configuration doesn’t travel. Skills, MCP servers, and agent config live in per-harness dotfiles (.mcp.json, .codex/config.toml, .cursor/mcp.json, …). Set up one machine for one agent, and you start over for every other machine, teammate, and cloud sandbox.
3. Agent state dies with the process. The CLIs assume an interactive terminal. Products need sessions that survive a crash, stream to a browser, and resume from disk.
4. “Where does it run?” is decided for you. Local-only tools can’t reach a cloud sandbox; cloud products won’t run on your laptop against your worktree. You should be able to choose per session — and change your mind.

Claxedo exists to be the layer that solves those four problems once, as ordinary open-source packages, so every product built on coding agents doesn’t have to solve them again privately.

How is it different?

It’s not an agent SDK. Frameworks like LangGraph or Mastra help you build an agent — you write the loop, pick the model, define the tools. Claxedo assumes the agent already exists and is very good. It drives the released Claude Code, Codex, and Cursor binaries as harnesses, with their own models, tools, and behaviors intact — and gives you the runtime around them.

It’s not a wrapper around one vendor. The same session code runs against every agent installed on the machine, and every harness’s raw events normalize into one AgentRuntimeEvent envelope. Supporting a new harness means writing one event adapter, not forking your product.

Extensions are written once, materialized everywhere. An Agent Extension package (skills, MCP servers, agent config) is authored once and materialized into each harness’s native format — .mcp.json for Claude, .codex/config.toml for Codex, .cursor/mcp.json for Cursor, opencode.jsonc for OpenCode — in one call. No other stack does this across harnesses.

Placement is your choice, per session. A session’s loop and its tools can run on your laptop over loopback, in a cloud sandbox, or split between the two — and authorized teammates can reach a laptop-hosted workspace through the relay without any inbound port.

It’s MIT and composable, all the way down. Ten ordinary npm packages. Each layer works standalone: use @claxedo/agent-event-runtime just to normalize events, or @claxedo/agent-extensions just to sync config, without adopting the rest.

The packages ship execution primitives. Auth, org policy, credential storage, and workspace routing live in your control plane — your server decides who can reach a workspace host. See code-supported vs product-owned.

The stack in one picture

your product
   │
   ├─ @claxedo/workspace-relay ──── reach a workspace from anywhere
   │    @claxedo/workspace-relay-protocol
   │
   ├─ @claxedo/workspace-runtime ── the per-workspace host: sessions,
   │                                terminals, files, diffs, events
   │
   ├─ @claxedo/agent-extensions ─── one extension package → every harness
   │
   ├─ @claxedo/agent-sdk-runtime ── one facade over Claude, Codex,
   │                                Cursor, OpenCode, Pi
   │
   └─ @claxedo/agent-event-runtime ─ every harness → one event shape

Full workspace products usually start with @claxedo/workspace-runtime — it creates the host that owns harness lifecycle, sessions, terminals, managed processes, files, diffs, and events for one workspace. Plus @claxedo/sandbox-manager (sandbox placement and provider drivers), @claxedo/connections (external-account connections), @claxedo/channels (chat-channel ingress), and @claxedo/workgraph (durable work ledger) — all on npm.

Where to go next

See it in action

The packages composed into a full coding-agent app, end to end.

Install

All ten framework packages are on npm.

The layer stack

How events flow from harness up through runtime, relay, and control plane.