Private memory for you. Shared memory for your team. Available to every MCP-compatible AI tool you use.
Now with Team Edition — private personal layers plus a shared team layer, in one Worker.
Agenten stärken
Installation vom Herausgeber. Kein PlugMCP-Endpunkt.
Host a copy with our keys and logs.
Noch kein paketiertes Release in der Registry. Folgen Sie der README des Repositorys.
Remote-URL oder ein Befehl auf Ihrem Rechner? Worin sich die beiden Installationen unterscheiden
Auf PlugMCP ausführen
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
StartenVom Herausgeber
Private memory for you. Shared memory for your team. Available to every MCP-compatible AI tool you use.
Now with Team Edition — private personal layers plus a shared team layer, in one Worker.
One memory layer, every AI tool. Store anything once — recall it in Claude, ChatGPT, Cursor, or any MCP client. Self-hosted on Cloudflare's free tier.
Claude, ChatGPT, Cursor, Codex, and the other AI tools you use do not naturally share context. You end up repeating the same projects, decisions, and preferences in every app.
Second Brain gives those tools one persistent memory system. It runs in your own Cloudflare account, stays under your control, and retrieves the right context by meaning rather than exact wording.
The desktop app is the easiest way to start. It builds your Second Brain and connects your AI tools in about two minutes—no terminal or Cloudflare setup required.
Second Brain can now be a team's memory without stopping being yours.
The same Worker supports personal and team use; there is no separate team deployment. In the API, CLI, and MCP tools, the Shared layer is represented by the stable workspace value company. See the Team Setup guide for member management, capture policies, sharing, and upgrades.
v3.0.0 scope: each brain has one shared team. The API and MCP layer include optional team parameters and a list_teams tool so multi-team support can ship later without breaking changes; the dashboard and admin flows do not create or switch between multiple teams yet. See CHANGELOG.md.
Second Brain runs as a Cloudflare Worker backed by D1, Vectorize, Workers AI, and KV. Every app and AI client connects to that Worker through REST or the Model Context Protocol (MCP).
If Vectorize is unavailable, captures and keyword recall continue working. Your memories remain usable while semantic indexing is restored. The shipped embedding models read English best; the desktop app's Settings can switch a brain to a multilingual reading.
Search now finds the hard things: exact names, ticket numbers, versions, and phrases in any language, even when they sit in old memories, and finding them is dramatically faster and cheaper, staying that way as the brain grows, which keeps the free plan comfortable. It does this with a full-text index that ranks matches by relevance instead of scanning every memory. The upgrade is automatic: new installs use the index immediately, existing brains build it over nightly runs, and no client needs updating.
A memory keeps the dates it was true for: recall with as_of answers what was actually true on a past date, and a fact that a newer one replaces is kept as history instead of being marked wrong.
On a team brain, memory tools accept a workspace of personal or company when you want to choose a layer explicitly. company is the wire value for the Shared team layer. Without workspace, captures use the member and team defaults, while recall searches everything that person is allowed to see.
Optional team (workspace id) and MCP list_teams / GET /team/workspaces are wired for a future multi-team release. In v3.0.0 you can omit them — each brain has one shared team and the primary team is used automatically.
Memories live on four axes: workspace = who can see it (personal / company / team) — tenancy, unchanged. project = what it's about — a named, managed container. tags = free-form facets, unchanged. source = where it came from, unchanged. Call list_projects to discover projects in scope and pass project on remember to group related memories. A memory can belong to one or more projects; use projects to organize by topic, initiative, or context rather than bare topic tags.
CLI example:
brain remember --workspace company "We ship on Thursdays"
brain recall --workspace company "when do we ship?"
brain recall --project website "what did we decide about hosting?"
Prompt Capsules are deterministic, read-only projections for gateways and
custom agents that can place stable context before a changing user request.
They complement query-specific recall; they do not inject every memory into
every prompt.
A Capsule entry is an ordinary canonical memory with one target tag and one
slot tag. Core entries use capsule:core; project entries use
capsule:project:<project-slug>. Slots are emitted in this fixed order:
identity, preferences, constraints, principlescurrent-state, decisions, open-questionsTag the slot as capsule-slot:<slot> and keep at most one canonical entry per
slot. Draft and deprecated entries are ignored. Ambiguous slots are omitted
without choosing a winner; malformed rows are skipped. The response reports
duplicate_slots and invalid_entries, and complete is false. Other valid
slots remain available, including on the shared layer.
An entry must carry status:canonical to be part of a Capsule. The easiest way
is to include status:canonical in the tags at remember or capture time (it is
stored after whitespace trimming, and the classifier then leaves it alone);
otherwise the definition starts as draft and requires set_status canonical.
Classification, including /classify-pending, never publishes a capsule. A
write that contradicts a protected memory is demoted to draft even when the
caller requested canonical. To take an entry out of a Capsule, set its
status to draft or deprecated. MCP update accepts an optional tags array:
pass the complete replacement definition, for example
["capsule:core", "capsule-slot:preferences"], along with the entry id and
content. Naming either capsule namespace replaces both namespaces; a lone
slot tag is not a complete definition. Omit tags to preserve existing tags.
MCP and REST capture/update accept at most 64 tags of 128 characters each.
Shared-layer recovery: members can publish their own shared definitions,
but cannot edit a teammate's entry. Check the reported ids, ask the author or
an admin to re-slot or unpublish them with update or set_status, and do not
interpret an incomplete response as the full team policy. The dashboard hides
bookkeeping tags; use MCP for this recovery. No teammate content-edit permission
is added.
Authenticated clients can use GET|HEAD /prompt-capsules/core,
GET|HEAD /prompt-capsules/projects/<project-slug>, or the
get_prompt_capsule MCP tool. Responses include a strong ETag, a SHA-256 of
the exact prompt-ready text, and whole-slot omission metadata for the
12,000-character budget. Validation happens before serialization: shared invalid,
duplicate, or individually oversized definitions are excluded and reported, so
later healthy slots may still appear. The result is an ordered subset of the
defined slots, not necessarily their prefix. Among the remaining valid slots,
once the cumulative budget is exceeded, that slot and every later slot are omitted. A single
entry longer than the whole serialized budget (including JSON escaping) returns
409 invalid_prompt_capsule with reason content-too-large in a personal
capsule, even if earlier slots would fit; no partial text is returned. In a shared capsule it is skipped
and reported, so it cannot hide unrelated slots. Empty responses have
populated: false and complete: false. The 200-candidate resource limit still
returns 409 too_many_candidates; an author or admin must reduce definitions. Timestamps, entry ids, and ETags are excluded from
text, so unrelated changes do not alter the reusable prefix. Provider cache
keys, breakpoints, token budgets, and cache-hit measurement remain the
gateway's responsibility.
Capsule bodies are cached in KV per workspace and immutable D1 revision for up
to one hour. Entry triggers advance that revision in the same D1 transaction
as every capsule-tagged insert, id/content/tag update, workspace move, or delete.
If a restore or import has no derived revision row, the first read seeds a new
opaque revision instead of using a reusable sentinel.
Each cached read therefore pays one indexed D1 row instead of scanning the whole
workspace; KV eventual consistency can cause an extra rebuild, but cannot revive
a pre-edit or pre-share body. Old keys become unreachable immediately and expire
within the hour; after propagation settles, the longer TTL normally limits an
unchanged, continuously read target to 24 refresh writes per day. Cold-fill races
and revision changes can add attempts. Writes to ordinary entries do not advance
the revision. Gateways should revalidate with If-None-Match once per session
rather than on every request.
An empty project Capsule is returned normally but not stored in KV. Project
ids now correspond to registered project slugs and are enumerable through the
projects registry, but capsule reads remain backward compatible and serve
unregistered ids normally; nonexistent or mistyped ids cannot consume KV writes
or keys. A partial (workspace_id, id) index over capsule-tagged rows,
explicitly selected by the candidate query, also bounds these reads to capsule
definitions instead of every ordinary memory in the workspace. Its cost grows
with capsule-tagged rows, not with the ordinary corpus. Empty core Capsules
remain cached because core is one fixed target per workspace.
After a D1 Time Travel restore, redeploy the Worker before resuming traffic so
schema initialization recreates prompt_capsule_revisions and the four
prompt_capsule_* triggers if the restore point predates part of this migration.
Initialization compares the installed capsule index definition and trigger bodies.
Changed index definitions and changed or missing triggers are repaired atomically
with a revision rotation, so cached results cannot survive a repaired invalidator. NUL-containing ids, content, or tag documents
are rejected (personal) or skipped and reported (shared), never published as a
truncated SQLite string. REST capture/update/append and MCP remember/update/append
reject new NUL-containing content; incoming tags must also be NUL-free. Imported
or legacy rows still receive the read-time checks described above.
Upgrade warning: capsule:* and capsule-slot:* are now reserved. Existing
canonical rows using those names can become prompt definitions or appear in
validation reports. Review these tags before enabling a gateway, especially on
a shared workspace.
All three setup methods deploy the same Second Brain into your Cloudflare account.
Download the latest release, open it, choose a password, and sign in to Cloudflare. The app provisions the Worker and its resources, then helps connect your AI clients, CLI, browser extension, Obsidian, and Notion.
The macOS build is signed and notarized by Apple. Windows release builds are code-signed; see the code signing policy.
Use Deploy to Cloudflare to provision the Worker yourself without cloning the repository.
Your AUTH_TOKEN is the password for your Second Brain—the same value every client asks for. Use either:
A memorable phrase, such as coffee-lover-2026
A randomly generated token:
openssl rand -base64 32
When Cloudflare shows the configuration form, enter:
After deployment, connect compatible clients to:
https://YOUR-WORKER-URL/mcp
Use OAuth where the client supports it, or an Authorization: Bearer <token> header for static clients. Query-string token authentication was removed in v3 because URLs can leak through browser history and logs.
Add ?client=<name> to the MCP URL so the dashboard can name the tool that made each change.
Having connection issues? See Connect to AI Clients → Troubleshooting (Opera warnings, Cursor OAuth, Claude Code tool visibility).
For developers who want full command-line control:
npm install
npm run vectors:create
npm run deploy
Follow the Setup Guide for prerequisites, resource creation, deployment verification, and troubleshooting. Then use Connect to AI Clients for client-specific instructions.
Develop locally:
npm run dev # start the Worker locally
npm test # run the test suite (fast: the golden-set eval replays are opt-in)
npm run test:eval:full # the full eval (golden-set replays, workerd lock); run by hand before merging a ranking change
See Local Development for mixed local/remote Wrangler configuration and sharing a local brain through a tunnel.
Verify the deployment (replace YOUR-WORKER-URL and YOUR-TOKEN):
curl -X POST https://YOUR-WORKER-URL/capture \
-H "Authorization: Bearer YOUR-TOKEN" \
-H "Content-Type: application/json" \
-d '{"content":"second brain is working","source":"test"}'
A successful response looks like {"ok":true,"id":"..."}.
second-brain-cf-cliintegrations/bookmarklet.jsintegrations/ios-shortcuts/integrations/claude-code-hooks/integrations/codex-cli-hooks/)recall tool for reliable recall (integrations/cursor-hooks/)integrations/vscode-copilot-hooks/)integrations/gemini-cli-hooks/)Not yet supported, revisit later: Windsurf (no documented session-start context injection event, only a post-response hook); OpenCode and Oh My Pi (plugin/event-callback APIs, not stdin/stdout scripts, so they need their own integration model rather than an adapter like the ones above).
See Capture from Anywhere for setup and usage instructions.
v3.4 adds Projects: named, workspace-bound containers for what a memory is about. Group memories by codebase, client, or goal; adopt years of existing tags retroactively through aliases with no migration; manage everything from a new dashboard tab; and let agents discover and use projects through list_projects and the project parameter. Nightly digests, prompt capsules, exports, and Claude Code hooks are all project-aware.
Team Edition adds Personal and Shared memory layers, per-person authentication, sharing and attribution, author locks, team administration, capture policies, team-aware recall and graphs, and a private-by-default upgrade from v2.
It also hardens tenant isolation across REST, MCP, integrations, imports, insights, graph traversal, and vector search, backed by expanded unit, integration, and UI coverage.
See GitHub Releases for release notes and previous versions.
Runs the real Worker and dashboard offline, for a UI change or a full walkthrough of the app, with no Cloudflare account of any kind, ever. wrangler dev cannot do this on its own: a real Workers AI binding needs a Cloudflare login even in local dev. This harness never asks for one.
npm run dev:local # boots the Worker + dashboard at http://localhost:8788
npm run ux:seed -- solo # seeds a 3.7.0-shaped brain and boots the real 4.0 upgrade against it
npm run ux:seed -- team # the same, plus a teammate, for the shared-history rows
UX_BRAIN=3.7-solo npm run dev:local # run against a seeded brain instead of an empty one
npm run ux:shot -- --name=home --caption="Dashboard home" # one screenshot, on demand (see below)
npm run ux:walkthroughs # the scripted dashboard journeys (map section 6.2), with screenshots
npm run ux:chat # scripted MCP calls per AI_Instructions file (map section 6.4)
What it uses instead of a Cloudflare account: real local D1 and KV (via wrangler's getPlatformProxy), real deterministic local embeddings (the same BGE weights Workers AI serves, run in-process through @huggingface/transformers, the eval harness's own local-model runtime), a real cosine-similarity Vectorize double, and fixed canned replies for the handful of LLM-style calls (classify, merge decisions, digest synthesis) a real local model cannot practically stand in for. Everything else, the dashboard, the REST routes, the MCP tools, is the genuine Worker code.
npm run ux:shot takes one screenshot of a named screen or state on demand (any lane can use it for a before/after pair), for example:
npm run ux:shot -- --name=trash-view --caption="New Trash view" --path=/#trash --viewport=mobile --locale=it
Screenshots never land in this repository: they are written to docs/superpowers/screenshots/v4/harness/<run-id>/ outside public/, which the project's docs/* gitignore rule already excludes, alongside an index.md captioning each one.
A journey in npm run ux:walkthroughs that reaches a feature not yet built on the current branch (the dashboard timeline, trash view, or settings panel, for example) reports PENDING with the exact missing UX item, not a failure; the same script turns green the moment that feature ships. None of this runs as part of npm test or CI's default job: it needs a local Chrome or Chromium (already present on GitHub's ubuntu-latest runners and most Linux desktops) and takes real wall-clock time to boot a browser and a local D1, so it stays behind its own npm scripts.
Second Brain uses Cloudflare Workers, D1 SQLite, Vectorize, Workers AI, KV, the Model Context Protocol, and TypeScript. It runs within Cloudflare's free tier at personal scale.
Your application resources and data stay in your Cloudflare account. The project maintainers cannot see your memories or credentials. Integrations contact only the services you choose to connect.
Windows release builds of the Second Brain desktop app are code-signed.
Free code signing is provided by SignPath.io, with a certificate from SignPath Foundation.
Release binaries are built from this repository by GitHub Actions. Every signing request is reviewed and manually approved before a signed release is published.
Privacy statement: This program will not transfer information to other networked systems unless the user or the person installing or operating it specifically requests that action. During setup, the desktop app communicates with Cloudflare to create resources in the user's account. Afterwards, it communicates with that deployment and with integrations the user explicitly connects. Memories and credentials are never sent to the project maintainers.
One memory layer, every AI tool. Store anything once — recall it in Claude, ChatGPT, Cursor, or any MCP client. Self-hosted on Cloudflare's free tier.
Tools
Noch keine Tool-Liste. Remote-Server erhalten eine nach dem ersten Health-Check.
FAQ
Kopieren Sie auf dieser Seite die stdio-Konfiguration für Cursor, Claude Desktop, Claude Code oder VS Code. Sie nutzt die Installation des Herausgebers, keinen PlugMCP-Proxy.
In diesem Eintrag ist keine erforderliche Umgebungsvariable aufgeführt.
Second Brain Cloudflare läuft lokal über stdio.
Zuletzt geprüft: 2026-10-27. One memory layer, every AI tool. Store anything once — recall it in Claude, ChatGPT, Cursor, or any MCP client. Self-hosted on Cloudflare's free tier.