OpenKnowledge bets your notes belong in the same context window as your code

What happened

Inkeep — the docs-search company — dropped OpenKnowledge on Show HN today and the post is sitting at 232 points. It's a WYSIWYG markdown editor (MacOS app + CLI), MIT-ish OSS on GitHub at `inkeep/open-knowledge`, with the explicit framing of being an "AI-first alternative to Obsidian and Notion." The differentiator isn't the editor surface — markdown editors are a saturated genre — it's the integrations: direct, named hookups to Claude Code, Codex CLI, and Cursor.

The storage model is the part worth reading twice. Notes are plain `.md` files on your local disk. There is no proprietary database, no sync server, no account. The Claude/Codex/Cursor integrations work because those agents already know how to read files in a directory — OpenKnowledge just makes the directory feel like a real notes app on top.

The shipped artifact is small; the bet underneath it is large: that the next generation of knowledge tools will be judged by how well an LLM agent can read them, not by how pretty the UI is for a human. Obsidian got this half-right years ago with its "files on disk" stance, but its plugin ecosystem still treats AI as a bolt-on. Notion went the other direction — beautiful UI, proprietary blocks, and an AI feature that can't see anything outside Notion's walls. OpenKnowledge is the first launch I've seen that treats "my coding agent can grep my notes" as the headline feature rather than a footnote.

Why it matters

There's a quiet architectural shift happening in how senior devs are organizing their working memory. A year ago, the typical setup was: Notion or Obsidian for notes, a separate repo for code, and a Claude/ChatGPT tab that knew about neither. The cost of that separation was hidden — you paid it every time you re-explained your project's conventions, your past decisions, your half-finished ADRs.

Coding agents have collapsed that separation by accident: Claude Code, Codex, and Cursor all read whatever files are in the working directory, which means a `notes/` folder next to `src/` is now a first-class context source for free. Once you notice this, the question stops being "which notes app has the best AI features" and starts being "which notes format does my agent already understand." Markdown wins that fight without trying.

The HN comments are split in a predictable way. The Obsidian camp asks the obvious question — why not just point Claude Code at an Obsidian vault, since that's already markdown on disk? The honest answer is: you can, and people do. OpenKnowledge's wedge is the WYSIWYG editor (Obsidian's source-mode toggle is famously fiddly) plus the explicit, documented integration surface. The Notion camp is mostly silent, which tells you something about who this is aimed at.

The deeper signal is that Inkeep — a company whose entire business is RAG over docs — looked at the problem and concluded the answer wasn't a better retrieval pipeline but a better substrate. That's worth sitting with. When the people building production RAG systems start shipping local-first markdown editors, it's evidence that the agent-reads-files pattern is eating the embed-and-retrieve pattern for personal-scale knowledge. Embeddings still win at scale, but for the 200-file scope of one developer's working notes, an agent with a `find` command and a 200k context window is faster, cheaper, and weirdly more accurate than a vector store.

The CLI bit matters too. A MacOS app is table stakes for the consumer pitch; a CLI is the tell that the team expects this to be scripted into workflows. Think `ok new` from a git hook after a commit, or piping `git log` into a daily note. That's not a Notion use case. It's barely an Obsidian use case. It's the use case of someone who already lives in a terminal and wants their notes to participate in the same shell pipelines as their code.

What this means for your stack

If you're running Claude Code or Codex against a repo every day, the lift to try this is roughly zero. Clone the repo, add a `knowledge/` directory at the root, point the editor at it, and your existing agent invocations now see your notes as part of the project context. The interesting test isn't whether you like the editor — it's whether, after a week, your agent prompts get shorter because the context is already on disk. That's the metric that matters.

For teams: this format works for individual knowledge but is a worse fit for shared knowledge than Notion or Confluence, because there's no real-time multi-user editing story and no permissions model. Don't try to migrate your company wiki. Do consider it for the per-engineer scratch space that currently lives in a chaos of Apple Notes, Obsidian vaults, and `~/notes.md` files — the stuff your agent should see but currently can't.

The license and OSS posture also matter for the paranoid. If your shop has a policy against shipping internal notes through a third-party AI sync service, a fully local markdown vault with no cloud component is the cleanest answer. The agent calls still hit Anthropic or OpenAI, but the notes themselves never leave the laptop unless you commit them.

Looking ahead

The Obsidian-vs-Notion debate is about to be replaced by a quieter one: which knowledge tools your agent can read, and which it can't. Tools that store data in proprietary formats — even pretty ones — will quietly lose ground to tools that store data in formats an LLM already understands. OpenKnowledge probably isn't the winner of that shift; it's the first credible Show HN that names it out loud. Expect a wave of "AI-native" forks of every existing note-taker over the next six months, and watch which ones treat the agent as a guest in a markdown directory versus which ones treat it as a feature inside a walled garden. The first group is going to win.