Dex: a personal vault that plugs into an AI app, with a support matrix that admits what is missing

Two license documents at the root, and the metadata field says NOASSERTION

Two licensing documents sit at the top of the repository: a `LICENSE` file and a `COMMERCIAL_LICENSE.md`. The repository's license metadata reports NOASSERTION, which is the value GitHub uses when it cannot map a detected license file to a known identifier, and in this case it also reflects a tree holding two documents rather than one.

Nothing visible on the project page resolves it. There is no statement of which grant applies to the source, whether the commercial document replaces or supplements the standard one, or what the trigger for the commercial terms is. A reader who needs to know whether a commercial use needs a separate agreement has to read both files and decide for themselves, and this page does not summarize either.

That is worth flagging rather than glossing over, because the product is distributed rather than consumed as a library. Install scripts are fetched, a vault is written into your documents folder, and background jobs are installed, so the terms matter more here than they would for an importable dependency.

Two related documents exist alongside them. `CONTRIBUTING.md` covers incoming work and `CHANGELOG.md` tracks changes, and the version history is unusually granular, which is the next thing worth looking at.

Mac pipes install.sh from the network, Windows says review it first

The two supported install paths have different trust postures, and the difference is deliberate. On a Mac:

curl -fsSL https://heydex.ai/install.sh | bash

On Windows through Git Bash:

git clone --branch release --single-branch https://github.com/davekilleen/dex.git Dex
cd Dex
bash ./install.sh

The Mac line fetches a remote script and executes it without a review step. The Windows instructions instead say to clone the official release branch, review `install.sh`, and only then run it from that folder. The guidance also notes that Git Bash ships with Git for Windows, so there is nothing extra to install, and gives one hard prohibition: do not pipe a remote script into `iex`.

So the PowerShell equivalent of the Mac one-liner is explicitly off the table, and `install.ps1` exists in the tree as a file to read and run rather than to pipe. A reviewer will notice that the curl pipe is exactly the pattern the Windows section warns against, applied to the other platform.

Either way the installer checks prerequisites and prepares `Documents/Dex`, and the page says to review its prompts before approving changes.

Three rows of the Windows support table read Not yet

Windows support is not a yes or no. It is a per-feature table, and the honest rows are the interesting ones. Install through Git Bash is marked Preview, working on a clean Windows 11 with python.org Python 3.12 or 3.13. First setup and daily use, covering notes, tasks and MCP tools, is also Preview.

Then the rows stop being previews. `/dex-update` and `/dex-rollback` are listed as Not yet, with a fix in progress for how Dex read and wrote its own record files on Windows. Connected-service keys in `.env` and trusted local MCPs are Not yet as well, with Windows file-permission checks in progress. Migrating an older vault from before v1.80 to the current update engine is marked Not on Windows at all, with the instruction to start from a fresh install.

Two rows are Mac only: calendar, background meeting sync, and launch-at-login jobs. And the supported environment is spelled out negatively too. Git Bash with python.org Python 3.12 or 3.13, and explicitly not Cygwin, not Microsoft Store Python, and not WSL folders under `/mnt`.

In short, a Windows user gets the app and its notes but not the update engine, the connected services, or a path from an old vault.

The repository root is the starter vault, .obsidian/ included

The top-level entries explain what gets installed. Eight numbered folders sit directly in the repository root: `00-Inbox/`, `01-Quarter_Goals/`, `02-Week_Priorities/`, `03-Tasks/`, `04-Projects/`, `05-Areas/`, `06-Resources/` and `07-Archives/`, alongside a `System/` directory.

Those names are a PARA-style structure with a quarter and week layer added at the front, and being in the repository rather than in a template means a fresh install produces a vault that is already populated with the intended hierarchy. There is no scaffolding step to describe.

`.obsidian/` is committed too. That means the editor configuration ships with the kit, so a new vault opens with the intended settings instead of defaults. It also means anything an individual adds to their editor settings becomes something they might accidentally push.

The rest of the root is agent configuration rather than content: `.claude/`, `.cursor/`, `.agents/`, plus `CLAUDE.md` and `AGENTS.md` side by side, so the instructions exist in two conventions. Tooling is doubled too, with `install.sh` and `install.ps1`, `package.json` and `package-lock.json` next to `pyproject.toml`, `requirements.txt`, `requirements-dev.txt` and `uv.lock`. There is a `.distignore` and a `DISTRIBUTION_READY.md`, which suggests the difference between the git checkout and the shipped package is a tracked state rather than a branch.

Unavailable is one of four connection modes

