Hanji

Paper-thin documentation tool

Your agents already live in GitNow your knowledge does too

Write and search Markdown. Review agent edits. Keep your files in your own Git repository.

  • Open source
  • Self-hosted
  • MCP access
Read the handbook
See how it works

Read. Review. Merge.

handbook / how-we-work.md

How we work

A shared handbook for product decisions, project notes, and team guides.

HandbookMarkdownGit-backed

Record a decision

  • Describe the problem and the options.
  • Choose an owner and a next step.

Make it easy to find

Link new guides from this handbook.

Interactive example · try Merge⑂ main · handbook/how-we-work.md

MARKDOWN EDITOR

Edit Markdown.
Keep clean Git diffs.

A one-word fix. A one-line diff. Nothing else touched.

WHAT YOU EDITdecisions.md

Make the next right thing
easy to find.

One word changed. Update.

WHAT GIT SEES+1 −1
− Make the next thing easy to find.
+ Make the right thing easy to find.

Ada · Update decisions.md

How byte-preserving edits work

AGENT PROPOSALS

Review the diff.
Approve the change.

Agents submit proposed edits with an explanation. You review the diff before merging it into your pages.

claudeClarify the review owner+2 −0

Added an owner so each incident review has someone responsible.

+ ## Review owner+ The incident lead writes the review and shares it with the team.

THE DEPENDENCY THAT ISN’T

NO METER RUNNING
0

Built for agents.
Runs without one.

Your agents are welcome guests, never a dependency. No API key in the setup. No model picker in the settings. Nothing stops working when the tokens run out.

Because there are no tokens.

0 bundled models0 AI credits100% your Markdown
A NOTE TO READING AGENTSPrefer the text? We kept that for you, too.llms.txt

ACCESS CONTROL

Set permissions.
For people and agents.

Private stays private. For people and agents alike.

Choose a reader. See what remains.

FIELDNOTES / PAGES4 visible
How we workhandbook / how-we-work.mdEveryone
Architectureengineering / architecture.mdTeam + agent
The next chapterplanning / next-chapter.mdAda + Remy
A work in progressprivate / rough-thoughts.mdOnly Ada

Ada owns this workspace. All four pages are visible.

Hanji controls app access. Repository access still exposes the files.

COMMENTS & HISTORY

Discuss changes.
Track contributions.

Comment on a page. See who changed it.

FROM THE HANDBOOK

Open the note in the margin.

Page comments.
Stored outside Git.

Comments stay out of git. Agents read them only with permission.

Read about comments
THE PAPER TRAIL

People above. Agents below. Eight weeks of work.

People Agents
8 weeks agoToday

A quiet day writes nothing at all.

CHOOSE YOUR WORKFLOW

Find the right tool
for your knowledge.

Different tools. Different jobs. Find your fit.

The difference is in the foundation.

FIVE TOOLS / DIFFERENT JOBS
Compare Hanji’s purpose, content, git workflow, and agent access with other knowledge tools.
What matters
to you?
HanjiYOUR KNOWLEDGE, YOUR GITObsidianTHE PERSONAL VAULTNotionTHE ALL-IN-ONEConfluenceTHE TEAM WIKI · CLOUDGitBookTHE DOCS SITE
Made forTeams + their agentsPersonal knowledgeDocs + projects + databasesAtlassian-connected teamsPublished documentation
Your contentMarkdown filesMarkdown filesPages + databasesPages + spacesDocs + optional Git Sync
Git’s roleThe source of truthBring your own workflowMarkdown via exportContent via exportTwo-way repository sync
Agent accessScoped MCPEdits proposed as git diffsLocal filesConnect your own toolsNotion MCPConnect external assistantsRovo MCPConnect external assistantsPublished-site MCPDocs for agent readers
Keep in mindEarly. Self-hosted.SSO + hosted service still aheadShared vault, shared access.No per-page grants in SyncThe workspace is Notion.Markdown is an exportThe workspace is Confluence.Not a Markdown repositoryPublishing comes first.A different focus from Hanji

Your files. Your agents. Your call.

Find your fit
Sources & scope Checked September 9, 2026

Our assessment of fit, based on the official documentation below. Confluence refers to Cloud. Features and access can depend on plan and configuration; extensions can add other workflows.

DEPLOYMENT

Run locally.
Share on your terms.

Local. Shared. Published. Your choice.

All four are part of the first release.
01Just you, locally

Open Hanji and a welcome screen does the wiring: your name for the place, your password, your folder of Markdown.

# public with the release:
git clone https://github.com/gethanji/hanji
pnpm install && pnpm dev:web
The five-minute start
02Your team, on a tailnet

One shared instance where the network signs people in. Nobody types a password. Their permissions stay exactly as you set them.

export HANJI_TAILSCALE_OWNER=you@github
next start -H 127.0.0.1 -p 4100
tailscale serve --bg 4100
Run on your tailnet
03With your coding agents

Scoped reads over MCP or plain HTTP. A bash script with curl counts as an agent. Edits arrive as proposals, ready for your decision.

pnpm hanji token my-claude notes=read+propose
# Connect your agent with the returned token.
Give your agent a key
04Published to the web

Everything you’ve opened to everyone, as a static website. A Markdown mirror and llms.txt come along. The handbook is published this way.

pnpm hanji rule handbook everyone-read
pnpm hanji export ./site
Make a little of it public

RELEASE UPDATES

Get the release note.
Start when it ships.

Follow the build. Be there when the code is yours to run.

A few letters a year. What shipped, what we learned, and the day Hanji is ready. Unsubscribe anytime.

Meanwhile, there’s plenty to read