Reflect Open: a Markdown graph with a Tauri desktop shell and a CLI for agents

The problem is note apps that own your data, not the note-taking itself

Most note tools store your writing in a database only they can read. Export exists, but it is a one-way door: you get a snapshot, not a working directory. Reflect Open inverts that. A notes folder is called a graph, and the README describes it as a folder you can inspect, back up, sync, or edit with other tools. The repository layout it gives is concrete: daily/2026-06-12.md for daily notes named by date, notes/some-title.md for other notes named from their titles, assets/ for images and attachments, and audio-memos/ for recordings and transcripts. The README states plainly that Markdown files are the source of truth, and that Reflect adds search, backlinks, tags and related notes on top while the files remain usable in any Markdown editor.

The target user is narrower than a general note-taking audience. This is for someone already on Apple hardware who wants daily notes that open by default, [[wiki links]] between people and projects, and a search box that does not require a server. The agent angle in the repository description is real but modest: the CLI exposes reflect today, reflect search and reflect show, and the README frames those as being for scripts and agents. If you have ever wanted a language model to read your notes without exporting them into a vector store first, that is the gap this fills.

A Tauri shell over a shared TypeScript core, with a Rust index schema

The architecture is visible in the monorepo layout. Reflect Open is a pnpm and Turborepo workspace. apps/desktop holds the Mac and iOS app, apps/cli holds the reflect command, apps/extension holds the Chrome capture extension, and apps/native-host is described as a browser capture helper. Shared logic sits in packages/core, database types and helpers in packages/db, and the index schema in a Rust crate at crates/index-schema. There is a design-system directory for tokens and UI primitives.

That split explains the build prerequisites. You need a recent stable Rust toolchain, Node.js with pnpm 10, and Xcode Command Line Tools. The desktop app is a Tauri application, which is why the Rust crate for the index schema is shared rather than living inside the desktop app. The data flow implied by the layout is: Markdown files on disk are read and indexed, the index schema defines what the search and backlink layer can query, and the TypeScript core mediates between the file system and both the desktop UI and the CLI. The README does not document the indexing algorithm, the index file format, or where the index is stored, so treat the performance characteristics of search as unverified. What can be confirmed is that search is described as local, and that optional semantic search can be enabled locally, which means the default path does not require a network call.

Getting it running: prebuilt DMGs, TestFlight, and a pnpm workspace for source builds

The fastest path is a prebuilt Mac app. The README links a stable Apple silicon DMG, a stable Intel DMG, and equivalent beta builds under the updater-beta release tag. Each build is described as signed, notarized, and auto-updated from GitHub Releases. The iOS beta goes through TestFlight at a join link the README provides, and the iOS app is stated to use the same plain-file graph and sync options as the Mac app. Browser capture is a separate Chrome Web Store extension called Reflect Capture, which saves the current page, selected text, screenshots, and optional page text.

Building from source is a short sequence from the repository root. Clone the repository, enter the directory, run corepack enable, then pnpm install, then pnpm tauri dev for development or pnpm tauri build for a release build. The development section lists pnpm dev for Vite alone on http://localhost:1420, pnpm typecheck, pnpm lint using oxlint, pnpm test using vitest, and pnpm check for typecheck plus lint. One detail worth flagging: the README notes that Rust tests which compile the desktop crate need sidecars staged first, via pnpm --filter @reflect/desktop sidecar, before cargo test --workspace. For iOS, pnpm tauri:ios:dev takes a simulator name such as "iPhone 17 Pro", and TestFlight builds go through pnpm release:ios preflight and pnpm release:ios testflight with a --build-number flag and an optional --wait.

Configuration is mostly done in the app rather than in a config file, based on the README. Sync is either iCloud Drive, by placing the graph in a folder such as iCloud Drive/ReflectGraph, or git, by connecting GitHub in the app or adding any SSH git remote as described in docs/generic-git-remotes.md. AI is opt-in through user-provided OpenAI, Anthropic, Google, or OpenRouter keys, triggered by a keyboard shortcut. A per-note frontmatter flag, private: true, excludes that note's content from AI and other external services.

The privacy model is a set of switches, not a guarantee

The README is careful about this and the care is warranted. By default, note content stays on the device. External calls only happen after you configure a provider, connect a git remote, or use a platform sync service. That is a clear statement of the trigger conditions, and docs/privacy.md is cited as the full model.

