Ten MCP tools turn a local folder into agent memory
At commit 0649e71, OpenContext's MCP server registered 10 tools for listing folders, creating documents, searching, building manifests, resolving stable IDs, and checking the index. The underlying material remains Markdown under ~/.opencontext/contexts, with metadata in a local SQLite file. That is a good choice for personal knowledge because a failed UI does not trap the writing inside a remote service. You can inspect, back up, diff, or move the documents with ordinary file tools.
The product's definition of memory is refreshingly literal. You decide what belongs in the library, give folders and documents descriptions, and ask an agent to load a manifest or search before working. Stable oc://doc/ links survive renames by resolving an ID to the current path. OpenContext does not claim that every conversation becomes useful memory automatically. The quality of later retrieval still depends on what you saved and how clearly you described it.
One command edits configuration for three coding tools
oc init targets 3 clients: Cursor, Claude Code, and Codex. It creates user-level skills for all three, slash commands for the first two, and MCP configuration that launches oc mcp over standard input and output. This saves manual wiring, but it also means initialization writes outside the current repository. Read the generated instructions and existing JSON before using it on a carefully managed workstation.
OpenCode occupies an awkward middle ground. The README repeatedly names it as a supported coding-agent CLI, while the documented oc init selection and source code cover Cursor, Claude Code, and Codex. Issue 30, still open after a June 3, 2026 update, asks for OpenCode support. Treat OpenCode compatibility as something to verify in your exact workflow instead of assuming the same installation path exists.
What happened when we ran it
Our sandbox installed 1,041 npm packages in 133 seconds, leaving 821 MB on disk. The checkout was 16.2 MB and contained 242 files with about 40,558 lines of source. There was no build script or target available to the lab, so that step was skipped. The repository does document separate UI and Tauri build commands, but we cannot turn an absent top-level build target into a successful measured build.
The Node test run completed in 23 seconds: 7 tests passed and 0 failed. Our scan found 5 CI workflow files, a tests directory, and no Dockerfile. Npm audit reported 37 known vulnerabilities, split into 1 critical, 22 high, 11 moderate, and 3 low. The audit count does not tell us which flaws are reachable in the CLI or desktop app. It does make dependency review a required adoption task rather than routine cleanup.
Semantic search introduces an external embedding bill
Keyword-oriented folders and manifests can stay local, while vector indexing is a different path. The measured commit defaults to the text-embedding-3-small model and an OpenAI-compatible API base. It accepts embedding credentials and endpoint overrides through environment variables or ~/.opencontext/config.json. The repository instructions warn that an index build can incur external embedding cost. Confidential notes may leave the machine when you choose that provider-backed indexing mode.
OpenContext also has separate AI chat settings, including provider, API base, model, and API key. The default provider is OpenAI, with Ollama named as another option in the configuration source. This flexibility is useful, though it creates two decisions: where embeddings go and where chat prompts go. Teams should inspect both paths before importing internal architecture notes. A local document store alone does not guarantee that every feature processes data locally.
Native packages are the main platform risk in v0.2.7
The store requires Rust-backed native bindings when the CLI loads. Issue 31 reports that @aicontextlab/cli@0.2.2 on Linux ARM64 could not find the expected platform package, causing both oc folder ls and oc mcp to fail. The reporter built the binding from source as a workaround. That may suit a Rust developer, but it defeats the README's two-command setup for ARM servers and small single-board machines.
Desktop users have a separate concern. Issue 37 reports that the v0.2.7 AppImage opened a gray window on Wayland with Mesa 26.0.3 and Intel graphics. The supplied log repeatedly showed EGL_BAD_PARAMETER in bundled WebKitGTK. One report cannot establish general Linux compatibility, yet it is specific enough to test before moving a working document library into the desktop app. The CLI and local web UI remain possible routes if the AppImage fails.
June code activity and July reports show a young project
GitHub recorded 1,059 stars, 8 combined issues and pull requests, and a last push on June 16, 2026. The newest release, desktop-v0.2.7, arrived on January 30, 2026 with indexing, native-package, embedding-length, and editor fixes. Issue 37 was opened on July 3, so user activity continued after the last code push. The 3-month gap to this review is noticeable, though it is too short to call the project abandoned.
OpenContext suits one careful developer better than a team
OpenContext makes the most sense when 1 developer wants the same curated notes available to several coding agents. Markdown storage, MCP access, stable links, and a graphical editor form a coherent personal workflow. The 7 passing tests are encouraging for the narrow path our lab exercised, while 37 audit findings and native platform reports keep this out of the low-maintenance category. Back up ~/.opencontext, review generated agent files, and start with non-sensitive notes.
Mem0 or Supermemory is a better comparison for application-level user memory, while Qdrant's MCP server fits an existing vector database. OpenContext wins when human-readable documents and coding-agent setup matter most. It loses when you need shared access controls, hosted synchronization, ARM binaries that install cleanly, or evidence from a broader test suite. The project is useful today, but the measured dependency state makes a contained trial much easier to recommend than organization-wide adoption.