Cabinet (cabinetai/cabinet): a markdown knowledge base with AI agents that remember

The problem Cabinet targets: AI sessions that forget your project

Cabinet's README states the problem directly: every new Claude session starts blank. Project context, decisions and research from the previous session are gone, and the workaround is copy-paste between a notes app and a chat window. The project's answer is to make the knowledge base the source of truth and give the agents a place to read from and write to.

The intended user is a small team or a solo founder who is already comfortable with files, git and a terminal. The README describes Cabinet as an "AI-first startup OS" and the package description calls it "an AI-first, self-hosted knowledge base and startup OS. Your files, your agents, on your machine." The repository layout backs that up: a Next.js app in src/, a daemon in server/, an Electron shell in electron/, an MCP directory, and CLI code in cli/ and cabinetai/. This is not aimed at someone who wants a browser tab and a signup form.

How Cabinet works: a Next.js app, a daemon, and plain files

The package scripts show the runtime shape. npm run dev:all runs two processes concurrently: npm:dev starts the Next.js app, and npm:dev:daemon runs tsx server/cabinet-daemon.ts. The production equivalent is npm run start, which runs next start alongside the same daemon script. The daemon is a separate process, not a library inside the web app, which is why the environment example exposes CABINET_APP_PORT, CABINET_DAEMON_PORT, CABINET_APP_ORIGIN and CABINET_PUBLIC_DAEMON_ORIGIN for cases where Cabinet is embedded in Electron.

Storage is the part that matters most. The README says everything lives as markdown files on disk, there is no database, and your cabinet directory is just a folder of markdown files that you can put anywhere. CABINET_DATA_DIR overrides the shared data directory, defaulting to ./data for source installs or a managed app-data path in Electron. The editing layer is Tiptap, described as WYSIWYG plus Markdown with tables, code blocks and slash commands.

Agents are the second half. Each agent has goals, skills and scheduled jobs. Skills can be browsed from skills.sh or any GitHub repo, attached per agent, or @-mentioned in the composer to scope a skill to one task. Scheduled jobs are cron-based: the README gives a Reddit scout every six hours and a weekly report on Monday as examples. There is also an embedded HTML app mechanism: drop an index.html into any folder and it renders as an iframe with a full-screen mode. A web terminal provides an interactive local AI CLI session in the browser, which the README says is kept for direct sessions and debugging.

Installing Cabinet with npx and running a first agent

Cabinet runs through npx, so there is no global install. The README's quickstart creates a cabinet, changes into it, and starts both processes.

npx create-cabinet@latest
cd cabinet
npm run dev:all

After that, the README says to open http://localhost:4000, where an onboarding wizard builds your AI team in five questions. The CLI itself is the cabinetai package on npm; create-cabinet is described as a thin wrapper around it. If you would rather create a directory without starting anything, the README gives npx cabinetai create my-startup, and npx cabinetai run starts Cabinet in the current directory.

On first run, the CLI downloads a prebuilt app bundle into ~/.cabinet/app/v{version}/. That is worth understanding before you install: the CLI is not just a launcher for source code you already have, it fetches a versioned bundle and runs it. Updates go through npx cabinetai update, which compares your installed app version against cabinet-release.json from the latest GitHub Release.

If the UI will ever be reachable beyond your own machine, the environment example provides a password gate and hardening knobs. KB_PASSWORD protects the UI and is empty by default, meaning no auth. The auth cookie is PBKDF2 over the password with a per-install salt, and the example notes that changing the password, the salt or the iteration count logs everyone out once.

KB_PASSWORD=your-password
CABINET_LOGIN_MAX_ATTEMPTS=10
CABINET_LOGIN_WINDOW_MS=900000
CABINET_LOGIN_LOCKOUT_MS=900000
CABINET_LOGIN_GLOBAL_MAX=60

CABINET_LOGIN_PBKDF2_ITERS defaults to 600000, and the comment in .env.example discourages values below roughly 300000. CABINET_AUTH_SALT is auto-generated into .cabinet.env on the first run; set it explicitly only to pin a value. The rate limiting is per-process and in-memory, which means it does not survive a restart and does not coordinate across multiple daemon processes.

Where Cabinet gets in your way

