Your backlog, as notes in your vault

What stays local

Plain-text project management has an obvious appeal: the files are yours, they open in anything, and they outlive the tool that wrote them. A local-first developer workflow only strains at the point where something outside the vault needs the same list — a coding agent, a colleague, a dashboard someone else is watching.

The plugin is explicit about that boundary. It talks to exactly one host, the origin of the MCP endpoint in its settings (autoplans.dev unless you self-host): the endpoint itself for every project and task call, and /api/telemetry/report if you have switched error reports on. Both go through Obsidian’s requestUrl helper rather than the renderer’s fetch, so calls are made by the main process and are not subject to CORS. Signing in is the one thing that leaves Obsidian: /auth/plugin on that same host is opened in your own browser, and the key comes back through an obsidian:// link. What crosses that boundary: the tasks of the projects you ticked for sync, and the title and body of a note at the moment you push it up as a task.

What does not cross it: the rest of the vault. The vault MCP server is off until you switch it on, and binds 127.0.0.1 when you do. Error reporting is a separate toggle, also off by default; when it is on, a report carries the error, its stack trace and the plugin version, with API keys, tokens, e-mail addresses and local paths stripped before sending — never note contents.

That is the practical form of local-first task management: the vault is the working copy you read and edit, and only the list you asked to share is shared. If Obsidian is your personal knowledge management system, the Autoplans folder is one more folder inside it, and a note counts as a project note only when its frontmatter carries autoplans_project_id.

Markdown task management workflows that survive a second tool

A checklist in a note is the quickest way to plan and the quickest thing to lose. Markdown task management workflows tend to fail in the same place: the list gets copied somewhere else — an issue tracker, a prompt, a colleague’s note — and from then on there are two lists, and the one being edited is not the one being read. The point of being able to sync tasks into notes is that the second list stops existing.

The general fix, with or without this plugin, is to give every line an identity that survives editing and to decide which side owns which field. Here each task line carries its id as an Obsidian block reference, so a line can still be found after it has been reworded, moved, or typed into halfway through; and the ownership rules are one-directional on purpose. The project owns titles, descriptions and order. The note owns two things: whether a box is ticked, and whether a new "- [ ]" line has appeared under ## Tasks.

An Obsidian task sync plugin is only worth having if that round trip is dependable, so writes made by the puller are marked while they happen and do not echo straight back up as pushes. Everything else — priorities, dependencies, subtasks, comments — is edited on autoplans.dev or through an agent, and simply reappears in the note on the next pull.

Serve an Obsidian vault over MCP

The other half of the plugin has nothing to do with notes going out. It is an Obsidian MCP server for coding agents, running inside Obsidian, so an agent reads the files you are actually looking at rather than a copy someone exported last week.

Switching it on starts a Streamable HTTP endpoint at http://127.0.0.1:28765/mcp with a token generated on first enable. It answers POST with JSON, returns 405 to GET — which in Streamable HTTP is how a server says it offers no server-initiated stream — and returns 401 to any request without the right bearer token. Binding localhost rather than every interface is what the MCP specification recommends for a server running on your own machine.

The eight tools are obsidian_list_notes, obsidian_read_note, obsidian_write_note, obsidian_append_note, obsidian_search_notes, autoplans_list_projects, autoplans_sync_project_note and autoplans_push_note_as_task. Copy config gives you the client entry below; Regenerate token mints a new token and invalidates the old one, so update your clients after using it.

{
  "obsidian-vault": {
    "type": "http",
    "url": "http://127.0.0.1:28765/mcp",
    "headers": { "Authorization": "Bearer <token>" }
  }
}

Obsidian for software project planning

A vault is a good place to think about a project and a poor place to be the only record of one. Using Obsidian for software project planning works when the notes are one view of a backlog other tools can read too — which is what the sync is for, and why the note format is boring on purpose.

The chain out to a repository is worth stating exactly, because it is shorter than people assume. The plugin syncs notes with Autoplans. Autoplans syncs the plan to a .autoplans folder in the repository, which travels with the checkout, so an agent working in that folder reads the project id from .autoplans/project.json and works the same backlog. The plugin itself never talks to GitHub.

It also means the thinking you do in the vault is not a dead end. A note written while working something out becomes a task with one command, and that task then shows up in the dashboard, in the VS Code extension, in the desktop agent, and in whichever MCP client is pointed at your account.

Related