NeverWrite puts a Markdown vault, AI agents and hunk-level review in one desktop app

A vault that holds the agent session, not just the agent output

NeverWrite describes itself as an agentic markdown workspace, and the distinction matters for how the app is laid out. The project summary calls it a local-first workspace for writing and thinking with AI agents, and the README frames it for people who work with local vaults and several agents at once. The application is a multipane desktop app: the vault, the documents, the agent sessions, the review queue and the research material all sit in the same window rather than in separate tools stitched together by copy and paste.

That framing puts it somewhere between a plain Markdown editor and an agent runner. The editor is where you compose; the sessions are where an agent composes; the review surface is where the two meet. The app also treats the vault as the unit of storage, so an agent that edits a note edits a file you already had open and already versioned in your own habits.

The interesting audience is narrower than the feature list suggests. If you have no local Markdown corpus, there is little to make a vault aware. If you already juggle an editor, a terminal agent, and a diff tool, the pitch is that those three loops collapse into one surface with the agent's changes tracked rather than silently applied.

One editor for Mermaid, CSV, PDFs, images and Excalidraw maps

The editor is not Markdown only. The README lists Markdown, Mermaid, CSV, text and code files, PDFs, images, and Excalidraw concept maps as formats you can edit in the same workspace, which is a broader surface than a typical note editor.

Two of those deserve attention. Mermaid is diagram-as-text, so keeping it in the same editing model means a diagram stays diffable and searchable alongside prose. Excalidraw maps are a different matter, since a concept map is normally a binary drawing file rather than text you can diff, so the review model described later cannot apply to those bytes in the same way it applies to text hunks.

PDFs and images sit at the edge of the editable set. Being able to open them next to your notes matters when the vault is also a research archive, where a saved paper or a screenshot is part of the working material. The README does not say how editing behaves for these formats, so treat them as viewable attachments rather than assume rich editing support.

For CSV, the same caution applies in reverse. A comma separated file is plain text, so it can be edited and reviewed, but a CSV in a vault is usually data rather than prose, and the review surface has no notion of a spreadsheet cell.

Wikilinks, backlinks, tags and a graph view over the same files

Knowledge navigation is a listed feature set: wikilinks, backlinks, tags, advanced search, bookmarks, and both 2D and 3D graph views. Every one of these operates on the vault, which means the index has to be rebuilt or kept current as files change.

The repository layout backs this up. The Cargo workspace declares members named crates/types, crates/vault, crates/index, crates/diff, crates/ai, and apps/desktop/native-backend, so there is a dedicated index crate sitting between the vault layer and the rest of the system. A vault crate owns the files, an index crate derives the link and tag relations, and a diff crate handles change computation. The graph views are then a rendering of what the index already knows.

That is a sensible separation, and it also explains where the cost sits. Indexing has to keep up with edits made by you and by agents at the same time. The README does not describe how the index handles a file being changed underneath it, so if you are going to run an agent that rewrites many files at once, that is the first behaviour you should check yourself.

Tags, bookmarks and advanced search are useful for a large vault, and less useful if your notes are few, since they mostly add vocabulary around plain file listing.

Codex, Claude, Grok, Kilo, OpenCode and Pi in one session list

Agent choice is a first-class decision in the app. The README says you can run Codex, Claude, Grok, Kilo, OpenCode, or Pi sessions, with attachments, saved transcripts, and local history kept alongside your vault. Transcripts are saved locally, which means a session can be revisited later without asking a provider to reconstruct it.

The Pi case is the informative one because it shows where the integration boundary sits. For Pi, NeverWrite bundles the ACP adapter, but the Pi CLI still has to be installed separately, with its models and credentials configured through Pi itself, as the README points to its AI Runtime Setup notes. Other providers need their own CLI login or an API key configured in the app settings.

So the agent layer is a set of adapters over tools you already have accounts and credentials for, not a hosted service. That is a reasonable design for a local-first product, and it also means the setup burden lands on you. Providers with an official command line interface are straightforward; the ones that expect a GUI login are where the friction lives, and the README does not enumerate which providers fall in that second group.

