For developers · open source
tuskd is a local memory daemon for AI agents: a human-readable Markdown vault, hybrid search, MCP-native tools, per-agent keys and grants — and an intelligence loop that turns raw experience into shared, validated, versioned knowledge.
$ curl -fsSL https://get.opentusk.ai | sh
$ tuskd setup01 · Why OpenTusk
Every session starts cold. Hard-won fixes, user preferences, procedures that finally worked — locked away in transcripts nobody reads again. Run several agents on the same project and it's worse: none of them knows what the others learned.
tuskd fixes this at the machine level. One local daemon gives every agent on the box the same durable, searchable, permissioned memory — and a loop that turns what they experience into knowledge the whole swarm can trust.
YOURS
One file per memory record. Grep it, diff it, put it in git. The search index is derived and rebuildable — the files are the truth.
PRIVATE
Binds to localhost only and makes no outbound calls. Nothing leaves your machine unless you export it — or opt into end-to-end encrypted sync.
SHARED
Per-agent identities with explicit read / write / promote grants per scope. Agents share project knowledge without stepping on each other.
TRUSTED
Shared scopes sit behind a gate: dedup, contradiction probe, per-scope policy, review queue. No agent silently overwrites what the team knows.
COMPOUNDING
Success and failure telemetry feeds search ranking; procedures that keep working graduate into agent-loadable SKILL.md files.
SIMPLE
No Docker, no database server, no cloud account. Works with Claude Code, Claude Desktop, Cursor, Codex, VS Code — any MCP client.
Want the full picture — architecture, memory model, the gate? Read the docs →
02 · Quickstart
The fast path is two commands: install, then tuskd setup — a guided wizard that creates the vault, starts the daemon, connects your AI clients, and offers cloud sync. Every step it runs is a plain verb you can use directly; explicit identities and grants, the review loop, and the dashboard are covered in the docs.
One command — verifies the SHA-256 checksum, installs to ~/.local/bin, never asks for sudo. Alternatives (pinning, manual verification, source) are in the docs.
curl -fsSL https://get.opentusk.ai | shtuskd setup is a checklist, not a questionnaire: every run derives the remaining steps from what is already on your machine and only asks about what is missing. Ctrl-C is always safe — rerunning resumes where you left off, rerunning on a broken install lands on the broken step, and on a healthy install it just prints status. Each step echoes the plain command it ran, so it teaches the manual verbs as it goes.
$ tuskd setup
tuskd setup — vault ~/team-vault
▸ vault
create a vault at ~/team-vault? [Y/n] y
ran: tuskd init
▸ daemon
start the daemon in the background? (it indexes, watches, and auto-syncs) [Y/n] y
ran: tuskd start -d
▸ AI clients
✓ claude-code already configured
configure cursor to use this vault? [Y/n] y
ran: tuskd agent setup cursor
▸ cloud sync
sync this vault to OpenTusk Cloud? (end-to-end encrypted; free plan: 1 repo) [y/N] n
staying local-only — rerun tuskd setup any time to enable sync
▸ all set
check any time with tuskd status; rerun tuskd setup to repair or extend this setupAgents write with memory_write and recall with memory_search. The CLI works alongside the daemon — commands route through it, never a second writer.
tuskd status
tuskd search "env parity" --scope project:demo03 · Sync across machines
tuskd is local-first: nothing leaves your machine until you opt in. When you do, OpenTusk Cloud keeps one vault synced across your machines — every change is encrypted on-device before upload, and the server only ever stores ciphertext under scrambled names. Once connected, the daemon syncs automatically in the background.
A second machine is the same two commands. The wizard's cloud step shows a numbered picker of your repos, then walks the fingerprint approval ceremony — you compare a short code on both screens, so a stolen password alone can never add a device — and pulls your vault the moment another device approves it.
curl -fsSL https://get.opentusk.ai | sh
tuskd setup # choose "join an existing repo", compare fingerprints, donetuskd sync reference is in the docs; how the encryption works lives on the cloud page.04 · The essentials
PLATFORMS
macOS (Apple Silicon and Intel) and static Linux builds (x86_64, arm64), published on GitHub Releases; Windows later. Installs verify SHA-256, never ask for sudo. Install options →
UPGRADES
Re-run the installer, cycle the daemon: curl -fsSL https://get.opentusk.ai | sh && tuskd restart -d. Releases are immutable — you can always pin a version.
SECURITY
Every tool call is authenticated and passes one ACL choke-point. Agent keys live in the vault (0600) and are excluded from exports. The grant model →
05 · FAQ
SQLite gets one writer; so does the vault. tuskd enforces this with an advisory flock on .tusk/lock that dies with the process — stale locks can't wedge the vault. Everything else (stdio sessions, CLI commands, the dashboard) routes through the owner over its Unix socket, so you get concurrency without corruption.
In the vault directory you initialized: one Markdown file per record under memory/, skills under skills/, and derived state under .tusk/. By default nothing leaves your machine — tuskd binds to localhost only and makes no outbound network calls until you opt into encrypted sync, which uploads only ciphertext. Back up the vault by copying the directory, or use tuskd export.
Yes — OpenTusk Cloud keeps one vault synced across your machines, end-to-end encrypted: the server only ever stores ciphertext. The fully offline alternative is tuskd export archive.tar.gz / tuskd import archive.tar.gz. Either way, don't put a live vault on a network filesystem — advisory locks and file-watchers are unreliable there.
Releases aren't codesigned yet. Installs via curl … | sh aren't quarantined, so this only appears if you downloaded a tarball with a browser — clear it with xattr -d com.apple.quarantine ~/.local/bin/tuskd. Signing and notarization are on the release roadmap.
More answers — lost tokens, stale indexes, backups — in the docs FAQ.