
Todo Mcp
io.github.pasichDevPublished by GitHub account pasichDevv2.2.0Updated Oct 25, 2026
Shared TODO/backlog MCP server with claim tracking, web UI, and encrypted local storage.
Overview
A local-first shared TODO and backlog server that lets any MCP-capable coding agent capture, claim, edit and complete work items across projects.
- What you can do
- Capture, list, edit, complete and delete TODO items, filed automatically under the project resolved from the git remote, with claim and release for in-progress work and a per-item change history. Publish, list, read and delete digests compiled by the agent from GitLab, GitHub, Notion or git, and hand a numbered digest item to the calling agent as a claimed task. Mark digest items seen so later digests skip them. Check the data-format version and read-only npm update status. A local web dashboard on port 8787 shows tasks, digests and active sessions, and an optional Claude Code session-start hook injects open items for the current project.
- When to use it
- Useful when you work across several projects and agent tools and want one quick capture list that any of them can write to, before items are worth a real ticket. Also fits teams or solo users who want a self-hosted, encrypted local store with an optional dashboard rather than a SaaS account.
- Requirements
- Node.js 18 or newer and at least one MCP host (Claude Code, Codex, Cursor, Windsurf, Claude Desktop, Zed or Warp). Runs as a local stdio process started with npx; no account, API key or declared environment variable is required. The web UI listens on localhost:8787 by default, overridable with DOCKET_WEB_PORT. Self-hosted multi-machine mode needs a server you run and paired devices.
Installation
In SourceWeft
- Open Todo Mcp in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Docket
[npm] [CI] [MCP Registry] [License: MIT]
One list every AI tool you use can write to — Claude Code, Codex, Cursor, Warp — across every project, before the work is worth a ticket. Local-first, self-hostable, no SaaS account.
Watch the one-minute demo · download the mp4
Quick start
You need: Node.js 18+ and at least one MCP host — Claude Code, Codex, Cursor, Windsurf, Claude Desktop, Zed or Warp.
That configures every host it finds on this machine and ends by telling you which ones. Then restart your agent and ask it "add a todo: buy milk" — it shows up at http://localhost:8787, a dashboard that started by itself the moment the agent connected.
Only want Claude Code, and nothing written anywhere else?
claude mcp add docket -- npx -y @pasichdev/docket does just that part.
Other hosts: Supported hosts.
Optional: see what's open in a project when a session starts
hook install works without the global install too — it pins the command to
this exact copy of docket and tells you it did — but the short form survives
moving or reinstalling, and npx leaves nothing on PATH.
Why
A thought that shows up mid-session is worth capturing but not worth the ceremony: a Notion template, a GitLab issue format, a ticket id you have to invent. So today it evaporates. Docket is the layer underneath all of that — work lands here at the speed an agent can type, from any tool, in any project, and graduates to Notion/GitLab/Obsidian when it's earned it.
Nobody else occupies this space, and it isn't an accident: Anthropic will not integrate Claude Code with Cursor, and Cursor will not integrate with Codex. Every vendor optimises its own closed loop. The space between the tools is structurally nobody's.
One list, many projects
Docket files every item under the project it was captured in, automatically — resolved from the git remote of wherever the agent is running. You never type it, and no agent has to remember to.
todo_listin~/work/backendshows that project's open items, not all three projects' — compact, one line each.- The web dashboard has a workspace switcher with per-project open counts.
- Items with no project context land under Unfiled and stay visible, never guessed at.
Using the git remote rather than the path means the same repo cloned to
~/src/backend on a laptop and /work/backend on a desktop is one
workspace — which matters precisely because sync exists. Full resolution
order and the .docket.json override: docs/workspaces.md.
[Docket web dashboard, dark theme: the top card is claimed by claude-code and shows a Markdown description clipped with a Read more link] [The same list in the light theme]
[One item opened: its full Markdown description rendered, and its history showing who claimed it and who created it] [The same item being edited, with a Markdown editor and Write/Preview tabs alongside category, priority and due date]
Regenerate these with node docs/assets/demo-seed.mjs — it builds the workspace they show, so they stay a picture of the real dashboard rather than a staged one.
Upgrading from 2.x
Read this before you upgrade if you have existing items.
3.0 migrates your store from data format v7 to v8 on first run, automatically. The migration itself is safe and is not the risk. Downgrading afterwards is.
docket 2.3.1 writes the store from its own v7 shape: it has never heard of the fields v8 adds, so its very first write after a reinstall silently strips them from every item. Nothing errors, and a later re-upgrade hands out fresh sequence numbers that no longer mean what your paired devices think they mean. 2.3.1 is published and cannot be patched, so 3.0 defends the only way it can — by keeping a copy of your pre-migration store:
It is written once, before the first v8 write, and never overwritten. The upgrade prints its path on the run that creates it.
To go back to 2.x, restore it first:
In that order. restore --from-v7 deletes nothing — your v8 store is renamed
aside, so you can come forward again later.
If you would rather have a portable copy as well, docket backup ./pre-v3.backup
before upgrading gives you one that includes your identity and paired peers.
Bridges, not replaces
Docket is deliberately not where work lives forever. It's where work lands first, before anyone knows whether it deserves a ticket. Most of it doesn't and gets closed by hand; the rest graduates.
sourceUrl is the bridge in both directions. Set it whenever an item maps to
something with a URL — a GitLab issue, a Notion page, an Obsidian
share link, a Slack thread, a GitHub PR — and the card carries a clickable
link straight back to it.
Why not just use GitHub Issues? Because an issue costs a title you have to phrase for an audience, a repo you have to pick, and labels you have to maintain — and because your Cursor session can't write one for you while you're mid-thought in a different project. Docket costs one sentence, from whichever tool you already have open. When the item turns out to matter, it becomes an issue, and
sourceUrlremembers where it went.
Supported hosts
Any MCP host works — the tools are identical everywhere:
Zed's config shape is slightly different
The one hook
Claude Code additionally gets a SessionStart hook, and only that one:
When a session starts it injects the items open in that project — compact, at most 7, under 120 tokens. Nothing at all when the project has nothing open. Its whole job is continuity: you come back to a terminal and the thread is already there.
Don't want it? export DOCKET_HOOKS=off disables it immediately, without
editing any config or uninstalling anything. docket hook doctor measures the
real round trip and says so if it is slow enough to notice.
It fails open, always. Server not running, request timed out, malformed
response, DOCKET_HOOKS=off — every one of those exits 0 and prints nothing.
A tool that degrades your session when the tool itself is broken gets
uninstalled, at which point it helps nobody. docket hook doctor runs the
configured command for real and reports what a session would actually see, so
a hook that never fires is visible rather than merely silent.
No PreToolUse, no blocking, no other hosts — the hook's only job in this
release is continuity, not enforcement.
Guidance for non-Claude-Code agents
The tools work everywhere; the guidance ships as a Claude Code plugin. For
any other agent, copy skills/docket/SKILL.md
(everything below the --- frontmatter) into whichever file your agent reads
— AGENTS.md for Codex, .cursor/rules/docket.mdc for Cursor,
.windsurfrules for Windsurf, CLAUDE.md for Claude Desktop, or Warp's
custom-instructions setting.
Tools
Full field and workflow reference: skills/docket/SKILL.md.
Digests
Ask your agent "make a digest" (or "зроби дайджест"). The docket:digest
skill reads your merge requests, pull requests, Notion tickets, local commits
and docket items, checks every status at the source, and publishes the result —
which becomes the dashboard's home page: what needs you, what shipped, what is
in review, what is stuck, each item linked back to where it lives and one click
away from becoming a task.
Docket never holds a GitLab, GitHub or Notion credential: the agent reads them
with the CLIs and MCP servers it already has, and Docket only keeps what it
wrote — on this machine in Local Mode (synced to paired devices), or on the
Docket Server in Self-hosted Mode, shared by every client. Anything else the agent can reach — Jira, Linear or Sentry through their MCP
servers, an Obsidian vault, a project's docs folder — can be added as a source, and
the digest can be split into groups such as work, learning and side projects. What to read is local to each machine, in ~/.config/docket/digest.json
(the docket:digest-setup skill writes it); the digests themselves sync to
paired devices. Details: docs/digests.md.
- What changed since the previous digest is computed when it is published — new items, status changes, what dropped out — not left to the agent's memory.
- Who does what: every item can name its owner (you, a teammate, the agent); By person turns the digest into numbered next steps per person.
- Depth where it matters: routine items stay one line; blocked, failing or stale ones carry the agent's analysis of the actual cause and next step.
- Hand it off by number: tell any agent "take 7" —
digest_takegives it the brief and a task claimed in its name; it closes the task with the reason. - Seen hides an item until its status changes; marks sync across devices.
- Yours to shape: groups, people, presets ("digest work", "digest week"), environment checks, mail and chat via MCP, a daily run — and the skill keeps short notes on what you keep correcting.
CLI
docket help prints the canonical, always-current list. Full reference:
docs/cli.md.
Deployment modes
Both modes install from the same package and expose the same MCP tools. Full
self-hosted setup and what it deliberately doesn't do:
docs/self-hosting.md.
P2P sync is deprecated as of v3.0. It still works, and nothing is removed in this release — but its 15-second pull interval means claims are advisory across it, so it cannot deliver an atomic guarantee. Self-hosted Mode is the supported multi-machine path. See
docs/p2p-sync.md.
Web UI
A real-time read/write dashboard — http://localhost:8787 by default in Local
Mode (override with DOCKET_WEB_PORT), or the Docket Server's own URL in
Self-hosted Mode. The home page (/) shows the latest digest next
to the task list at a glance; the list itself is at /tasks. Workspace switcher with per-project open counts, an active-
sessions panel, light/dark theme, search, sort, inline edit, undo-delete,
responsive mobile layout.
In Local Mode it starts itself: the first MCP client to connect spawns it
detached in the background if nothing's listening yet. Updates push live over
Server-Sent Events (/api/events), no polling.
Opening it from another device on your LAN (phone, tablet) requires an explicit Viewer Gate approval from the host machine first — see Security.
Security
Docket has four separate threat models (encrypted local storage, P2P sync, the LAN Viewer Gate, and self-hosted client/server traffic) — a guarantee from one does not apply to another. The basics:
- At rest:
todos.json.encandhistory.json.encare AES-256-GCM encrypted with a locally generated key — protects against accidental exposure, not against someone with read access to your own user account. - P2P sync: X25519 ECDH + HKDF-derived per-pair secrets, HMAC-signed requests with replay protection, AES-256-GCM encrypted responses.
- LAN Viewer Gate: any browser other than the host machine needs explicit human approval before it can open the dashboard; that local traffic itself is plain HTTP, not TLS (documented tradeoff, not an oversight).
- Self-hosted mode: per-device HMAC signatures with timestamp+nonce replay protection. The server is not end-to-end encrypted against its own operator.
- Updates: every release is published with Sigstore-backed npm provenance,
verifiable with
npm audit signatures.
Full threat model, exact primitives and limitations:
docs/security.md.
Data & encryption
Authoritative data lives on this machine (~/.docket) in Local Mode, or on
the Docket Server in Self-hosted Mode — either way on infrastructure you
control, never a hosted account.
todos.json.enc— the store, AES-256-GCM encryptedhistory.json.enc— the full audit log, kept off the store's write pathdigests.json.enc— digests, AES-256-GCM encrypted, with their own sync cursorkey— a locally generated 256-bit key,chmod 600device.json— this machine's id, name, and X25519 identity keypairpeers.json.enc— paired P2P devices and their derived sync secretssessions.json— which agent sessions are open right now (plain, local-only, never synced; it holds process metadata, not content)
Set DOCKET_DATA_DIR to relocate the directory; startup refuses to silently
split an existing store rather than guessing.
Backup & updating
docket backup <file> bundles the whole data directory into one
password-protected file (AES-256-GCM, scrypt-derived key); docket restore
writes it back, renaming what's on disk aside rather than overwriting.
Testing
Runs the full node:test suite — sync delivery and pagination, the
cross-process file lock under real contention, workspace resolution and
scoping, the session registry, agent-facing token budgets, and the hook's
fail-open behaviour.
License
MIT — see LICENSE.
Source: README.md at commit 890ab8a
Tools
0Version history
1- v2.2.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts