OpenWiki lets your coding agent write the repo wiki while it keeps the Claims honest

Claims tie each wiki fact to versioned source evidence

OpenWiki's output is ordinary Markdown in an openwiki/ directory of your repository, linked page to page, which you own and can read like any other docs. What separates it from a one-shot README generator is the Claim. For repository wikis, OpenWiki tracks facts back to source evidence and versions that evidence, so when the code moves it can identify which facts need attention instead of regenerating everything.

That design shapes the update cost. A rerun focuses on what changed, and completed pages survive interruptions because progress is saved page by page. If a long run dies halfway through a large repository, you resume rather than start over. The same wiki can be browsed as an interactive graph, and OpenWiki can emit portable OKF v0.2 output and publishable visualizers if you want the knowledge outside the repo.

The agent writes pages, OpenWiki owns the queue

In the recommended setup there is no separate model provider to configure. OpenWiki uses your coding agent's authenticated model session and repository tools. The agent investigates the repository, plans the wiki, and writes each assigned page with its native tools. OpenWiki keeps the durable queue, validates and persists Claims, handles source drift, and deterministically finalizes Claims, indexes, provenance, setup files and metadata.

The two sides talk over MCP in a fixed lifecycle: openwiki_begin, openwiki_submit_plan, then openwiki_next_page and openwiki_submit_page for each page, and finally openwiki_finish, with openwiki_inspect_page_claims available on demand. Per page, the host submits only sparse Claim decisions. OpenWiki keeps current Claims that the change did not affect, applies explicit confirmations, revisions, additions or retractions, and refuses to finish until the final state is durable. The practical effect is that a sloppy agent cannot silently drop facts it did not look at.

Host-driven runs only build repository code wikis

The agent-hosted path has a narrower scope than the standalone CLI. Host-driven runs currently support repository code wikis, not personal brains, and they draw only on repository source and tests. Connector-sourced context, including LangSmith, is not yet supported there.

Two consequences follow. If you hoped to fold traces, tickets or other external knowledge into the wiki while letting Claude Code or Codex do the writing, that combination is not available; personal knowledge and scheduled updates belong to the standalone CLI. And host-driven runs write each assigned page sequentially. The parallel page workers that document several pages concurrently, save progress page by page and adapt to provider rate limits apply to native CLI runs. On a large codebase, the convenient agent route gives up that concurrency.

Integrations install at user level, with per-host paths

OpenWiki needs Node.js 22.22.0 or newer, matching the engines field in package.json. The global install is one command:

npm install -g openwiki

Then connect the agent you use. For Claude Code that is:

openwiki integrations install claude

The other targets are codex, opencode, cursor, bob, kiro, omp, antigravity and copilot. Integrations install at user level by default, so one install works from any Git repository. openwiki integrations list shows status, openwiki integrations uninstall <host> removes one, and adding --project [path] scopes any of the three to a repository, resolved to its Git root. Each host writes to its own config: Kiro to ~/.kiro/skills and ~/.kiro/settings/mcp.json, GitHub Copilot CLI to ~/.copilot/skills and ~/.copilot/mcp-config.json, OpenCode to ~/.config/opencode. Pi is the exception: it is not a target of openwiki integrations install and loads the package itself, with a project-local option:

pi install --local npm:openwiki

After restarting the agent, you open a repository and ask it to initialize OpenWiki from the current source and tests.

Installing with bun on Windows can pull in a C++ toolchain

The Windows guidance is specific: install with a Node.js package manager.

pnpm add -g openwiki

Installing with bun can fall back to compiling the better-sqlite3 native dependency, and that needs Visual Studio Build Tools with the Desktop development with C++ workload. On a developer laptop without that workload, a bun install can fail at the native build step, and the fix is either to install that build tooling or to switch to npm or pnpm. Teams that standardize on bun should make an exception here.

The Node floor is also strict. With an older Node release the package's engines constraint is not met, so check the runtime on CI images and shared machines before rolling OpenWiki out, not after the first failed run.

openwiki link turns several repositories into one searchable workspace

The newest addition is linked wiki workspaces. openwiki link groups related repositories so you can search across their wikis, and agents can read relevant sections through MCP. For a service split across a front end, an API and a shared library, that means the agent working in one repo can pull context documented in another without you pasting it in.

The retrieval side is separate from generation. Pi, for example, loads OpenWiki's skill, four read-only retrieval tools and six lifecycle tools from the npm package. Read-only tools let an agent consult the wiki without being able to rewrite it, which keeps question answering and documentation updates as distinct steps.

Scheduled updates ship as CI examples, and releases move fast

Keeping the wiki current is meant to happen in CI. The examples/ directory carries openwiki-update.yml, openwiki-update-auto-merge.yml, openwiki-update.gitlab-ci.yml and openwiki-update.bitbucket-pipelines.yml, including GitLab CI and Bitbucket Pipelines variants. Read whichever matches your host before enabling the auto-merge variant, since an auto-merged documentation change lands without a human review.

Under the hood, the package describes itself as a CLI that uses a DeepAgents documentation agent, built on LangChain's deepagentsjs. The project ships often: v0.7.1 on 2026-10-06, v0.7.2 on 2026-10-09 and v0.7.3 on 2026-11-02, with the last push to main on the same date. The repository keeps an evals/ directory with a ledger evaluation suite and a CHANGELOG.md managed through changesets. Pin a version for CI jobs so a release does not change wiki output between runs.

Editorial conclusion

OpenWiki fits teams that already use Codex, Claude Code, Cursor or another supported agent and want repository documentation that agents can query over MCP and that updates from what changed. It is the wrong tool if you want connector-sourced context such as LangSmith inside host-driven runs, or a personal knowledge base built through your agent, since host runs cover repository code wikis only. Check that your machines have Node.js 22.22.0 or newer, and on Windows install with npm or pnpm rather than bun.

Frequently asked questions

Official sources

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