The Cargo workspace lists an exclude entry for vendor/codex-acp, and the repository root contains a vendor directory. A vendored adapter is usually there because an upstream dependency was pinned or patched, which is worth knowing before you upgrade that dependency yourself.

Tracked edits you keep or reject one hunk at a time

The change review model is the most distinctive part of the project. The README describes inspecting tracked edits inline, in chat, or in a dedicated review tab, and then keeping or rejecting complete files and individual hunks. Granularity at that level is what makes an agent usable on notes you care about, since a single agent pass can rewrite a paragraph you wanted and leave the rest alone.

There is a dedicated crates/diff member in the Cargo workspace, so change computation is a distinct Rust component rather than something bolted onto the editor. That separation is what allows the same change set to be shown three ways: inline while you read, in the conversation where the agent explained itself, and in a review tab where you process a batch.

The three views matter for a different reason too. Inline review is for the single edit you are making right now, chat review gives you the agent's reasoning next to the change, and the review tab is for queueing up a larger batch. If you work with agents that produce many small changes across many files, the batch tab is the part you will lean on.

Note the boundary: hunk-level keep and reject applies to text. A file the agent rewrote wholesale, or an Excalidraw map it redrew, can only be kept or rejected as a whole file. The vault's non-text formats are outside the fine-grained model.

Building the native backend from a local clone

There is no published install command for the desktop app in the README beyond platform requirements, so the supported path in the documentation is a local run. Requirements are macOS 13 or later, Windows, or Linux on x64 or ARM64, plus Node.js 22.12 or later with npm, Rust and Cargo, and pnpm 10.33.0 for the web clipper.

The run sequence is short:

git clone https://github.com/jsgrrchg/NeverWrite.git
cd NeverWrite/apps/desktop
npm install
npm run dev

The first start builds the native backend, so expect a Rust compile before the window appears. After that you configure your preferred agent in the app settings.

The project's own checks are grouped by component, and each one runs in a different subdirectory with a different toolchain:

cd apps/desktop && npm test
cd apps/web-clipper && pnpm check
cargo test

If you are evaluating the project, the Rust test run is the one that tells you most about the vault, index, diff and AI crates. The clipper check needs pnpm 10.33.0 specifically, which is a narrower constraint than the other requirements.

Dev and installed releases share one vault, which is both feature and trap

Local development runs under the name NeverWrite Dev with its own application profile, so an installed NeverWrite release can stay open at the same time. The README is explicit about the consequence: files and hidden state inside a vault remain shared when both variants open that same vault, and the advice is to use a disposable vault when testing write or review flows concurrently.

That is a genuine dual use of the app, and also a genuine data hazard. Two processes writing review state and hidden metadata into one vault can interleave in ways neither was designed for, so testing an agent write against your real notes is the case to avoid. Copy a scratch vault and point the Dev profile at that.

The second caution is provider setup. The README notes that some providers require their own CLI login or API key, and for Pi specifically you install the Pi CLI separately and configure models and credentials through Pi. Nothing in the app abstracts that away, so the practical cost of adding a second agent is a separate login flow per provider.

There is a third small thing worth knowing: the repository contains an ETHICS.md and a Copyright.md alongside the code, which is unusual enough to be worth reading before you decide how you want to use the output.

Editorial conclusion

NeverWrite fits writers who already keep a local vault of Markdown files and want agent work reviewed before it lands, and it fits teams that need to see which lines an agent changed rather than trusting a rewritten file. It is the wrong tool for anyone who wants a hosted, collaborative editor, for people who do not already own a vault of local files, or for anyone unwilling to install a Rust toolchain and wire up provider CLIs and API keys. Before committing, verify three things on your own machine: that the desktop build starts on your platform, that your chosen provider logs in through the CLI or key that NeverWrite expects, and that the browser clipper can write into the same vault without fighting the app for the file.

Frequently asked questions

Official sources

1. jsgrrchg/NeverWrite on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases