fix(desktop): rewrite the tokenizers prebuild's install name before signing - #153

What failed

The v0.0.14 desktop release (run 34937845040) failed in Sign, notarize, publish → Verify bundle (pre-notarization):

[2/5] every Mach-O carries a Team ID
  scanned  18 Mach-O files
[3/5] no build paths baked into load commands
  FAIL     leaks a build path: Contents/Resources/app/node_modules/tokenizers/tokenizers.darwin-arm64.node
           /Users/runner/work/tokenizers/tokenizers/bindings/node/target/aarch64-apple-darwin/release/deps/libnode.dylib
BUNDLE GATE: FAIL

Why, and why it is our fixup to make

That path is the binary's LC_ID_DYLIB — its own install name, written by the publisher's CI:

LC_ID_DYLIB  /Users/runner/work/tokenizers/tokenizers/bindings/node/target/aarch64-apple-darwin/release/deps/libnode.dylib
LC_LOAD_DYLIB /usr/lib/libc++.1.dylib
LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib
LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib

tokenizers arrived with the delegate token counter (#150) and is loaded lazily by packages/dashboard/src/ingest/tokenizer.ts. This is the same defect mlx-core and @napi-rs/keyring ship with, and package.ts already rewrites both with install_name_tool -id @rpath/<file> on the staged copy, before packager/codesign. Rewriting the install name is therefore the established remedy here — not excluding the package (the token counter is a live feature) and not carving it out of the gate (the gate is what caught this).

stage-app.ts already ships exactly one slice of the package — its copy filter keeps only tokenizers.darwin-arm64.node — so a single rewrite covers the bundle.

The change (one file)

// The dashboard's delegate token counter imports `tokenizers` lazily, and
// stage-app ships exactly one slice of it. Its upstream LC_ID_DYLIB carries the
// publisher's CI path …, which is the same defect mlx-core and keyring arrive
// with, and step [3/5] of verify-bundle refuses it. Rewrite the staged copy.
const tokenizersBinary = 'tokenizers.darwin-arm64.node';
run('install_name_tool', ['-id', `@rpath/${tokenizersBinary}`, join(STAGE_APP, 'node_modules', 'tokenizers', tokenizersBinary)]);

Verification

I discarded an earlier attempt that carved third-party prebuilds out of step [3/5]; the real defect turned out to be fixable in the bundle, which keeps the gate absolute.

Re-releasing needs your call

The workflow checks out inputs.dry_run ? github.ref : refs/tags/<release_tag>, so:

• Validate this fix — dispatch with dry_run: true on main (or this branch): it builds and signs, and step [3/5] should pass.
• Publish v0.0.14 — not possible from the current tag: v0.0.14's tree does not contain this fix. Either move the tag onto the fixed commit, or cut 0.0.15 from main.

My recommendation is 0.0.15: the number 0.0.14 already exists (npm may hold it), and re-pointing a tag after a publish makes one version mean two different trees.