The practical consequence is that privacy here is a function of your configuration, not a property of the software. The moment you paste an API key into the AI settings, note content can leave the machine when you invoke the query shortcut. The private: true flag is the per-note escape hatch, and it is worth understanding that it is a content-level exclusion, not an encryption feature. If a note contains a credential and you forget the flag, the exclusion does not apply. There is no mention in the README of a local model option, so the AI path is provider-based by construction. Teams with data residency requirements should read docs/privacy.md before enabling anything, and should treat the git remote as a data export decision rather than a backup convenience.

Beta cadence, Apple-only scope, and no plugin API

The release history shows a tight beta rhythm: v0.12.0-beta.2, beta.3 and beta.4 all landed within roughly two days in September 2026, and the repository was pushed on the same day as the last release. Frequent beta releases on a project that is explicitly in beta means you should expect churn in the app layer. The README says Reflect is in beta and used daily, and that the current focus is the Mac app, iOS companion, browser capture, the local-first data model, and sync reliability. That focus list is effectively a statement of where bugs will and will not be fixed.

The scope boundary is stated directly: Windows, Android, and a plugin API are out of scope for now. For a note app, the missing plugin API is the sharper limitation. There is no documented extension point for adding a custom view, a custom index field, or a new capture source beyond the Chrome extension. If your workflow depends on scripting the app itself rather than the files, the CLI is the only surface, and it exposes three subcommands. That is a small API. The absence of Windows and Android also means the plain-file promise is only fully realized on hardware you already own; the files travel, the app does not.

One more thing the README does not cover: conflict handling. With iCloud Drive or git as the sync layer, the merge semantics are those of the underlying tool. The README does not describe how Reflect Open resolves a conflict between two devices editing the same daily note, and that is the question to ask before putting the graph on two machines.

Obsidian is the obvious comparison, and the difference is where the app ends

The closest alternative in this space is Obsidian, which also stores notes as Markdown files in a folder, also supports [[wiki links]] and backlinks, and also runs locally. The difference in approach is the boundary of the application. Obsidian's core bet is the plugin ecosystem: a large community API that lets third parties add views, editors, sync backends and integrations. Reflect Open has no plugin API and the README says so. What it offers instead is a first-party CLI, reflect today, reflect search and reflect show, aimed at scripts and agents, plus a Chrome capture extension and a native host helper shipped in the same monorepo.

That is a real trade. If your needs are covered by the built-in feature list (daily notes, wiki links, backlinks, local search, optional semantic search, AI queries with cited source notes, audio memos with transcription, browser capture, iCloud or git sync), the absence of plugins costs you nothing and you get a smaller, more coherent surface. If you need an integration nobody has built yet, Obsidian's API is the reason to stay. The other difference is platform: Obsidian ships on Windows and Android, and Reflect Open does not. A third option worth naming is simply a folder of Markdown plus a text editor and ripgrep, which is what Reflect Open is layered on top of; the app is buying you the index, the backlink graph and the capture paths, not the file format.

Maintenance cost and what the MIT licence actually settles

The licence is MIT, which is permissive and places few obligations on you: keep the copyright notice and the permission notice with any substantial portion you redistribute, and understand that the software comes without warranty. That is the extent of what a licence file settles, and it says nothing about whether the project will keep shipping. This article is not legal advice; if you plan to redistribute a modified build, read the LICENSE file in the repository.

Maintenance cost is the more practical question. Running from source means tracking a pnpm workspace with a Rust component, which is a heavier toolchain than a single-binary note app. You need Rust, Node with pnpm 10, and Xcode Command Line Tools just to build, and the Rust test suite requires sidecars staged before cargo test will compile the desktop crate. Prebuilt DMGs avoid that entirely and auto-update from GitHub Releases, which is the lower-effort path for most users. The upgrade risk is the beta channel: with three beta releases inside about two days, pinning to a specific tag rather than tracking latest is the only way to keep a working graph stable while the app layer moves. The files themselves are the hedge. Because Markdown is the source of truth, abandoning the app costs you the index and the UI, not the notes.

Editorial conclusion

Adopt Reflect Open if you want a Mac and iOS client over a folder of Markdown files you already control, and you are comfortable running beta builds. Do not adopt it if you need Windows or Android, or if a plugin API is a requirement, since the README states those are out of scope for now. Before committing, verify two things against your own graph: that the daily/ and notes/ naming convention matches how you already name files, and that docs/cli.md documents the reflect today, reflect search and reflect show subcommands you intend to script against.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. team-reflect/reflect-open on GitHub