- update.rs: Umstellung auf Package-Registry-Manifest mit SHA256-Verify, Basic-Auth, dev/APPIMAGE/Nix-Wrapper-Modus. Liest binary_filename im Nix-Modus (AppImage laeuft auf NixOS nicht) - Nix-Wrapper-Paket (nix/default.nix): LD_LIBRARY_PATH-korrekter Launcher + Installer-Script, User-Home-Binary (writable fuer Auto-Update) - CI laedt jetzt AppImage UND natives Binary + update.json v2 (binary_filename/binary_sha256) in die Package Registry - Svelte: Store-basierter Update-Trigger, manueller Check im Settings-Panel, "Kein Update"-Dialog-Variante, expectedSha256-Param - install.sh: One-Click-Installer fuer NixOS (curl | bash) - sha2-Dep fuer Integritaets-Check des Downloads Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.8 KiB
Claude Desktop — Native Build auf NixOS
Anleitung für den nativen Produktiv-Build auf NixOS. Das CI-AppImage funktioniert auf NixOS nicht (WebKit2GTK/Mesa EGL-ABI-Konflikt, siehe KB #381) — deshalb wird hier immer nativ über die Nix-Dev-Shell gebaut.
Voraussetzungen
- NixOS-System mit
nix-shellim PATH shell.nixim Projekt-Root (liefert Rust, Node 22, WebKitGTK 4.1, GTK3, OpenSSL, libsoup3 etc.)- Projekt liegt auf SMB-Mount —
/mnt/17 - Entwicklungen/20 - Projekte/ClaudeDesktop
Warum CARGO_TARGET_DIR=/tmp/...?
Das Projekt liegt auf einem SMB-Share. Cargo kann dort nicht zuverlässig schreiben (I/O-Errors bei Lockfiles, Rename-Operationen scheitern). Deshalb muss das Build-Target auf ein lokales Dateisystem (tmpfs/ext4) umgeleitet werden. Siehe KB #382.
Build-Befehl (der Pflicht-Weg)
CARGO_TARGET_DIR=/tmp/claude-target \
nix-shell shell.nix --run 'npm ci && npm run tauri build -- --bundles appimage'
Phasen:
npm ci— Frontend-Abhängigkeiten (überspringbar wennnode_modules/aktuell ist)- SvelteKit-Build — produziert
build/(Vite) - Cargo-Build
--release— kompiliert Rust-Binary in/tmp/claude-target/release/claude-desktop - Tauri-Bundle (AppImage) — crasht auf NixOS oft in der pkg-config-Phase von
linuxdeploy
Das Bundling darf scheitern — das Binary aus Phase 3 ist trotzdem lauffähig.
Binary starten
nix-shell shell.nix --run /tmp/claude-target/release/claude-desktop
Der Start muss durch nix-shell laufen, damit LD_LIBRARY_PATH korrekt gesetzt ist (WebKitGTK, GTK3 etc.).
Inkrementelle Builds
Nach Code-Änderungen reicht:
CARGO_TARGET_DIR=/tmp/claude-target \
nix-shell shell.nix --run 'npm run tauri build -- --bundles appimage'
- Nur Rust geändert → Cargo baut inkrementell neu (~10–60 s)
- Nur Frontend geändert → Vite+Cargo linken neu (~30 s)
- Abhängigkeiten neu → erster Cargo-Build dauert 5–15 min
Typische Fehler
| Symptom | Ursache | Fix |
|---|---|---|
error: could not write to ... |
Cargo auf SMB | CARGO_TARGET_DIR=/tmp/... vorne anstellen |
pkg-config exited with status code 1 am Ende |
Tauri-Bundler-Bug bei AppImage auf NixOS | ignorieren, Binary ist fertig |
EGL_BAD_PARAMETER beim Start |
AppImage statt nativem Binary gestartet | /tmp/claude-target/release/claude-desktop direkt starten |
webkit2gtk-4.1 not found |
außerhalb von nix-shell |
Start immer via nix-shell shell.nix --run … |
rustc: command not found |
außerhalb von nix-shell |
siehe oben |
Hot-Reload-Dev-Mode (Alternative)
Für UI-Entwicklung reicht meist der Dev-Modus — kein Release-Build nötig:
nix-shell shell.nix --run 'npm ci && npm run tauri:dev'
Vite auf Port 1420 + Tauri-Window. Rust wird unoptimiert gebaut, deutlich schneller für Iteration.