The bridge between an app and the vault is described with four modes, and the fourth is the one most documentation would leave out. Automatic means a configured and trusted app event runs the behavior. On demand means you ask for a registered tool or skill. Guided means Dex explains the steps that still need your participation. Unavailable means the installed surface cannot deliver that behavior at all.

Two qualifiers keep the model honest. The modes describe individual features rather than whole apps, so a capability being Automatic in one tool says nothing about the app as a whole. And a package manifest or a saved app selection is not proof of a working session.

The same restraint appears earlier. Installing a plugin does not create a vault, connect accounts, start background jobs, or prove that every workflow works in that app. And when a capability is missing, the guidance for the first useful result is to ask Dex which sources it can read, with the expectation that it names the missing ones rather than implying it checked them.

The practical consequence is that capability is per feature, per app, and per platform, which is why three separate tables in the page are needed to describe one product.

Privacy covers your files, not what your model provider receives

The privacy section opens with where the data lives and immediately narrows the claim. Your notes live in your vault, which is a folder you own. Then the qualification: that does not mean all processing stays on your computer. Your AI app may send the context it reads to its model provider, and optional integrations contact their services.

So the guarantee is about storage and access, not about inference. The stated boundary is that you grant access to the folder and the services you intend to use, and that a local plugin does not grant a web app access to your files. That is the difference between a plugin with folder permission and a hosted product reaching into the same folder, and the page draws it deliberately.

The update service is described separately: it previews product changes and protects personal content through ownership rules. Feedback is reviewed before being sent, under a configured consent policy, and the page is explicit that app permissions and diagnostic metadata do not establish who you are or authorize wider access.

Leaving is symmetric with joining. Close the session, revoke folder access or disable the plugin, and keep the vault if you want the notes. What does not stop is the catch: removing an app or plugin does not stop independently installed background jobs, and new-app removal instructions are still pending native verification.

Three model SDKs ship even though the app and the model are separate choices

The Node package is private, named `dex-pkm`, described as a personal knowledge management system, and versioned in step with the repository. Its runtime dependencies include SDKs for three model providers at once: `@anthropic-ai/sdk`, `@google/generative-ai` and `openai`, alongside `dotenv`, `js-yaml` pinned exactly, and `@nangohq/providers` pinned to an exact version.

That sits oddly against a central product claim, which is that the AI app and the model it uses are separate choices with their own subscriptions and usage limits. A tree carrying three provider SDKs is either supporting multi-provider calls directly, or carrying weight for a path the documentation treats as secondary. The page does not say which.

The scripts tell a clearer story about what actually runs. Three variants of a meeting sync exist, `meeting-sync`, `meeting-sync:dry-run` and `meeting-sync:force`, all invoking the same script with different flags, and that script is named for syncing from Granola, a separate meeting notes application. So background meeting sync depends on a third-party app, which lines up exactly with the support table marking it Mac only.

Testing is split four ways: hooks, scripts, integrations and a connections contract check that also verifies a generated engine manifest.

Five Python requirements, one of them a scraper, and daily 1.97.x releases

The Python side is unusually light. `requirements.txt` carries five real entries and comments out three more. Core MCP functionality is `mcp` at 1.0 or above and below 2.0. Configuration and data handling add `pyyaml`, `python-dateutil` and `requests`. Then one line stands apart:

pip install -r requirements.txt

`scrapling[ai]` at 0.4.1 or above, filed under web scraping with the note that no API key is required. That is the entire install for the plugin, and the three commented entries are the Google auth stack, left in place as an opt-in for anyone wiring those services themselves.

Compare that to the release cadence, which is where the effort is going. Three tags, `v1.97.24` on 2026-09-30, `v1.97.23` on 2026-09-29 and `v1.97.22` on 2026-09-28, one per day, with the last push to the default branch on 2026-09-30. A minor component sitting at 97 is unusual for a project with this shape, and it means the version number itself is not going to tell you much about scope.

The Python tooling reflects a CI story too. Coverage is set to relative paths so shards recorded on macOS runners can be combined on a Linux aggregator, and pytest defines a `windows_supported` marker gated on the platform name, next to a nightly `fuzz` marker for the slower property-based cases.

Editorial conclusion

Dex is for people who already live in an AI coding app and want their notes, priorities and people records to stay in a folder rather than inside that tool. Read the support matrix before picking a platform, because the accurate answer is that Windows covers install and daily use in preview while updates, connected-service keys and older-vault migration are not yet supported there, and calendar plus meeting sync are Mac only. Decide which app you are committing to, since hooks do not travel between apps and Doctor is missing from the portable plugin. And settle licensing yourself: two license documents sit at the root while the metadata field reports NOASSERTION.

Frequently asked questions

Official sources

1. davekilleen/Dex on GitHub
2. Issues
3. README
4. Releases