Windows desktop port#520
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Windows CI jobs for signed and PR builds, pins and provisions Windows ONNX Runtime with checksum verification, tightens Tauri filesystem capabilities to ChangesWindows Desktop Build Support
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying maple with
|
| Latest commit: |
8ed48d8
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://cbf80b53.maple-ca8.pages.dev |
| Branch Preview URL: | https://windows-pr1-compile-launch.maple-ca8.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
from
bbb7960 to
a4161cd
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
I've been making significant updates to the build processes, you'll likely want to rebase and standardize around them at some point |
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
from
1aa2673 to
2c4e927
Compare
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
2 times, most recently
from
19b863d to
4e074dc
Compare
Rebased the PR and updated to follow some of the new patterns you set up. All builds are passing and I was able to download the windows installer and run on my VM successfully |
Three minimum-viable changes to unblock building Maple on Windows. Atomic migration, keyring storage, signing, TTS DLL shipping, and the CI matrix job are deferred to follow-up epics. tauri.conf.json (MPLR-uyqowcnn / 1a): - bundle.targets switched from "all" to an explicit list excluding "msi". Tauri's WiX template hard-codes HKLM + perMachine install, which would shadow the HKCU keys we rely on for cloud.opensecret.maple deep links. - bundle.windows.nsis.installMode = "currentUser" so the NSIS installer is per-user (no UAC) and writes deep-link registration under HKCU. - bundle.windows.webviewInstallMode.type = "downloadBootstrapper" set explicitly to avoid surprise behavior if the Tauri default changes. capabilities/default.json (MPLR-zivybmgl / 1b): - Dropped $HOME/.config/maple/** scope entries from every fs:allow-* permission. The path tokens don't resolve to anything meaningful on Windows, no JS code touches them via the Tauri fs plugin, and proxy.rs writes via raw std::fs which bypasses the capability system entirely. $APPCONFIG/** entries are kept. src/proxy.rs (MPLR-oshibkah / 1c): - get_config_path now takes &AppHandle and resolves to %APPDATA%\cloud.opensecret.maple\ on Windows via Tauri's path resolver. macOS and Linux behavior is byte-identical (still ~/.config/maple/). - AppHandle is plumbed through save_proxy_config, load_saved_proxy_config, start_proxy, load_proxy_config, save_proxy_settings, and the auto-start initializer. Frontend invoke() calls are unchanged — Tauri auto-injects AppHandle on commands. - USERPROFILE fallback removed; Windows now uses the proper Tauri path. cargo check + cargo clippy -D warnings + cargo fmt --check all pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Introduces Windows as a third desktop build target across both desktop CI
workflows. Both jobs are born conformant with the patterns shipped during
PR review (pinned actions, Bun 1.3.5, Rust 1.95.0, sha256-verified binary
fetches via onnxruntime-pins.sh + sibling helper script).
desktop-build.yml (MPLR-hzehaxpp / 1e):
- New build-windows job runs on push to master, mirrors build-macos /
build-linux step-for-step, builds via tauri-action (signing env wired
up so the action doesn't error mid-build, though Authenticode is
deliberately out of scope here), uploads the .exe artifact.
- All third-party actions SHA-pinned to the same commits used by the
Linux/macOS jobs: actions/checkout, oven-sh/setup-bun,
dtolnay/rust-toolchain, actions/cache, tauri-apps/tauri-action,
actions/upload-artifact.
- bundle.targets in tauri.conf.json already constrains the Windows build
to NSIS (MPLR-zsvmhjjx / 1i), so the redundant `--bundles nsis`
tauri-action arg is omitted.
desktop-pr-build.yml (MPLR-hzehaxpp / 1e):
- Parallel build-windows job runs on pull_request, modeled on the
existing macOS/Linux PR jobs: no secrets, no codesigning, no updater
artifacts (`bun tauri build --no-sign --config '{"bundle":{"createUpdaterArtifacts":false}}'`),
dev-environment VITE URLs, artifact suffixed `-pr`.
sccache install (MPLR-gelmlpfg / 1h):
- Mirrors the Linux job's style (long-form curl, `sha256sum --check -`,
current-dir extract). Windows twist: download/verify/extract run inside
a subshell cd'd to RUNNER_TEMP so all paths stay relative. MSYS2 tar
mangles absolute D:\ paths passed via -C/-f even with --force-local;
relative paths sidestep it. Inline comment explains.
ONNX Runtime install (MPLR-hzehaxpp / 1e):
- New provide-windows-onnxruntime.sh helper mirrors
provide-linux-onnxruntime.sh one-for-one: same sha256_file /
verify_sha256 helpers, archive + DLL double SHA256 verify, emits
ORT_LIB_LOCATION / ORT_SKIP_DOWNLOAD / ORT_DYLIB_PATH for the
GITHUB_ENV file. Workflow step reduces to a single invocation piped to
GITHUB_ENV.
- onnxruntime-pins.sh extended with windows_x64_archive_sha256 and
windows_x64_dll_sha256 lookups for 1.22.0 (matches the existing
linux_x64 pattern).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
from
4e074dc to
c5e79a2
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/desktop-build.yml (1)
3-7: 💤 Low valueScope elevated permissions to only the jobs that need them.
The
id-token: write,attestations: write, andartifact-metadata: writepermissions are only used by attestation steps inbuild-macosandbuild-linuxjobs, but they're declared at workflow level, granting them to all jobs includingbuild-windowswhich doesn't perform attestation.Consider moving these to job-level
permissionsblocks on just the jobs that need them (following the pattern already used byverify-desktop-artifactsat lines 177-178).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/desktop-build.yml around lines 3 - 7, The workflow-level permissions currently grant id-token: write, attestations: write, and artifact-metadata: write to every job; move those three permissions out of the top-level "permissions" block and add them only to the job-level "permissions" blocks for the build-macos and build-linux jobs (the jobs named build-macos and build-linux), leaving the workflow-level permissions with only the minimal required scope (e.g., contents: read) so build-windows and other jobs do not receive elevated attestation permissions; follow the existing pattern used by the verify-desktop-artifacts job to copy the exact id-token/attestations/artifact-metadata entries into the two attestation jobs.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/src-tauri/capabilities/default.json`:
- Around line 14-30: proxy.rs currently writes proxy_config.json to a hardcoded
"~/.config/maple" on non-Windows, which falls outside the allowed capability
$APPCONFIG; change proxy.rs to use the same app_config_dir() helper used
elsewhere (call app_config_dir() / join "proxy_config.json") to compute the
config directory, create the directory if missing, and write/read
proxy_config.json there so it matches the capability scope; alternatively, if
you prefer widening capabilities instead, update
frontend/src-tauri/capabilities/default.json to allow the actual
"~/.config/maple" and macOS equivalent paths (or a broader pattern) so the
write/read of proxy_config.json is permitted.
---
Nitpick comments:
In @.github/workflows/desktop-build.yml:
- Around line 3-7: The workflow-level permissions currently grant id-token:
write, attestations: write, and artifact-metadata: write to every job; move
those three permissions out of the top-level "permissions" block and add them
only to the job-level "permissions" blocks for the build-macos and build-linux
jobs (the jobs named build-macos and build-linux), leaving the workflow-level
permissions with only the minimal required scope (e.g., contents: read) so
build-windows and other jobs do not receive elevated attestation permissions;
follow the existing pattern used by the verify-desktop-artifacts job to copy the
exact id-token/attestations/artifact-metadata entries into the two attestation
jobs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9b2786d9-b94d-40c7-9414-c2e5b356b8b9
📒 Files selected for processing (7)
.github/workflows/desktop-build.yml.github/workflows/desktop-pr-build.ymlfrontend/src-tauri/capabilities/default.jsonfrontend/src-tauri/scripts/onnxruntime-pins.shfrontend/src-tauri/scripts/provide-windows-onnxruntime.shfrontend/src-tauri/src/proxy.rsfrontend/src-tauri/tauri.conf.json
💤 Files with no reviewable changes (4)
- frontend/src-tauri/tauri.conf.json
- frontend/src-tauri/scripts/onnxruntime-pins.sh
- frontend/src-tauri/scripts/provide-windows-onnxruntime.sh
- frontend/src-tauri/src/proxy.rs
| path: | | ||
| frontend/src-tauri/target/release/bundle/nsis/*.exe |
There was a problem hiding this comment.
🟡 Windows release build discards updater artifacts (.nsis.zip and .nsis.zip.sig)
The Windows release build in desktop-build.yml provides TAURI_SIGNING_PRIVATE_KEY and TAURI_SIGNING_PRIVATE_KEY_PASSWORD env vars, and tauri.conf.json:113 has "createUpdaterArtifacts": true. This means Tauri will generate signed updater artifacts (.nsis.zip and .nsis.zip.sig) alongside the .exe installer in the nsis/ bundle directory. However, the upload step only globs *.exe, so the updater artifacts are silently discarded. This is inconsistent with the Linux release build which correctly uploads both packages and their .sig files. If these artifacts are needed for Windows auto-update support (the updater plugin is active in tauri.conf.json:14), they will be missing from the uploaded CI artifacts.
| path: | | |
| frontend/src-tauri/target/release/bundle/nsis/*.exe | |
| path: | | |
| frontend/src-tauri/target/release/bundle/nsis/*.exe | |
| frontend/src-tauri/target/release/bundle/nsis/*.nsis.zip | |
| frontend/src-tauri/target/release/bundle/nsis/*.nsis.zip.sig | |
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
Fixed in 359bbd0 — the Upload Windows Build step now globs *.nsis.zip and *.nsis.zip.sig alongside *.exe, matching the Linux job so the signed updater artifacts are preserved.
proxy.rs writes proxy_config.json to ~/.config/maple on macOS/Linux (byte-identical behavior deferred to PR3's app_config_dir() unification), but the capability only allowed $APPCONFIG/** ($APPCONFIG resolves to the bundle-identifier dir, e.g. ~/.config/cloud.opensecret.maple on Linux). Those writes fell outside the allowed scope and failed with permission errors. Restore the $HOME/.config/maple entries to match proxy.rs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The build-windows job signs builds and tauri.conf.json sets createUpdaterArtifacts: true, so Tauri emits .nsis.zip and .nsis.zip.sig alongside the .exe installer. The upload step only globbed *.exe, silently discarding the updater artifacts (inconsistent with the Linux job). Add the .nsis.zip and .nsis.zip.sig globs so auto-update artifacts are preserved. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Does this have full feature compatibility? |
most features work - login, chat, voice record, file picker, search, folders. I'll be following up with some other updates over the next couple of days -
|
|
I’d say keeping working on that in a single PR then. No point in splitting things across many PRs and merging in incomplete code. also don’t spend any more extra time on any cicd or development setup scripts or anything. All of that is going to be redone with my new nixos reproducible build setup. |
Sounds good, happy to run it that way. I'll close my other PR and convert this back to a draft for now so it can all land together. 👍 |
On Windows the proxy config lives in the roaming %APPDATA% profile, so a plaintext api_key could sync across machines in a domain/AAD environment. Store it in Credential Manager via keyring (windows-native) and scrub it from the JSON; restore it on load. If secure storage is unavailable, fall back to plaintext-in-JSON. All keyring code and the dependency are gated to target_os="windows" — macOS/Linux keep their existing local plaintext-with-0o600 behavior, byte-for-byte unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
On Windows, OAuth/payment deep links only reach the app if HKCU\Software\Classes\cloud.opensecret.maple\shell\open\command points at the running exe. A missing or stale key (installer skipped, dev build deleted, exe moved) silently breaks the OAuth callback with no signal. Log the result of DeepLinkExt::is_registered() once at startup so support can diagnose "the callback button does nothing" reports. Windows-gated; no behavior change on macOS/Linux. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "Desktop" card listed only "macOS • Linux". Windows is now a supported desktop target, so include it. Listed last to reflect relative priority. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ldstreet
changed the title
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
from
79de99f to
022613d
Compare
maple.exe links onnxruntime.dll by ordinal. On a clean Windows install the
loader binds that import to the OS-shipped Windows-ML onnxruntime.dll (a
forwarder to onnxruntime_x64.dll, currently v1.17), which lets the app launch
but hangs TTS at the first Session::builder call.
Ship ONNX Runtime 1.22.0 and its four MSVC C++ runtime DLLs (VCRUNTIME140,
VCRUNTIME140_1, MSVCP140, MSVCP140_1) next to maple.exe so the executable's
own directory wins the Windows DLL search order over System32. The four CRT
DLLs are deployed app-local (rather than via vc_redist) to avoid a UAC prompt
on the per-user install.
Deployment uses an NSIS installer hook, not bundle.resources: in Tauri 2.11 a
resources map supplied via the platform config gets the DLLs into the installer
payload but not into the NSIS install file-list, so they never land in the
install dir (verified: only maple.exe + uninstall.exe were installed). The hook
copies them explicitly into $INSTDIR and removes them on uninstall.
- resources/windows/install-dlls.nsh: NSIS_HOOK_POSTINSTALL File-copies the 5
DLLs from <src-tauri>/resources/windows into $INSTDIR (anchored on
${MAINBINARYSRCPATH}); NSIS_HOOK_PREUNINSTALL deletes them.
- tauri.windows.conf.json: register the hook via bundle.windows.nsis.installerHooks
(Windows-only; macOS/Linux/iOS unaffected).
- resources/windows/: README + .gitignore (the redistributable DLLs are staged
at build time, not committed).
- desktop-pr-build.yml / desktop-build.yml: stage the 5 DLLs into
resources/windows before the Tauri build, from the already-downloaded ORT
(ORT_DYLIB_PATH) and the MSVC CRT redist located via vswhere (year/edition
agnostic, with a System32 fallback).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ldstreet
force-pushed
the
windows/pr1-compile-launch
branch
from
022613d to
260af74
Compare
The desktop menu was built as a flat in-window bar on Windows/Linux (About / Check for Updates / Undo / Redo / Cut / Copy / Paste / Select All / Quit), adding a cluttered, dated row at the top of the window. The edit items are handled natively by the webview regardless of the menu, About is available in the in-app account menu, and updates are applied by the automatic check (startup + hourly), so the bar added only noise. Gate the entire menu-creation block (and its event handler) to macOS, which keeps its proper nested app/Edit submenus. Windows and Linux now get a clean window with just the title bar. The updater auto-check loop is untouched and still uses check_for_updates, so no code is orphaned. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 participants
Summary
Brings the Tauri desktop app to Windows (x64, NSIS installer).
This is the single consolidated PR for the Windows port. Per maintainer direction it replaces the earlier stacked PR-per-slice plan and grows until Windows reaches feature parity, rather than merging incomplete slices across many PRs.
Build/CI/dev-setup is intentionally minimal here. The reproducible build + release pipeline (likely cross-compilation via nix) is owned by the maintainer and lands after the Windows app is in a good place. The
windows-latestCI job in this PR is an interim compile/build gate only — a placeholder to keep the app building until that pipeline replaces it.What's included
windows-latestjobs produce an unsigned NSIS build on both master-push and PRs.%APPDATA%(Tauriapp_config_dir()); API key stored in Windows Credential Manager (keyring) and scrubbed from the JSON, with plaintext fallback if secure storage is unavailable. macOS/Linux behavior byte-for-byte unchanged.cloud.opensecret.maple://registered via the NSIS template + runtimeregister();installMode: currentUser;msiexcluded from bundle targets. Adds a Windows startup diagnostic loggingis_registered()to debug "OAuth callback does nothing" reports.Still pending (toward full feature parity)
onnxruntime.dllon WindowsScope notes
/downloadspage is left as-is (superseded by trymaple.ai/research#download).Test plan
build-windowsCI (master-push + PR) stays green%APPDATA%config + Credential Managerstart cloud.opensecret.maple://auth?...from cmd focuses the app and logs the deep link🤖 Generated with Claude Code