Skip to content

Release 2.63.0 - #904

Merged
adibhanna merged 8 commits into
mainfrom
v2.63.0
Oct 6, 2026
Merged

adibhanna merged 8 commits into
mainfrom
v2.63.0

Conversation

@adibhanna

@adibhanna adibhanna commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

ZenNotes 2.63.0.

Fixes

Local gates on dc8fe10: typecheck 8/8 and test:run 6/6 with no cache (shared-domain 1,896, app-core 3,122, quicklook 15, desktop 1,052), npm audit --omit=dev --audit-level=high clean, npm run pack signed, deep strict codesign OK, bundled zn v0.6.3 in Resources/zn-cli (drwxr-xr-x), packaged launch check: page target in 1.4 s, version 2.63.0, MCP server (SDK 1.31.0) stdio round trip: initialize, 34 tools, list_notes on a scratch vault. Smoke suites on the built app: vim-editor and sidebar-vim passed; editor-improvements passed on a re-run (the first run's one failure read the cursor as null before the mode switch, a measurement flake).

The 2.62.0 braces override gave Excalidraw sass 1.103.1, and that sass
depends on @parcel/watcher, so the packaged app started carrying both:
sass inside app.asar and the watcher's prebuilt native binaries in
app.asar.unpacked (glibc and musl ones on Linux). Nothing loads either.
The renderer bundles Excalidraw, and Excalidraw's build never imports sass.
The musl binary alone failed the 2.62.0 Nix build until 9393422 removed it
inside the Nix package.

electron-builder now leaves both packages out of the app. A packed build
has no sass or @parcel entries left in app.asar or app.asar.unpacked and
an app.asar 5.9 MB smaller; nothing else changed in it. The packaged launch
check passes, an Excalidraw drawing opens in the packed app with no
renderer errors, and the production audit is unchanged because no
dependency moved. The Nix workaround stays until a release without the
watcher replaces 2.62.0 there.
…board images

Reported by Julie on Discord (Linux): a screenshot pasted only with a
middle click. Right-click > Paste, "+p and "*p in normal mode, and Ctrl-R +
in insert mode did nothing, and a fresh screenshot did not paste even with
a middle click.

Images were only ever imported from a real paste event, the one Mod+V and a
middle click send. Every other path read text: the editor menu's Paste and
codemirror-vim's "+p called readText(), and codemirror-vim's "*p and
insert-mode Ctrl-R read in-memory registers the system clipboard never
fills, so "*p and Ctrl-R + did not paste clipboard text either. None of it
was specific to Linux. The fresh screenshot is Linux working as designed: a
middle click pastes the primary selection, which screenshot tools leave
alone.

The editor menu and the + and * registers now read the whole clipboard. An
image goes through the note's own import (saved to assets/ as "Pasted Image
<time>" and embedded, as with Mod+V); anything else pastes as text. Both
registers mean the system clipboard, as in Vim on macOS and Windows;
reading the Linux primary selection is left out. A Vim put lands the image
on a line of its own, below the cursor line for p and above it for P,
leaving visual mode first, instead of splitting the line at the cursor;
Ctrl-R + and the menu insert at the cursor, like Mod+V. With
yank_to_clipboard on, bare p and P take images the same way. Clipboard text
through "+p is linewise when it ends in a newline, as the synced p already
read it, instead of reusing the flag of the last in-Vim yank into "+.

The overrides replace codemirror-vim's paste and insertRegister actions and
keep its behaviour for every other register. Editors without the note
import (table cells) fall back to the clipboard text.

Verified in the built app over CDP with a real PNG and real text on the
macOS clipboard: before, only Mod+V took an image (2 of 10 paths); after,
"+p, "*p, "+P, visual "+p, Ctrl-R +, Ctrl-R *, synced p and a real mouse
right-click > Paste all paste the image (the asset is byte-identical to the
copied PNG), and the text paths paste text. Not run on Linux.
Reported in #898: typing `-` under a paragraph to start a list turned the
paragraph into a heading in the editor, the outline and the Preview, and
the note kept it after a restart.

CommonMark reads a lone `-` under a line as a setext underline, because an
empty list item may not interrupt a paragraph, so the line above became a
level-2 heading the moment the dash was typed. That is correct to the spec
and wrong for a notes app: a lone dash under a line starts a list far more
often than it underlines a heading.

ZenNotes now keeps that line a paragraph, with the dash as its last line,
and ends the paragraph on the dash line, where the heading would have
ended, so every line after it parses exactly as before. `--`, `---` and `=`
underlines are still headings. The rule holds across every parser of note
markdown: the editor grammar (a Lezer leaf parser ahead of the setext one,
also given to the template editor), the outline, and every remark renderer
through one shared plugin (Preview, PDF, email, DOCX, and the share viewer
and Quick Look, which render with the Preview's pipeline). DOCX export now
runs its tree through the transformers, which it used to skip. The zn
CLI's outline follows in ZenNotes/tui.

The deliberate cost: other Markdown renderers, GitHub's included, still
show such a line as a heading. The note text is unchanged.

Verified in the built app over CDP: before, a line over `-` or `- ` carried
tok-heading2 in the editor, was listed in the outline and rendered as <h2>;
after, it is a plain paragraph in all three, typing a line, Enter, `-`
leaves the line plain, and `--` and `---` still make headings.
…901)

Reported in #901: with config.toml in a dotfiles repo shared by a Mac and
a Fedora machine, opening ZenNotes on the other OS changed 14 lines, and
opening it on the first one changed them back.

Launch rewrites the file whenever its canonical text differs from what is
on disk, and the canonical text included the commented keymap reference
rendered with this platform's defaults. The 14 actions with their own Mac
default (tab switching, previous note, marker hops, reflow, new note from
template) rendered differently on each OS, so the two machines never
agreed. The comments never changed behavior; they only churned the file.

The reference no longer depends on the platform: each line shows the
cross-platform default, and an action whose Mac default differs notes it
after its title. Every machine renders the same bytes, so after one
rewrite by this version the file changes only when a setting does. The
manual's config file entry says so.

What it deliberately does not do: give overrides a cross-platform form.
An override still applies as written on every OS; that is the separate
request at the end of the issue.

Verified in the built app with isolated stores: before, a Linux-written
file opened on macOS had 14 reference lines rewritten; after, it is
rewritten once into the shared form and the next launch leaves it
byte-identical. app-config.test.ts requires darwin, linux and win32 to
render the same.
The bundled CLI is the floor a desktop build guarantees, and 0.6.3 is
the newest release: it carries the #898 rule, so zn's outline reads a
line over a lone `-` as a paragraph, the same as the app. The pin is the
release's terminal-release.json copied byte for byte after it verified
against packaging/release-signing/zn-release-1.pub in ZenNotes/tui
(source commit e608fe3, integration protocol 1, all four archives
matching checksums.txt). Staged through `npm run terminal:stage`; the
native darwin-arm64 binary reports zn v0.6.3. The in-app manual's CLI
card says 0.6.3 and what it changes.
The clipboard fix in d8b9f1c lets "+p, "*p, insert-mode Ctrl-R + and,
with Sync clipboard with Vim registers on, p and P paste an image the
way Cmd/Ctrl+V does. The manual's entry for that setting still talked
about text only; it now says an image lands in assets/ and is embedded,
and that "+p, "*p and Ctrl-R + read the system clipboard even with the
setting off.
The release PR's production audit failed on three advisories published on
2026-10-05 and 06: proxy-addr below 2.0.8 (critical, IP spoofing through
an IPv4-mapped IPv6 trust subnet; it arrives through the MCP SDK's
Express), @modelcontextprotocol/sdk below 1.31.0 (high, its OAuth client
could send credentials to an authorization server the MCP server picks;
the app's MCP server does not use that client), and source-map-js below
1.2.2 (high, event-loop denial of service; through Excalidraw's sass,
which no longer ships, and node-tikzjax).

Each moves to its first fixed version and no further: proxy-addr 2.0.8
and source-map-js 1.2.2 in the lockfile, and the desktop's MCP SDK range
to ^1.31.0 at 1.31.0 (npm now nests it under apps/desktop, its only
user; main bundles it, so the packaged layout does not change). The MCP
server built with 1.31.0 answers initialize, lists its 34 tools and lists
a scratch vault's notes over stdio; typecheck, every test suite, the
signed pack and the packaged launch check pass, and the production audit
is clean at high.
@adibhanna
adibhanna merged commit dc8fe10 into main Oct 6, 2026
9 checks passed
@adibhanna
adibhanna deleted the v2.63.0 branch October 6, 2026 21:37
@adibhanna
adibhanna restored the v2.63.0 branch October 6, 2026 21:37
@adibhanna
adibhanna deployed to boundary-artifacts October 6, 2026 21:42 — with GitHub Actions Active
@adibhanna
adibhanna deployed to boundary-artifacts October 6, 2026 21:42 — with GitHub Actions Active
@adibhanna
adibhanna deployed to boundary-artifacts October 6, 2026 21:47 — with GitHub Actions Active

This branch was successfully deployed

1 active deployment
boundary-artifacts — dc8fe105 Deployed Oct 6, 2026 by adibhanna via draft #33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant