Embed @napi-rs/keyring native bindings for all CLI release targets

[ChiragAgg5k]

What

The compiled CLI binaries ship without the @napi-rs/keyring native binding for every target except linux-x64, so on macOS/Windows/linux-arm64 the CLI silently stores OAuth refresh tokens in plaintext (~/.appwrite/prefs.json) instead of the OS keychain. No crash — silent downgrade.

Reproduced on a released 22.2.1 Homebrew binary (darwin-arm64): the native keyring symbols are absent, and appwrite login writes the refresh token in plaintext.

Root cause

The keyring loader code (literal per-platform require) shipped already. The missing half is the build:

templates/cli/.github/workflows/publish.yml cross-compiles all six bun --compile targets on a single ubuntu-latest host after one bun install --frozen-lockfile. @napi-rs/keyring's native binding is delivered as os/cpu-gated platform packages, so that install only fetches the host's — @napi-rs/keyring-linux-x64-gnu. bun --compile embeds a .node only when its platform package is present on disk, so every other target (darwin-arm64, darwin-x64, linux-arm64, win32-*) is compiled with no binding to embed and falls back to plaintext at runtime. bun does not error on the missing cross-target package — it silently omits it, which is why the broken build shipped green.

Fix

Before cross-compiling, fetch each target's platform package directly from the npm registry (a plain tarball extract, which bypasses the os/cpu install skip) into node_modules, so bun --compile can embed the matching .node for every target.

Verified locally

• Cross-built linux-x64 on macOS with its platform package missing → builds fine, 0 embedded bindings (reproduces the shipped bug).
• Fetched the platform package via the tarball, rebuilt → binding embedded.
• The exact workflow snippet (version auto-detected from the installed umbrella package, loop over all six triples) fetches all six packages successfully.

Scope

• publish.yml is copy scope; only the template is committed (generated examples/cli is gitignored).
• Once merged, regenerate sdk-for-cli and cut a 22.2.2 so released binaries actually use the keychain. The access token stays in prefs.json by design (short-lived); only the long-lived refresh token moves to the keychain.

[greptile-apps]

Greptile Summary

This PR updates the CLI publish workflow to include keyring native bindings in release binaries. The main changes are:

• Splits dependency installation from binary compilation.
• Downloads @napi-rs/keyring native packages for all six release targets before building.
• Builds the Linux, macOS, and Windows CLI binaries after the native bindings are present.

Confidence Score: 5/5

The workflow-only change is merge-safe and directly addresses the missing native package inputs for cross-compiled CLI release targets.

The update is narrowly scoped to the publish workflow, fetches the expected platform packages before compilation, and has no accepted code issues.

T-Rex Logs

What T-Rex did

• Observed the initial install state showing only host keyring-linux-x64-gnu among the six release targets, with five target directories missing.
• Validated the final install state after the fetches, with successful fetches for darwin-arm64, darwin-x64, linux-x64-gnu, linux-arm64-gnu, win32-x64-msvc, and win32-arm64-msvc, and missing_target_dirs=0 and targets_missing_native_node=0.

_{Ran code and verified through T-Rex}

_{Reviews (2): Last reviewed commit: "Split keyring binding fetch into its own..." | Re-trigger Greptile}