Add launch-at-login via tauri-plugin-autostart

[cohogan]

Summary

• Adds the tauri-plugin-autostart plugin (LaunchAgent on macOS, HKCU\...\Run key on Windows, .desktop entry on Linux) with autostart:default granted in the desktop capability
• Adds a Launch at Login toggle to the settings sheet: reads the OS state when the sheet opens, applies enable/disable on Save
• Adds src-tauri/tests/autostart.rs, the first Rust integration test in the repo: round-trips enable()/disable() and independently asserts the Windows Run registry entry is created and removed
• build.rs: embeds the Common Controls v6 manifest into test binaries only so cargo test does not crash with STATUS_ENTRYPOINT_NOT_FOUND on Windows (known issue, see tauri-apps discussion #11179); the app build is unchanged

Testing

• cargo test --test autostart passes: enable → is_enabled() true and reg query shows the Run entry → disable → entry gone
• Verified live in the running dev app over real Tauri IPC (via WebView2 remote debugging): plugin:autostart|enable / is_enabled / disable all succeed from the main window, and HKCU\Software\Microsoft\Windows\CurrentVersion\Run gained/lost the Labric Sync entry accordingly — confirming plugin registration and capability permissions end to end
• cargo clippy clean, pnpm build (tsc + vite) passes
• Not covered: clicking the toggle itself in a paired/logged-in app (the settings sheet lives behind auth); the switch calls the same plugin functions verified above

Notes

• In dev, enabling registers the dev binary path; packaged builds register the installed exe
• Follow-up idea: pass a --minimized launch arg and start hidden in the tray when launched at login

🤖 Generated with Claude Code

[github-actions]

Claude finished @cohogan's task in 1m 46s —— View job

---

Code Review: Add launch-at-login via tauri-plugin-autostart

• Read all changed files
• Review Rust backend changes
• Review frontend changes
• Review test and build changes
• Post review findings

---

Overall this is a clean, well-structured PR that follows the existing patterns in the codebase. The plugin wiring, capability grant, test, and UI toggle are all done correctly. A few observations below.

---

Findings

1. Partial save if autostart toggle fails — src/components/UploadSettingsDialog.tsx:112-119

handleSave calls updateConfig() first (which persists the upload settings), then calls enableAutostart()/disableAutostart(). If the autostart call throws, the catch block shows "Failed to save settings" — but the upload config has already been committed. The user sees an error toast, but their upload settings did change. A retry of Save would fix it (the upload config update is idempotent), so this is low-severity but worth noting.

A simple fix would be to swap the order (autostart first, then upload config) or to handle the autostart error independently:

// Option A: independent error handling
try {
  if (launchAtLogin) await enableAutostart();
  else await disableAutostart();
} catch (err) {
  console.error("Failed to toggle autostart:", err);
  toast.error("Failed to update launch-at-login setting");
}

Fix this →

2. Unconditional enable/disable on every save — src/components/UploadSettingsDialog.tsx:115-119

handleSave always calls enableAutostart() or disableAutostart() even when the toggle hasn't changed. These calls are idempotent so this is harmless, but you could compare against the OS state read on open to skip the unnecessary IPC round-trip.

3. Missing trailing newline — src-tauri/capabilities/desktop.json

The diff shows \ No newline at end of file. Minor style nit — most editors and linters prefer a trailing newline.

4. Test cleanup on panic — src-tauri/tests/autostart.rs:19-49

If the test panics between enable() (line 19) and disable() (line 45), the autostart entry is left on the test machine. Since it points at the test binary (which gets cleaned up by cargo), this is harmless in practice — just something to be aware of if this test ever runs in a shared CI environment.

---

What looks good

• Plugin registration (lib.rs:434-437): Correctly uses MacosLauncher::LaunchAgent and matches the pattern of other plugins. Placed under the same cfg(not(mobile)) conditional in Cargo.toml as tauri-plugin-updater.
• build.rs workaround (lines 14-23): Well-scoped to test binaries only via rustc-link-arg-tests, with a clear explanation and upstream issue link. Doesn't affect the app build.
• Test (autostart.rs): Clean round-trip structure using the Tauri mock builder. The Windows-specific reg query assertion is a nice touch for verifying OS-level side effects.
• UI toggle: Reads OS state on sheet open (not stale React state), follows the same Field + Switch pattern as the other toggles.
• Capability: autostart:default correctly added to the desktop capability file.

---

Verdict: Looks good to merge. Finding #1 (partial save) is the only one I'd consider addressing before merge, but it's low-risk given that autostart calls rarely fail and a retry resolves it.