OpenContext: A Personal Context Store for Codex, Claude Code and Cursor

The problem OpenContext targets: context that dies with the chat

The README states the problem plainly: when you use an AI assistant to build things, context gets lost across days, repos and chats, so you re-explain background, repeat decisions, and sometimes the assistant continues with the wrong assumptions. That is a real failure mode for anyone working across more than one repository. A decision made in March about why a service polls instead of accepting webhooks lives in a chat transcript, not in the codebase, and the next session starts from zero.

OpenContext positions itself as a lightweight personal context and knowledge store for AI assistants and coding tools like Cursor, Claude Code and Codex. The audience is narrow: individual developers who already run one of those agent CLIs and want their notes to survive the session. The README's comparison table makes the promise concrete, listing global context that works across all projects, an agent that loads your background and decisions automatically, and a knowledge base the coding agent can read and write directly.

The word worth pausing on is personal. Nothing in the README describes shared team spaces, permissions or a hosted sync service. If your actual problem is that five engineers disagree about the architecture, this is not aimed at you.

How the oc CLI, MCP server and generated skills fit together

There are four moving parts, and the README names each one. The oc CLI manages a global contexts/ library made of folders, documents, manifests and search. The MCP server exposes that library so Cursor, Claude Code, Codex and other agents can call OpenContext as tools. Skills and slash commands are generated at user level by oc init. The desktop app and a local web UI provide a graphical way to browse and edit the same store.

The decision that separates OpenContext from a plain notes folder is that it does not ship its own agent. The README says it reuses your existing coding agent CLI (Codex, Claude or OpenCode) and adds a GUI plus built-in skills and tools, so there is no separate agent subscription. The knowledge management agent is the agent you already have.

The data flow follows from that. You run oc init once, which writes skills and slash commands into your agent's config directories and registers the MCP server. After that, an agent session can call the MCP tools to search or read context, or you can invoke a slash command such as /opencontext-context to load background before working and /opencontext-iterate to persist what you learned. The store is a directory of documents, so the underlying format stays inspectable rather than locked inside an application database.

The repository layout backs this up. The top level contains bin/, src/, src-tauri/, crates/, tests/ and an mcp.example.json. The package.json defines a bin entry mapping oc to ./bin/oc.js, an mcp script that runs node src/mcp/server.js, and a test:rust script that runs cargo test inside crates/opencontext-core with a search feature flag. The desktop app is Tauri, which is why src-tauri/ and crates/ sit alongside the JavaScript CLI.

Installing the CLI and running oc init for the first time

The README gives a three-step quick start. The first step installs the CLI globally from npm. Note that the package name is @aicontextlab/cli, not the repository name, and package.json declares node >=18 as the engine requirement.

npm install -g @aicontextlab/cli

The second step initializes the tool inside a project. The README's example changes into your project directory first, then runs init. According to the README, oc init prompts for tool setup and defaults to all supported tools.

cd your-project
oc init

The README notes that non-interactive installs can pass --tools cursor,claude,codex, or use --no-claude, --no-cursor and --no-codex to skip individual tools. After init, Cursor and Claude Code get slash commands, and all three tools get skills. The README lists the exact destinations: Cursor commands land in ~/.cursor/commands, Claude Code commands in ~/.claude/commands (or $CLAUDE_CONFIG_DIR/commands), Cursor skills in ~/.cursor/skills/opencontext-*/SKILL.md, Claude Code skills in ~/.claude/skills/opencontext-*/SKILL.md, and Codex skills in ~/.codex/skills/opencontext-*/SKILL.md (or $CODEX_HOME/skills).

MCP configuration is written at user level rather than per project. The README gives three paths: ~/.cursor/mcp.json, ~/.claude/mcp.json (or $CLAUDE_CONFIG_DIR/mcp.json) and ~/.codex/mcp.json (or $CODEX_HOME/mcp.json). The repository also ships mcp.example.json at the top level, which is worth reading before you let init modify anything, since it shows the shape of the entry being added.

