ZenNotes CLI 0.4.1
Released on September 28, 2026 as v0.4.1, at 86e2149. Two fixes for zn mcp and the desktop-managed zn, both from one report on the ZenNotes Discord (Kevin, against 0.4.0 and ZenNotes 2.56.0). The desktop pins this release in its next version, 2.57.0.
zn mcp follows the app to another vault
zn mcp picked its vault at the first tool call and kept it until the MCP
client restarted it. Switch the app from a ZenNotes server back to a local
vault, and an agent went on reading and writing the server, while a fresh zn
followed the switch at once.
The server now resolves the vault before every tool call, the way a fresh zn
does. A switch still never redirects work silently: an agent that read notes in
one vault and writes after you switched would change a note at the same path in
the other one. So once the vault changes, every tool except vault_info stops
with an error that names the old and the new vault and runs nothing. vault_info
confirms the switch and its notes say which vault the session left; the calls
after it run in the new vault. A batch of parallel calls stops as a whole, a new
token or profile name for the same server is no switch, and switching back
before vault_info is no switch at all. This holds whatever zn mcp follows:
the desktop app, or zn's own default in terminal mode. (35a77be)
The desktop-managed zn authenticates with the token zn connect saved
The desktop launcher runs zn in app mode, which follows the workspace the app
has open. For a ZenNotes server that needs a token, app mode took one from
--token, ZENNOTES_REMOTE_TOKEN or the desktop profile, but the app keeps its
own copy in the OS secret store, where zn cannot read it, so every command and
zn mcp answered 401. A token saved by zn connect for that same server was
left to terminal mode on purpose, so that nothing saved in the terminal could
redirect a desktop script.
App mode keeps that order and falls back, last, to the token zn connect saved
for the URL the app is connected to. The lookup is keyed by that URL, so the
token can only authenticate the app's server, never pick another one. Connect
the app, run this once, and your agents get in, with no token in any MCP config:
zn connect https://notes.example.com --no-default--no-default saves the token without making the server zn's own default, which
would stop a terminal-mode zn mcp from following the app. On a 401, zn mcp
now names that exact command, or says so when the rejected token came from
ZENNOTES_REMOTE_TOKEN: the environment outranks a saved token, so zn connect
cannot fix that one. And zn connect under the desktop launcher no longer claims
that zn uses the server by default; there only zn tui does, and the other
commands keep following the app. (86e2149)
How to test locally: connect the ZenNotes app to a server that needs a token,
then run ZENNOTES_WORKSPACE_SOURCE=app zn connect <url> --no-default (the
desktop launcher sets that variable itself). Register the MCP server with the
same variable, for Claude Code
claude mcp add zennotes -e ZENNOTES_WORKSPACE_SOURCE=app -- zn mcp, and ask
for your notes: they list, where 0.4.0 answered 401. Switch the app to a local
vault and ask again: the agent is told the vault changed, calls vault_info, and
lists the local notes, where 0.4.0 kept listing the server's until the client
restarted.
Also in this release
The README's MCP section and
docs/desktop-integration.md
describe both changes: how the server follows a switch, and the order in which
app mode looks for a server token.