OpenWiki: a CLI that turns your codebase into a self-maintaining wiki for agents

The problem: documentation that rots faster than humans can fix it

Most codebase documentation is written once and then ignored. When the code changes, the docs drift, and agents that read those docs inherit the drift. OpenWiki attacks this by making an agent the author and a queue the memory. The target user is a team that runs coding agents or LLM-based tooling and needs a stable, current reference that those agents can read as context. It is not for teams that want polished, human-voice docs. The output is a Markdown wiki, which is plain text that any tool can parse, and the project explicitly frames it as memory for agents. The README says the wiki is "built for agents to read as memory, and it ships an interactive visualizer for humans to explore." That split tells you where the priorities sit.

How it works: a durable page queue and Grounded Claims

The core mechanism is a resumable page-job architecture. Repository generation follows a sequence: `begin → submit_plan → next_page → submit_page → finish`. Each page is an independent job in an ordered queue, and progress is checkpointed in `openwiki/.run.json`. A page only advances after its Markdown, Claims, verification, and a `openwiki/.page-manifest.json` entry are durable. That means an interrupted run can resume from where it left off on a persistent checkout. The second mechanism is Grounded Claims. Material facts in code wikis carry versioned source evidence. When that evidence changes or disappears, OpenWiki knows which propositions need to be confirmed, rewritten, or retired. This is a concrete answer to the stale-docs problem: instead of regenerating everything, it tracks which statements depend on which files. The README does not specify how Claims are represented on disk, only that they persist strictly and are tied to source versions. That is a gap you should verify before trusting the feature for compliance-heavy work.

Getting started: real commands and config keys

Installation requires Node.js 22 or newer. The command is `npm install -g openwiki`. Then run `openwiki --init` in a repository. The first run walks you through picking a provider, key, and model, then writes docs to `openwiki/`. Rerunning `--init` replaces the generated wiki and Claims but preserves the user-authored `openwiki/INSTRUCTIONS.md` brief. That brief is your lever for steering the agent's output. To update from code changes, run `openwiki --update`. For automation, the README points to three CI examples: `openwiki-update.yml` for GitHub Actions, `openwiki-update.gitlab-ci.yml` for GitLab, and `openwiki-update.bitbucket-pipelines.yml` for Bitbucket. Those files are not included in the supplied material, so you must fetch them from the repository. On Windows, the README warns that installing with `bun` can fall back to compiling the `better-sqlite3` native dependency, which needs Visual Studio Build Tools with the C++ workload. Using `npm` or `pnpm` avoids that path.

Coding-agent integrations: when you already have a model

Instead of launching its own model, OpenWiki can run inside Codex, Claude Code, OpenCode, or Cursor. The command is `openwiki integrations install codex`, and similarly for the other three. These install at user level by default, so one installation works from any Git repository. The coding agent investigates the repository, plans the wiki, and writes each page sequentially with its native tools. OpenWiki owns the durable page-job lifecycle, validates each completion, and finalizes Claims, indexes, provenance, and metadata. The README states that host-driven runs support repository code wikis, not personal brains, and they use the coding agent's authenticated model session, so no OpenWiki provider credentials are needed. This is a meaningful cost saving if you already pay for a coding agent subscription. But it also means the quality of the wiki depends on the coding agent's ability to follow a page plan, which is a different failure mode than a dedicated documentation agent.

Personal wikis and connectors: the other half of the product

OpenWiki has two modes: `code` for a repository and `personal` for your own knowledge. The personal mode is less described in the README, which focuses on repository generation. What is concrete is the list of nine built-in connectors: Custom MCP, Notion, Slack, Gmail, X, Web Search, Hacker News, LangSmith, and local git repositories. That range suggests the personal wiki can ingest external sources and synthesize them into the same linked Markdown format. The README does not give a command for personal mode, so you would need to check `openwiki --help` after installation. The visualizer is a separate deliverable: an interactive node graph that can be exported as a static site for GitHub Pages, MkDocs, or any static host. That is a practical way to share the wiki with humans without running a server.

Limitations and failure modes you should know

The biggest limitation is the ephemeral CI problem. The README says that on a persistent checkout, OpenWiki resumes from `openwiki/.run.json`, but ephemeral CI runners start fresh after failure unless their workspace is preserved. That means a scheduled CI job that runs on a clean runner will lose all partial progress and restart the entire generation. For a large repository, that could be hours of agent time wasted. The README does not say what happens to the wiki if the CI job fails mid-run and the workspace is not preserved. Another limitation is that the `--init` command replaces the existing wiki and Claims, which is destructive. The only thing preserved is `openwiki/INSTRUCTIONS.md`. If you have hand-edited any generated page, that edit is lost. The README also notes that host-driven runs do not support personal brains, so if you want a personal wiki, you must use the CLI's own model connection. Finally, the README does not mention how OpenWiki handles monorepos with multiple packages or large generated directories like `node_modules`. You should assume it will try to read everything under the repository root unless you configure an ignore list, and the README does not document such a config key.

Alternatives and how they differ

The closest alternative is to write your own documentation pipeline using a tool like MkDocs and a script that regenerates pages from templates. That approach gives you full control over the content and does not require an agent or a model provider. The difference is that OpenWiki's agent synthesizes facts from source and tracks evidence, which a template script cannot do. Another alternative is a documentation generator like Docusaurus, which builds a static site from Markdown but does not write the Markdown for you. You would still need to hand-write the prose or feed it through a separate LLM call. OpenWiki's advantage is that it couples generation with verification and update tracking. The trade-off is that you are trusting an agent to decide what is a material fact, and you have to review the Claims to confirm they match your understanding. If you already use LangChain's Deep Agents, OpenWiki is a natural fit because it uses that same agent framework.

Maintenance and upgrade cost

The project is under active development, with three releases in a single day in the supplied material (v0.4.1, v0.4.2, v0.4.3). That cadence suggests rapid iteration, which is good for bug fixes but means you should pin the version in CI. The README does not document a migration path between versions, so assume that upgrading may require regenerating the wiki. The license is MIT, which is permissive and does not impose obligations beyond preserving the copyright notice. The main maintenance cost is not the CLI itself but the scheduled CI job that opens a docs PR whenever the wiki changes. That PR will need human review to catch hallucinated Claims or incorrect page structure. The `openwiki/INSTRUCTIONS.md` brief is your control point for steering the agent, so expect to iterate on that file. There is no mention of a config file for model parameters or output directory, so you will need to rely on the interactive setup and the instructions brief. That is a thin surface for a tool that generates an entire wiki.

Editorial conclusion

Adopt OpenWiki if you want agent-readable documentation that updates itself, especially if you already use LangChain's Deep Agents or a supported coding agent. Skip it if you need human-curated prose or if your repository has a large binary or proprietary blob that an agent cannot summarize well. Before adopting, verify that your CI runner can persist the `openwiki/` directory across scheduled runs, because ephemeral runners lose partial progress and restart from scratch. Also confirm that your chosen model provider is in the thirteen supported ones, and test a single `openwiki --update` on a small repo to see whether the generated Claims match your notion of material facts. The project is MIT-licensed and actively released, but the README does not document a migration path, so plan to regenerate from scratch if you later change providers.

Official sources

1. Official README
2. Project repository
3. Release notes