OpenContext: a personal context store that plugs into the coding agent you already run
A personal context store for AI agents and assistants—reuse your existing coding agent CLI (Codex/Claude/OpenCode) with built‑in Skills/tools and a desktop GUI to capture, search, and reuse project knowledge across agents and repos.
At a glance
- What is it?
- OpenContext is an MIT-licensed JavaScript tool that keeps a global contexts/ library, exposes it over MCP, and generates user-level skills so Cursor, Claude Code or Codex can read and write your project knowledge. The interesting part is the bring-your-own-CLI bet; the unproven part is how that store behaves once it grows.
- Who is it for?
- Adopt OpenContext if you already pay for a coding agent CLI and keep re-explaining the same project background across repos and sessions, and if you are comfortable with your knowledge base living as plain folders and documents under a single global contexts/ directory.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 92 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OpenContext targets: context that dies with the chat window
The README states the problem plainly: context gets lost across days, repos and chats, so you re-explain background, repeat decisions, and sometimes watch the assistant continue from the wrong assumptions. That is a real failure mode for anyone who moves between several repositories with one assistant, because each new session starts from whatever the agent can infer from the current directory. OpenContext's answer is a global contexts/ library that sits outside any single repo, so the same background is available whether you are in the frontend or the infrastructure project. The intended user is a builder who already runs Cursor, Claude Code or Codex and wants the agent to load history first, act, then persist what it learned. The README frames the audience with a before/after table: hard-to-share context becomes a global library, ideas become something the agent perceives automatically, and existing knowledge becomes something the agent can read and write directly. Note what is absent from that pitch. There is no claim about retrieval quality, no index format, no statement about what happens when the library holds thousands of documents. The project sells the plumbing, not the ranking.
Five components, one directory: how the pieces fit together
The README lists five components. The oc CLI manages the global contexts/ library, described as folders and documents plus manifests and search. An MCP server exposes the same store as tools that Cursor, Claude Code, Codex and other agents can call. Skills and slash commands are generated at user level, with skills for Cursor, Claude Code and Codex and slash commands for Cursor and Claude Code. A desktop app provides a native UI for managing, searching and editing contexts. A web UI browses and edits contexts locally with no install. The data flow implied by the documentation is: the agent calls an OpenContext tool over MCP, or you invoke a slash command such as /opencontext-context, the request resolves against the global contexts/ library on disk, and results come back as context the agent can use. Writing follows the same path in reverse, which is what /opencontext-iterate is for. The architectural bet is that the store is plain files rather than a database or a hosted service. That makes it inspectable and portable, and it means your knowledge survives an uninstall of the desktop app. It also means the store has no built-in notion of permissions, sharing or conflict resolution beyond whatever the filesystem provides. For a single developer on one machine that is fine. For a team, it is the first thing you would have to solve yourself.
Getting it running: npm, oc init, and the files it writes
Installation is a single global npm package: npm install -g @aicontextlab/cli. The README's 30-second setup then runs oc init from inside your project directory. That command prompts for tool setup and defaults to all of them. For scripted or non-interactive installs the README documents --tools cursor,claude,codex along with the individual flags --no-claude, --no-cursor and --no-codex. The generated slash commands are /opencontext-context for loading background before working, /opencontext-search for finding relevant documents, /opencontext-create for creating a new document, and /opencontext-iterate for persisting what you learned. The README is specific about where files land. Slash commands go to ~/.cursor/commands and ~/.claude/commands, or $CLAUDE_CONFIG_DIR/commands when that variable is set. Skills go to ~/.cursor/skills/opencontext-*/SKILL.md, ~/.claude/skills/opencontext-*/SKILL.md with the same CLAUDE_CONFIG_DIR override, and ~/.codex/skills/opencontext-*/SKILL.md with $CODEX_HOME as the override. MCP configuration is user-level rather than per-project: ~/.cursor/mcp.json, ~/.claude/mcp.json and ~/.codex/mcp.json, again with the environment variable overrides. Two things follow from this layout. First, everything is user-scoped, so a colleague cloning your repository does not inherit your setup. Second, because MCP config is user-level, the OpenContext server is available in every project you open with that agent, not just the one where you ran oc init. If you want the store scoped per project, the README does not describe a mechanism for that.
The bring-your-own-CLI decision, and what it costs you
OpenContext does not ship its own agent. The README says it reuses your existing coding agent CLI, naming Codex, Claude and OpenCode, and adds a GUI plus built-in skills and tools. The stated benefit is that you do not pay for a separate agent subscription. That is a genuine architectural choice with consequences in both directions. On the plus side, your context store is not tied to one vendor's model or pricing, and switching from Claude Code to Codex does not orphan your knowledge base, because the store is the same directory and the MCP server is the same server. On the minus side, the quality of every context operation depends on the agent you brought. If your CLI is slow, expensive or unavailable, so is OpenContext. There is also a compatibility surface to watch: the README lists Cursor, Claude Code and Codex for skills, but slash commands only for Cursor and Claude Code. Codex users get skills and MCP tools, not slash commands. That asymmetry is easy to miss when reading the feature list, and it changes how you invoke the workflow day to day depending on which CLI you run.
Where the documentation is thin: search quality and scale
The README mentions search in three places: the oc CLI manages a library with search, the desktop and web UIs let you search contexts, and /opencontext-search finds relevant documents. It never describes how search works. There is no statement about whether matching is lexical or embedding-based, whether there is an index file, or what the manifests contain beyond the word itself. The README also points to the website for search configuration and an FAQ, so the detail presumably lives there rather than in the repository front page. Treat that as the main unknown. A personal context store is only as useful as its retrieval, and retrieval is exactly the part the front page does not quantify. The same gap applies to scale. Nothing in the material says how many documents the library is expected to hold, whether the agent loads the whole store or a subset, or what the token cost of a typical /opencontext-context call looks like. If your library is a dozen documents, none of this matters. If it grows into the hundreds, the absence of any stated ranking or budget mechanism is the thing to test before you depend on it.
Alternatives, and the actual difference in approach
The obvious comparison is a per-repository instruction file, such as an AGENTS.md or CLAUDE.md checked into each project. That approach is versioned with the code, reviewed in pull requests, and shared automatically with everyone who clones the repo. OpenContext inverts every one of those properties: the store is global and user-level, so it spans repositories but is not shared by cloning, and it is not reviewed alongside code. The trade is deliberate. A per-repo file answers what is true about this project; OpenContext answers what is true about you and how you work across projects. If your problem is that a teammate's agent lacks project conventions, a checked-in file is the better tool. If your problem is that your own agent forgets your preferences and prior decisions every time you open a different repository, OpenContext addresses that and a per-repo file does not. A second comparison is a general note-taking application with an MCP server bolted on. The difference is that OpenContext generates the agent-facing surface itself, the skills and slash commands, rather than leaving you to write prompts that describe how the agent should query your notes. That generation step is the concrete thing you are adopting.
Maintenance, releases and the MIT licence
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; anything beyond it is a question for your own counsel. On maintenance, the material shows a desktop release cadence across early 2026: desktop-v0.2.5 in mid-January, desktop-v0.2.6 in late January, and desktop-v0.2.7 on 30 January 2026. The repository's last push is dated 16 June 2026, and it is not archived. Those dates tell you the project is active but not how stable the interfaces are. Version 0.2.x is pre-1.0, and the generated artifacts live in your home directory, which is the practical upgrade cost: a change to skill or command naming between releases can leave stale files in ~/.cursor/skills, ~/.claude/commands or ~/.codex/skills that you have to clean up by hand. The README does not describe an upgrade or cleanup command. Before updating the CLI, it is worth listing those directories so you know what the previous version wrote. The npm package is published as @aicontextlab/cli, which is a different name from the GitHub repository, so pinning the version you install is the straightforward way to keep the CLI and the generated files in step.
Editorial conclusion
Adopt OpenContext if you already pay for a coding agent CLI and keep re-explaining the same project background across repos and sessions, and if you are comfortable with your knowledge base living as plain folders and documents under a single global contexts/ directory. Do not adopt it if you need per-team access control, a hosted sync layer, or a store large enough that search quality becomes the deciding factor; the README describes search configuration but gives no ranking detail, so verify that against your own material first. Before committing, run oc init in a throwaway project with --tools cursor,claude,codex, inspect exactly which files land in ~/.cursor/commands, ~/.claude/commands and ~/.codex/skills, and confirm the generated MCP entries in ~/.cursor/mcp.json point at the CLI you actually use.
Community notes