2026.10.10
OpenLore: A Governed Filesystem for Shared Agent Knowledge
OpenLore turns ordinary Markdown into a shared knowledge space for agents, people, and repositories, exposing the same virtual filesystem through SSH, MCP, SFTP/SSHFS, and a web view. It fits teams that need current context and scoped permissions, but deployment still requires careful review of identity, persistence, write policy, and version support.
What it is for
OpenLore is an agent-oriented knowledge repository. Its central idea is straightforward: place documents in a folder and let Claude Code, Codex, Cursor, CI jobs, or team members read the same context through familiar file operations. The knowledge remains ordinary Markdown rather than requiring a vector database, ingestion pipeline, or dedicated SDK. For one agent in one repository, keeping Markdown in that repository may be simpler. OpenLore targets situations where several agents, repositories, or people need shared knowledge with explicit rules for who may read, publish, or modify it.
Who may benefit
The project suits development teams maintaining internal API documentation, runbooks, architecture notes, product context, or agent skills. It can also support agent collaboration where session summaries, research findings, and generated reports need a shared home. Teams requiring isolation can give identities private home directories alongside shared docsets. Teams that want controlled contributions can direct contributors to inboxes while reserving existing documents for maintainers.
Documented capabilities
The same virtual filesystem can be exposed over SSH, SFTP/SSHFS, MCP, and a web view. Agents can continue using familiar tools such as cat, grep, and find; MCP clients receive an equivalent shell tool. The permission model includes ro, publish, and rw grants, with identity-scoped docsets and path aliases.
The default posture is read-only. When writing is enabled, the README describes whole-file atomic swaps, conflict detection, authorization, and validation before a change commits. Plugins can add validation, grants, read/write middleware, metadata handling, and post-commit processing. Documentation can also be embedded in a self-contained binary, or cross-platform bundles can be built with the GitHub Action. Frontmatter can be inspected as NDJSON and used to validate OKF bundles and Agent Skills.
Limits and deployment considerations
OpenLore is not a substitute for knowledge governance or proof of semantic search. Teams still need rules for document structure, naming, review, and maintenance. The project presents a filesystem-oriented interface, so its documentation should not be read as evidence of automatic ingestion or semantic retrieval.
Identity, authorization, and persistence should be verified before adoption. What each identity sees depends on configured docsets, paths, and capabilities. Once writes are enabled, teams should design the publishing path, conflict handling, and validation workflow. For hosted deployment, follow the official documentation for networking, persistent storage, configuration, and upgrades; a general deployment claim does not establish availability or operating cost on every cloud provider.
The security boundary also deserves review. The README says normal sessions use an in-memory Go interpreter and restrict arbitrary process execution and ambient network access. That is a project design description, not a security guarantee for every deployment. Evaluate the selected version, configuration, authentication method, and plugins together before production use.
For versioning, the v0.7.3 release notes describe fixes involving restricted Shell behavior, analytics materialization, and the dashboard, along with archives, Homebrew distribution, and checksums. The same notes state that v0.7.2 produced no GitHub release, Homebrew update, or GHCR image. Installation and upgrades should therefore be checked against the formal release record and project documentation.
Sources
Sources checked: 2026-10-10