UltraContext: Sharing Agent Context Across Claude Code, Codex and OpenClaw

The gap UltraContext targets: context trapped inside one agent

The README states the problem in one line: what Claude Code knows, Codex does not. That is not a model quality issue. It is a storage issue. Each coding agent keeps its own session state locally, so a plan written in one tool is invisible to the next tool you open, and invisible to a teammate running a different agent. UltraContext's answer is a shared store plus a capture daemon: sessions from Claude Code, Codex and OpenClaw are ingested in realtime, and every connected agent can read them back. The README frames the audience as people shipping at inference speed, and the example prompts are telling: ask Codex to pick up the last plan Claude Code made, ask what the team is building today, ask what a named colleague is doing in Codex right now. That third example is the one that changes the product category. Once context is shared across machines, this stops being a personal memory tool and becomes team infrastructure, with the access questions that implies. The repository is JavaScript, licensed Apache-2.0, and the last push recorded is 2026-06-24, with v1.6.0 released 2026-04-20.

Three surfaces: CLI daemon, MCP server, Context API

UltraContext ships as three things that can be used separately. The CLI is a background sync process with a terminal dashboard; the README describes it as auto-ingesting Claude Code, Codex and OpenClaw sessions. The MCP server is what makes that captured context visible to other agents: the README says it is built into the API or can run standalone over stdio. The Context API is the lower-level piece for builders, described as git-like primitives for context engineering. The data flow is capture, store, retrieve. A session event is ingested by the daemon, written to a context object in the store, and then read back either by an MCP-connected agent or by your own code calling the SDK. The design choice worth noting is that the MCP server is not a separate product tier. If the API is the store, MCP is just another client of it, which is why the README can claim any agent gets awareness of every other agent without a per-agent integration.

The Context API is deliberately small: five methods, automatic versioning

The README is explicit that the API has five methods: create, get, append, update, delete. Automatic versioning is not optional. Every change creates a new version, and the README claims full history out of the box, with time-travel to any point in a context's history. That combination is the most interesting engineering decision in the project. A small verb set plus immutable version history means you cannot quietly mutate a context and lose the prior state, which matters when two agents are appending to the same session. The cost is that context objects grow: every append is retained, so a long-running shared context accumulates versions you must eventually reason about. The README does not describe a retention or compaction mechanism, and that is a gap worth flagging rather than glossing over. The JavaScript example shows the shape plainly: construct an UltraContext with an apiKey, call create, append a message with role and content, then pass ctx.data straight into any LLM call. The Python SDK mirrors it, reading back with uc.get(ctx["id"])["data"]. Note the asymmetry in the two snippets: the JS example passes ctx.data directly, while the Python example re-fetches the context by id before reading data. The README does not explain whether that difference is stylistic or required.

Getting it running: Node 22, one global install, five CLI commands

The install path is short. The README states a requirement of Node >= 22, then npm install -g ultracontext. Running ultracontext with no arguments starts sync, described as a daemon plus dashboard. The documented subcommands are ultracontext sync to start the daemon and dashboard, ultracontext stop to stop the daemon, ultracontext config to run the setup wizard, and ultracontext update to update the CLI globally. For the API path, the JavaScript and TypeScript SDK installs with npm install ultracontext, and the Python SDK with pip install ultracontext. Authentication is an API key in the form uc_live_..., passed as apiKey in JavaScript or api_key in Python. That prefix is the only deployment detail the README gives, and it is worth reading carefully: the key format suggests a hosted service rather than a local server. The README never shows a base URL, a self-hosting guide or a Docker command, so anyone who needs context to stay on their own network should treat that as unresolved and check the docs before installing.

Where UltraContext is the wrong tool

The ingest list is the first limit. The README names Claude Code, Codex and OpenClaw. If your agents run inside a framework that is not on that list, the automatic capture path does not apply to you, and you are left with the Context API as a manual store you wire up yourself. That is a real reduction in value: the CLI and MCP server are the parts that require no integration work, and they are the parts tied to specific tools. The second limit is the one the README advertises as a feature. Framework-agnostic is true of the API, but the API is not where the capture happens. The third is operational: this is a daemon. It runs in the background, watches sessions, and writes them to a store. A daemon that observes every agent session is also a daemon that can fail, and the README documents ultracontext stop and ultracontext update but no health check, log inspection or restart-on-failure behaviour. If capture silently stops, the failure mode is not an error. It is an agent answering from stale context, which is harder to notice than a crash. The fourth limit is the one implied by the team examples: if context is shared across people, the access model matters. The README does not describe per-context permissions, so verify that before pointing a team at it.

Alternatives and the actual difference in approach

The obvious alternative is to keep context in the agent's own session state and export it by hand, pasting a plan from one tool into another. That works, costs nothing, and has no daemon to operate. The difference is that manual export is a copy, not a shared record: two people cannot both see the current state, and there is no history unless you keep one yourself. A second alternative is to build the store yourself on top of a database or a file-backed log, using the same create and append pattern the UltraContext SDK exposes. That gets you full control over retention, permissions and hosting, at the cost of the MCP server and the ingestion work, which is the part that is genuinely tedious to write. The honest comparison is not feature-by-feature. It is that UltraContext's value is concentrated in the capture and the MCP bridge, not in the five API methods, which are easy to reimplement. If you only need a versioned context store and you are happy writing the client, the API alone is a thin layer. If you need Claude Code and Codex to see each other without you doing anything, that is the part you are paying for.

Maintenance, releases and what Apache-2.0 covers here

The release cadence visible in the material is tight: v1.4.13 on 2026-04-13, v1.5.0 on 2026-04-14, v1.6.0 on 2026-04-20, with the last repository push on 2026-06-24. Three releases in eight days followed by a two-month gap in pushes is a pattern you should interpret yourself rather than assume either way; the material does not say what the gap means. The CLI has a built-in upgrade path, ultracontext update, which updates the CLI globally, so staying current is one command. The SDKs are distributed through npm and PyPI, which means version pinning is your responsibility and a major bump can land without a CLI update. On licensing: the repository is Apache-2.0, which is a permissive licence with an explicit patent grant and a requirement to preserve notices. That covers the code in this repository. It does not automatically cover the hosted service the uc_live_ key points at, and the README does not state terms for that service. Read the LICENSE file in the repository for the exact grant, and check the service terms separately. This is a description of what the licence text does, not legal advice.

Editorial conclusion

Adopt UltraContext if you already run two or more of Claude Code, Codex or OpenClaw and keep losing plans between them; the CLI plus MCP path is the low-effort entry point. Do not adopt it if your context lives in a framework it does not ingest, if you need self-hosting, or if you cannot send session content to a hosted service with an uc_live_ key. Before committing, verify the retention and deletion policy behind that key, confirm the ingest path for your agent, and read the Apache-2.0 LICENSE for what the grant covers.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ultracontext/ultracontext on GitHub