Introduce the Electron desktop shell alongside the existing React renderer and local Bun server boundary. The migration keeps the DesktopHost contract explicit across Tauri, Electron, and browser runtimes while adding Electron main/preload services for dialogs, shell, notifications, updates, tray/window lifecycle, terminal, preview WebContentsView, app mode, and release/package validation.
The commit also carries the latest local main desktop command updates, including agent slash entries and hidden-by-default markdown thinking details, so the packaged Electron build matches the current main UX surface.
Constraint: React renderer, local Bun server, REST/WebSocket, and sidecar boundaries must remain reusable during the migration
Constraint: macOS dev packages are ad-hoc signed and cannot prove Developer ID notarization or Gatekeeper release launch
Rejected: Browser-only smoke validation | it cannot exercise native dialogs, keychain prompts, notification behavior, or packaged app startup
Confidence: medium
Scope-risk: broad
Directive: Do not remove Tauri host support until signed Electron release artifacts pass native OS smoke on macOS, Windows, and Linux
Tested: bun run check:desktop
Tested: cd desktop && bun run check:electron
Tested: CSC_IDENTITY_AUTO_DISCOVERY=false bun run electron📦dir
Tested: bun run test:package-smoke --platform macos --package-kind dir --artifacts-dir desktop/build-artifacts/electron
Tested: Computer Use read packaged Electron app window at desktop/build-artifacts/electron/mac-arm64/Claude Code Haha.app
Not-tested: Developer ID signed/notarized Gatekeeper launch
Not-tested: Real OS notification click-to-session action
Not-tested: Windows and Linux packaged app smoke on real hosts
Tauri runs the repository beforeBuildCommand during packaging, which invokes build:sidecars again after the explicit sidecar step has already passed. The Windows runner therefore still needs the same Bun compile cache override inside the packaging step so the repeated baseline runtime extraction stays on the runner work drive.
Constraint: Tauri beforeBuildCommand re-enters the sidecar build under the packaging step environment.
Rejected: Remove beforeBuildCommand from CI | that would diverge CI from normal Tauri packaging behavior.
Confidence: high
Scope-risk: narrow
Directive: Keep explicit sidecar build and Tauri packaging environments in sync when changing desktop workflow target or cache settings.
Tested: bun test scripts/pr/release-workflow.test.ts; bun run check:policy
Not-tested: GitHub Actions Windows runner rerun after push.
Windows GitHub runners keep the checkout and Bun install cache on different drives, which can trip Bun's baseline compile-target extraction before Tauri packaging starts. Point desktop sidecar builds at the runner temp cache so dev and release workflows can still use the Windows x64 baseline runtime needed for older CPUs.
Constraint: Bun upstream still has an open Windows cross-drive extraction issue for compile target downloads.
Rejected: Revert to bun-windows-x64 | would reintroduce the older-CPU Illegal Instruction failure class.
Confidence: high
Scope-risk: narrow
Directive: Keep desktop dev and release sidecar build cache handling aligned until Bun's Windows extraction fix is released and verified in Actions.
Tested: bun test scripts/pr/release-workflow.test.ts; cd desktop && bun run test -- --run scripts/build-sidecars.test.ts; bun run check:policy; cd desktop && BUN_INSTALL_CACHE_DIR=/tmp/cc-haha-bun-install-cache TAURI_ENV_TARGET_TRIPLE=x86_64-pc-windows-msvc bun run build:sidecars
Not-tested: GitHub Actions Windows runner rerun after push.
Windows releases were shipping both NSIS exe and MSI bundles, which made the
release page harder to understand and increased the chance that users would
pick the wrong asset. Restricting Windows output to MSI narrows the installer
surface while the release asset naming now spells out platform, architecture,
and bundle type directly in every published filename.
Constraint: Remote desktop packaging is triggered by GitHub Actions releases, not local uploads
Constraint: Updater metadata must keep latest.json stable for existing clients
Rejected: Keep publishing both NSIS and MSI with better docs | still leaves the higher-risk installer on the release page
Rejected: Rename assets manually after upload | easy to drift from workflow output and updater metadata
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: If Windows exe bundles are reintroduced later, reassess SmartScreen and AV impact before publishing them again
Tested: YAML parse for both desktop workflows; git diff --check on modified files; manual review of PowerShell changes
Not-tested: End-to-end GitHub Actions release run; PowerShell parser validation on a Windows host
GitHub Actions showed that Linux compilation and .deb packaging succeed on both x64 and ARM64, but AppImage consistently fails inside linuxdeploy. The workflows now ship Linux as .deb only so CI and releases stay reliable while the AppImage path is investigated separately.
Constraint: Current GitHub-hosted Linux packaging fails specifically in linuxdeploy after successful .deb output
Rejected: Keep AppImage enabled and accept red workflows | blocks release confidence for an optional format
Rejected: Drop Linux builds entirely | would remove a working .deb delivery path
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Re-enable AppImage only after capturing linuxdeploy stderr and validating both Linux architectures on GitHub Actions
Tested: git diff --check; YAML parse of both workflow files; inspection of failed GitHub Actions logs showing .deb success before AppImage linuxdeploy failure
Not-tested: Re-run of updated workflows on GitHub Actions
The local desktop build path already proved that AppImage packaging needs libfuse2 and that macOS artifacts may be directories rather than plain files. This commit aligns the GitHub workflows with those realities so remote validation matches the local release path more closely.
Constraint: GitHub-hosted Linux runners do not guarantee AppImage runtime deps unless we install them explicitly
Rejected: Leave release workflow unchanged and trust local macOS build only | would not validate Linux packaging path at all
Rejected: Upload only DMG/installer files in dev workflow | hides the macOS .app artifact users expect for local testing
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep dev and release desktop dependency lists in sync when packaging requirements change
Tested: git diff --check; YAML parse of both workflow files; manual inspection of artifact collection and Linux dependency steps
Not-tested: Live GitHub Actions execution on repository runners