The four slash commands the README documents are /opencontext-context to load background before working, /opencontext-search to find relevant docs, /opencontext-create to create a new doc, and /opencontext-iterate to persist what you learned. A reasonable first session is to create a project overview, then start a fresh agent session and load context to confirm the agent actually pulls it back in. If it does not, the MCP registration is the first thing to check.

If you prefer a graphical path, the README points to the GitHub releases page for the desktop app, and mentions a local web UI that requires no install. The desktop releases listed in the repository are desktop-v0.2.7, desktop-v0.2.6 and desktop-v0.2.5, dated 2026-01-30, 2026-01-25 and 2026-01-17 respectively.

Where OpenContext stops being the right tool

The MCP server runs as a local process, launched through node src/mcp/server.js according to package.json. There is no hosted endpoint described anywhere in the README, and no authentication layer is mentioned. That means the store is exactly as available as the machine it lives on. If you work from two laptops, or from a laptop and a remote dev box, the README does not describe how contexts move between them. You would be syncing a directory yourself and hoping nothing conflicts.

The same gap rules out team use. A shared knowledge base needs identity, write permissions and conflict resolution. OpenContext gives you a global contexts/ library with folders and manifests, which is a filesystem, not a multi-tenant service. For a solo developer this is fine and arguably better, because there is no server to run. For a team it is a mismatch.

There is also a version skew worth noticing. The npm package @aicontextlab/cli is at version 0.1.0 in package.json, while the desktop releases are in the 0.2.x line. The desktop app and the CLI are separate artifacts on separate release tracks, so a desktop feature you read about may not correspond to anything in the CLI you installed. Treat them as two products that share a store format.

Finally, oc init writes into user-level config directories that other tools own. The README does not document an uninstall or rollback command. Removing OpenContext means manually deleting the generated skill directories and editing three mcp.json files. That is not a reason to avoid it, but it is a reason to read mcp.example.json first and to run init in a project you do not mind experimenting in.

How it compares with wiring an MCP server yourself

The obvious alternative is not another context product. It is doing the same thing by hand: keep a notes directory in your repo, write a small MCP server that exposes it as a search tool, and add the server entry to ~/.cursor/mcp.json or the Claude Code equivalent. That approach has real advantages. You control the storage format, you decide what gets indexed, and there is no third-party code writing into your agent configuration directories.

The difference in approach is packaging. A hand-rolled MCP server gives you one tool surface and nothing else. OpenContext adds the oc CLI for managing the library outside an agent session, a desktop GUI for browsing and editing, a local web UI, and the skills and slash commands that oc init generates so the agent has a named entry point rather than a generic tool call. The README's framing is that it reuses your existing coding agent CLI instead of replacing it, which is the same bet a hand-rolled server makes, just with more of the plumbing already written.

The trade-off runs the other way too. A hand-rolled server is a hundred lines you fully understand and can delete in one commit. OpenContext is a CLI, an MCP server, a Tauri desktop app, a Rust core crate and generated files spread across three tool ecosystems. You are trading control and reviewability for a working setup on day one. Which side of that trade you want depends on whether you enjoy writing the plumbing.

Editorial conclusion

Adopt OpenContext if you already run Codex, Claude Code or Cursor and keep re-explaining the same project background in every new session, because oc init writes skills, slash commands and MCP config into directories those tools already read. Skip it if you want a hosted team knowledge base with access control, since the README describes a personal store with no server component, and the npm package is at 0.1.0 while the desktop app is at 0.2.7. Before committing, run oc init in a throwaway project and inspect ~/.cursor/commands, ~/.claude/commands and the three mcp.json files to confirm what gets written; the README does not document a rollback command, so removal is manual.

Frequently asked questions

Official sources

1. 0xranx/OpenContext on GitHub
2. License: MIT
3. Project website
4. README
5. Releases