The CLI's uninstall behaviour is deliberately narrow, and the README is explicit about it. npx cabinetai uninstall removes cached app versions only. npx cabinetai uninstall --all also removes global state and telemetry data. Your cabinet directories are never touched, and the README says those you delete manually. So the cleanup path for your actual knowledge base is rm -rf, not a Cabinet command. That is a defensible choice for a tool whose whole pitch is that your data is just files, but it means a mistaken uninstall leaves the interesting part on disk.

Telemetry deserves a direct look. The repository has a TELEMETRY.md file and the uninstall help text names platform-specific telemetry directories: ~/Library/Application Support/cabinet-telemetry/ on macOS, %APPDATA%\cabinet-telemetry\ on Windows, and $XDG_CONFIG_HOME/cabinet/ (falling back to ~/.config/cabinet/) on Linux. The README does not describe what is collected, so TELEMETRY.md is the document to read before you point Cabinet at anything sensitive. The README's own claim that your data never leaves your machine is about your cabinet directory, not about the telemetry directory.

Two smaller constraints. First, the GitHub-backed skill registry is rate limited: the environment example says an unauthenticated request gets 60 per hour and a GITHUB_TOKEN with public-repo read access raises it to 5000 per hour. Second, the web terminal is described in the README as kept for direct sessions, debugging and future terminal work, which reads as a feature the project is not finished with. If your workflow depends on that terminal, treat it as in motion.

Finally, Cabinet is the wrong tool if you want a hosted product. There is no managed tier in the repository, only a waitlist link for Cabinet Cloud in the README badges. Everything else assumes you are running the app yourself.

Cabinet versus a git-backed notes app with a chat window

The obvious alternative is a plain markdown vault in Obsidian or a git repository of notes, plus a chat client you paste context into. That combination shares Cabinet's core storage property: files on disk, versioned by git, readable without the tool. The difference is the execution model. A notes app has no daemon, no cron scheduler and no per-agent skill attachment. You supply the context each time.

Cabinet's scheduled jobs are the part a notes vault cannot replicate without you writing your own cron scripts and glue. The README's example of a Reddit scout running every six hours is a job that writes back into the same markdown store the agents read from, so the knowledge base grows without a human in the loop. The BYOAI principle in the README says Cabinet should work with Claude, Codex, OpenCode and local models rather than binding your knowledge to one provider, which is a meaningful difference from tools that store memory inside a single vendor's account.

The trade-off is operational surface. A notes vault is one process you already have. Cabinet is a Next.js app, a daemon, a CLI that downloads versioned bundles, an optional Electron shell and a telemetry directory. If you do not want cron jobs and agent skills, the extra machinery buys you nothing.

Maintenance, releases and the licence

The last push to the default branch was on 2026-08-25, the same day as the v0.6.0 release. Before that, v0.5.0 landed on 2026-07-04 and v0.4.4 on 2026-05-23, so the release cadence over that window is roughly every six to eight weeks. The repository is not archived. Note that package.json in the repository root still reads version 0.5.3 while the latest release is v0.6.0, so the manifest is not the thing to check for your running version; npx cabinetai update does that against cabinet-release.json.

Upgrade cost is low by design. npx cabinetai update checks for and installs a newer app version, and because your cabinet is a folder of markdown files outside the app bundle, the update does not migrate your content. The risk sits in the app bundle path: because the CLI downloads prebuilt bundles into ~/.cabinet/app/v{version}/, an update can change application behaviour without touching anything you can review in your own directory. There is a CHANGELOG.md and RELEASE_NOTES_v0.4.0.md in the repository root, but the README does not document a rollback procedure for a bad app version.

The project is MIT licensed, stated in both the README badge area and package.json. MIT permits commercial use, modification and redistribution with the licence and copyright notice retained. That is the extent of what the repository tells you; it is not legal advice, and if you are embedding Cabinet in a product, have counsel read the LICENSE file rather than a summary.

Editorial conclusion

Adopt Cabinet if you already work in markdown, want your agent memory on your own disk under git, and are comfortable running a Next.js app plus a daemon from a CLI that ships updates by downloading app bundles. Do not adopt it if you need a hosted product with a support contract, or if you want a knowledge base that non-technical teammates can use without a terminal. Before committing, run npx cabinetai uninstall --help to see exactly what the CLI removes, read docs/CABINETAI.md for the full command surface, and set KB_PASSWORD in .env if the UI will ever be reachable beyond localhost.

Frequently asked questions

Official sources

1. cabinetai/cabinet on GitHub
2. Issues
3. License: MIT
4. README
5. Releases