FileN

Recent Commits

• Dwynr(21 Jul 26)

  chore: bump version

• Dwynr(17 Jul 26)

  chore: bump version

• Dwynr(17 Jul 26)

  fix(ci): canonicalize the reference dir before computing relative paths Both Windows verify legs failed the payload-completeness diff with every path prefixed "64\": $env:TEMP on GitHub runners is the 8.3 short form (C:\Users\RUNNERA~1\...) while Get-ChildItem returns long paths, so the Substring-based relative computation cut two characters short and no reference file ever matched the (fully correct) install. Resolve the reference dir to its canonical long form after extraction. Covers both scripts - verify-update reuses Assert-Installation. The run itself was another clean bill of health for the product: full 250-file installs on both arches at the right location, Authenticode valid, registry entry and app-update.yml correct, and the WinFSP MSI confirmed installing on real Windows-on-ARM for the first time.

• Dwynr(17 Jul 26)

  fix(ci): match electron-builder's versioned Add/Remove Programs DisplayName Both Windows verify legs failed only on the registry assertion: the install itself succeeded on both arches - including the first correctly located arm64 install (C:\Program Files\Filen, full 250-file payload, genuine ARM64 Filen.exe), confirming the customInit fix on real Windows-on-ARM hardware. Defender: enabled on the windows-11-arm image (unlike windows-latest), zero detections - no AV interference. electron-builder writes the uninstall entry's DisplayName as "${productName} ${version}" ("Filen 3.0.51"), not the bare product name; Get-FilenUninstallEntry matched only the exact string "Filen". Match both shapes ("Filen" or "Filen <digit>...") without matching unrelated "Filen*" products. Validated under pwsh 7.6.3.

• Dwynr(17 Jul 26)

  fix(ci): repair the PowerShell array unrolling that broke both Windows verify legs verify-install-windows.ps1 died instantly on both arches with "the term 'p' is not recognized": Get-PythonCommand's single-element @("python") return gets unrolled by PowerShell into a bare string, the + became string concatenation, and $cmd[0] indexed the string - yielding the character 'p', which the script then tried to execute. Fix with exactly ONE layer of protection - @(...) at the call sites, plain array returns in the function. Validated empirically under real PowerShell 7.6.3 (portable pwsh): both the @("python") and @("py","-3") shapes now build correct argument arrays, the original bug reproduces in the test harness, and belt-and-braces (unary comma AND call-site @()) was itself caught producing a nested array that broke the two-element case. Add a lintCiScripts job (ubuntu, pwsh preinstalled) that parses every build/ci/*.ps1 and syntax-checks the sh/py scripts on every run - two PowerShell-only bugs have now shipped because nothing parsed these scripts before they reached a Windows runner.

• Dwynr(17 Jul 26)

  fix(updater): apply verifier polish - idempotency, timer hygiene, unload guard From the adversarial verification of 4b92ab4..23e693b (verdict: ship; all seeded hunts - beforeunload, launcher window, recover races, CI harness compatibility - traced clean against source): - guard installUpdate() against double invocation so a second call can't stack another error handler, quitAndInstall, and exit timer onto an install in flight - clear the macOS 30-minute staging failsafe inside recover() (dropped in the refactor; harmless since every path exits the process, but the old shape was right) - permit renderer unloads during the install via will-prevent-unload preventDefault: filen-web has no beforeunload today, but if one is ever added, the renderer would block the window close that macOS native quitAndInstall performs and stall the install until the failsafe - this keeps the windows-stay-alive invariant robust against future frontend changes

• Dwynr(17 Jul 26)

  fix(updater): keep the app alive if the user closes the window mid-install The listener removals in installUpdate() stay load-bearing (the worker's will-quit interceptor and the drive window's hide-to-tray close handler would block the update's quit - the historical "updater cannot close the app" bug). But removing window-all-closed also re-enables Electron's default quit-when-all-windows-close, and since the windows now stay alive through the install with their close interceptor gone, a user clicking X mid-install (macOS Squirrel staging especially) would quit the app and kill the install - a user-induced replay of the v3.0.4x symptom. Register a no-op window-all-closed listener for the install window: it suppresses the default quit but cannot block anything, so closing the window just lets the install finish headless and relaunch. Deliberately not a close-preventer: native quitAndInstall closes windows BEFORE emitting before-quit, so a close-blocking handler would stall the legitimate update quit itself.

• Dwynr(17 Jul 26)

  ci(updater): drive the E2E install through the renderer IPC bridge The update E2E previously invoked installUpdate() directly in the main process, bypassing the exact wiring a real user's Update click rides: renderer window.desktopAPI.installUpdate -> preload ipcRenderer.invoke("installUpdate") -> ipcMain.handle. A renamed channel or a broken preload bridge would have stranded every user's click while CI stayed green. In E2E mode the auto-install now executes window.desktopAPI.installUpdate() inside an existing window's renderer (retrying up to 10s for a window that carries the bridge - the drive window loads the preload even on the login screen), covering preload and ipcMain end to end, and falls back to the direct call with a logged warning if no bridge appears. The only slice of the user flow left uncovered is the React dialog component itself in filen-web.

• Dwynr(17 Jul 26)

  fix(updater): keep windows alive during install + relaunch on failure Build on the frontend's blocking update overlay (filen-web desktopUpdate.tsx locks itself the moment the user confirms and only resolves when the app goes away): stop destroying the windows in installUpdate(). The overlay now stays visible through the entire install - Squirrel staging on macOS (previously the app vanished for several silent seconds), the installer handoff on Windows, and the package-manager run on Linux (the polkit prompt now appears over the locked app instead of out of nowhere). Each platform's mechanism quits the app itself when ready to swap, closing the window naturally. Unify failure recovery across platforms: one updater error handler (rejected Squirrel staging, cancelled polkit prompt, failed installer spawn) plus the macOS 30-minute staging failsafe now app.relaunch() + exit instead of leaving - or previously on Linux, creating - a torn-down headless process that still holds the single-instance lock and blocks manual restarts. A failed update lands the user back in a working current-version app and the update can be retried. Give Linux the same stuck-quit exit failsafe Windows has (armed after BaseUpdater's synchronous install, so a long polkit prompt is never cut short); macOS keeps none by design - its quit is driven by Squirrel after staging and a fixed exit there is exactly the v3.0.46-v3.0.50 bug.

• Dwynr(17 Jul 26)

  ci: drop the CDN feed check for now Remove verify-cdn.yml and its script. The gap it covered stays known: nothing asserts that cdn.filen.io serves the manifests attached to the release - the verify suite validates artifacts, clients consume the CDN. Reintroduce later if wanted; the workflow_run-triggered shape from 60d4374 is the one that works with the sync ordering (the sync starts only after the build workflow succeeds, so an in-workflow check deadlocks).

• Dwynr(17 Jul 26)

  ci: move the CDN feed check to a workflow_run follow-up workflow The release->CDN sync starts only after the build workflow fully succeeds, so a verifyCdn job inside that workflow deadlocks: it waits on a sync that waits on the workflow's own success - and its guaranteed failure would have blocked the sync (and every release) outright. verify-cdn now lives in its own workflow triggered on completion of the build workflow for release events, starting exactly when the sync does and polling until the CDN byte-matches the manifests attached to the latest release (which is what the CDN's /release/latest/ path mirrors). By construction it is an alarm rather than a gate: a red run means deployed clients are being served a stale or partial feed and the sync needs fixing before the release is announced.

• Dwynr(17 Jul 26)

  fix+ci: apply the adversarial-review hardening across updater and verify suite Product fixes (from six per-platform/arch adversarial reviews of the verify suite, each traced against electron-updater 6.8.9 and the electron-builder 26.15.5 NSIS templates): - windows: install updates SILENTLY (quitAndInstall(true, true)). The assisted (oneClick:false) installer honors --force-run only in silent mode; non-silent - the long-standing shipped behavior - parks users on the wizard's Finish page after the app closes and never auto-relaunches. - windows arm64: fresh installs of the arm64-only installer landed in C:\Program Files (x86)\Filen (the verify suite's first-run catch). electron-builder's multiUser.nsh upgrades to $PROGRAMFILES64 only under "!ifdef APP_64"; the arm64 package defines APP_ARM64, so the x86 stub's WOW64 default won. customInit in build/installer.nsh corrects exactly that wrong default (preserving /D= and registry paths; still broken in electron-builder master, worth filing upstream). - route electron-updater's internal log stream into desktop.log - it was discarded, hiding exactly the diagnostics this week needed. - bound worker.stop() in installUpdate (a dead worker's stop never settles and would silently prevent the update from ever installing). - skip the top-level launch-failure app.exit when an update install is in flight (teardown-rejected startup steps must not kill Squirrel staging mid-flight). - macOS failsafe raised to 30 min: staging deep-verifies >1 GB in-process and can legitimately exceed 10 min on HDD-era Intel machines - the old cap would strand exactly the slowest cohort in an install-kill loop. - E2E hook is one-shot via FILEN_E2E_ONCE_FILE (the relaunched instance inherits the env on Windows/Linux and would loop forever). Verify-suite hardening: - update E2Es now serve the REAL manifests (version rewritten to 9.9.9) with every listed artifact, so the app's own file/arch selection runs against the production manifest shape - and assert the arch-correct file was chosen. Windows swap detection now uses a canary file + fresh process (NSIS restores payload mtimes, so mtime comparison could never fire); the uninstaller runs with an UNQUOTED _?= (Start-Process quoting silently broke every Delete inside it) and must leave no files and no registry entry; post-update re-runs the full installation assertions. - check-feed.py asserts the exact files[] set, files[0] contract, yml version, minimumSystemVersion VALUE (electron-updater fails open on a bad value), per-entry admin flags, and cross-arch contamination. - macOS: dmg and apps must be stapled (notarize-dmg.js soft-skips without creds), app-update.yml must point at the production CDN with no channel override, hdiutil detach retries, relaunch liveness + original-pid-exit asserted, updater log lines dumped on failure. - linux: deb postinst outcomes asserted (AppArmor profile, /usr/bin link, desktop entry - postinst soft-fails by design and a missing profile aborts the sandbox on stock Ubuntu 24.04), Fedora container pinned to registry.fedoraproject.org/fedora:42 with an ldd check, package-type absence also asserted for the zip (a leak would run an active deb/rpm updater for portable installs), rclone helper arch asserted, swapped AppImage byte-compared against the served artifact, relaunch liveness proven via the doubled E2E banner, sysctl take-effect asserted. - all E2Es: feed-server readiness probes and an early "E2E mode engaged" assertion so failures are diagnosed in seconds, not after the timeout. - new verifyCdn job (release events): the CDN manifests deployed clients actually poll must byte-match the release assets, and every artifact they list must be HEAD-able at the promised size - closing the gap between "green CI" and "users update" (retries ~30 min for sync lag). - concurrency group keyed by event+ref so a dispatch can no longer cancel a release run's verification mid-flight. Deferred deliberately (documented in the scripts): previous-release -> candidate baselines (needs the first E2E-capable release in the field), the Rosetta x64-on-arm64 migration row, root-container deb/rpm update E2Es, and gating release-asset attachment on the verify jobs.

• Dwynr(17 Jul 26)

  ci: fix first-run verify failures + make the manifest pipeline truthful First live run of the verify jobs surfaced three issues: - Windows x64: rcedit pads the PE version resource to four parts, so the installed ProductVersion is "3.0.51.0"; the assertion now accepts the ".0"-padded form. - Windows arm64 installed nothing again on the windows-11-arm runner despite the BCJ payload; the verify scripts now dump deep diagnostics on failure (install tree, Program Files (x86) probe, Defender realtime status and detection history) so the next run identifies whether extraction, arch detection, or AV quarantine is at fault. - macOS: check-feed caught a real pre-existing manifest defect - latest-mac.yml records the dmg size BEFORE notarize-dmg.js staples it (+3 KB). build/hashes.ts already re-synced each entry's sha512 after stapling but never the size; it now updates both, and its artifact list gains the missing arm64 deb / aarch64 rpm (and drops duplicates). The *.sha256.txt generation now runs AFTER build:hashes in all three build jobs, so the published checksum of each latest*.yml matches the final manifest instead of the pre-rewrite one. check-feed.py now reports every mismatch before failing instead of stopping at the first. workflow_dispatch gains per-platform boolean inputs (windows/linux/mac, default on) so a manual run can skip platforms - release events still always build everything, and skipping a build auto-skips its verify job via needs.

• Dwynr(17 Jul 26)

  ci: run the Intel mac verification on macos-26-intel + widen timeouts macos-26-intel exists (macOS 26 is the last Intel release), so verify the x64 artifacts against the current OS instead of macOS 15. Raise the verify job timeouts to 90 minutes and the in-script update-cycle deadlines (10 min on macOS/Linux, 15 min on Windows) so slower hosted runners don't flake the first runs.

• Dwynr(17 Jul 26)

  ci: verify install + auto-update on real runners for every platform/arch Add verifyWindows/verifyLinux/verifyMac jobs (x64 + arm64 each, using the windows-11-arm / ubuntu-24.04-arm / macos-15-intel hosted runners) that run after the builds on every release and manual dispatch. Build jobs now always upload workflow artifacts so the verify jobs have them on release runs too. Advisory for now: a red verify job on a release means pull the release before announcing. Install checks (build/ci/verify-install-*): - Windows: silently install BOTH the arch installer and the universal Filen_win.exe, then diff the installed tree against the raw zip payload file-by-file - the v3.0.50 arm64 installer "succeeded" while extracting nothing (7z ARM64 filter vs the old nsis7z.dll), and this assertion catches any such silent extraction skip. Plus PE arch, Authenticode, and version checks. - macOS: deep codesign, Gatekeeper assessment (signing + notarization), and the designated-requirement check Squirrel.Mac applies when deployed clients stage an update, for both dmg and zip. - Linux: real dpkg install, real dnf install in a Fedora container, AppImage payload inspection (resources/package-type must NOT leak in - it would misroute AppImage clients to the rpm updater), zip contents. - All: latest*.yml manifests re-hashed against the artifacts (build/ci/check-feed.py), latest-mac.yml must carry minimumSystemVersion. Auto-update checks (build/ci/verify-update-*): install the candidate, then serve it back to itself from a loopback feed claiming version 9.9.9 (updaters compare manifest versions; Squirrel validates signatures, not versions) and assert the full production pipeline runs end to end: check -> download -> sha512 -> NSIS reinstall / Squirrel staging + ShipIt swap / AppImage in-place swap -> relaunch, with post-update payload completeness on Windows. A regression like the v3.0.46-v3.0.50 macOS quitAndInstall exit-timer race hangs this check instead of shipping. deb/rpm update flows are consciously not E2E-tested (they need polkit interaction CI cannot provide); their download path is shared with the AppImage check and their install correctness is covered above. App side: FILEN_E2E_UPDATER=1 enables a test-only updater mode - feed override from FILEN_E2E_UPDATE_FEED (honored ONLY for plain http to 127.0.0.1/localhost, so production clients can never be redirected to a remote feed) and auto-confirmation of the install prompt. In E2E mode the updater initializes right after app-ready so the check does not depend on SDK/worker/login state on a fresh runner; initialize() is now idempotent so the regular post-window call stays harmless.

• Dwynr(17 Jul 26)

  fix(windows): use the BCJ filter upstream pins for NSIS payloads Amends 8dc7573: electron-builder issue #9983 and the merged fix (PR #9988, released in 26.15.6) state the vendored Nsis7z extractor decodes only plain LZMA2/Copy and single-stream BCJ - reporters hit silent extraction failures with 7za 24.09 BCJ2 streams too, on some payloads even on x64. Our shipped 3.0.50 x64 BCJ2 payload does extract in the field, so BCJ2 breakage is parameter-dependent, but there is no reason to sit on that edge: switch ELECTRON_BUILDER_7Z_FILTER from BCJ2 to BCJ, the exact filter 26.15.6 now pins for NSIS payloads by default. Re-verified like the original fix: packing the published arm64 Filen.exe with the bundled 7-Zip 24.09 toolset and -mf=BCJ yields "LZMA2:25 BCJ" (no ARM64/BCJ2 coders) and a pre-21.01 decoder extracts it byte-identically. Once electron-builder is bumped to >=26.15.6 the env var becomes redundant but harmless (BCJ stays allow-listed).

• Dwynr(17 Jul 26)

  chore: bump version

• Dwynr(17 Jul 26)

  fix(windows): force BCJ2 in the NSIS payload so arm64 installs extract electron-builder 26.15's bundled 7-Zip 24.09 toolset auto-applies the ARM64 branch filter (a 7-Zip 21.01 codec) when compressing ARM64 executables into the NSIS app payload. The nsis7z.dll plugin that extracts that payload at install time predates the codec, so every ARM64-filtered block silently fails to extract: the v3.0.50 arm64 installers (standalone and universal, which auto-update uses) finished "successfully" but wrote no Filen.exe. x64 looked fine because only the never-used rclone-windows-arm64.exe helper sat in an ARM64-filtered block there. v3.0.47 worked because its 7za (7zip-bin 5.2.0) never applied the filter. Set ELECTRON_BUILDER_7Z_FILTER=BCJ2 for Windows builds, which makes electron-builder pass -mf=BCJ2 and restores the pre-regression coder chain (LZMA2 LZMA BCJ2). Verified against the published artifacts: a pre-21.01 decoder fails on the shipped app-arm64.7z exactly at Filen.exe, and succeeds byte-identically once the payload is repacked with -mf=BCJ2 by the same 7-Zip 24.09 toolset. Also cures the x64 payload's silently missing arm64 rclone helper. The env var must stay on any Windows build path until electron-builder ships a modern nsis7z.dll (its filter allow-list deliberately excludes ARM64). The Filen_win_*.zip artifacts are plain deflate zips and were never affected.

• Dwynr(15 Jul 26)

  fix(macos): don't kill Squirrel.Mac staging with a fixed exit timer With autoInstallOnAppQuit=false, electron-updater's MacUpdater only hands the update to native Squirrel.Mac inside quitAndInstall(): the zip is fetched through the local proxy, extracted, and signature-verified there, and only after that does ShipIt install and relaunch. installUpdate() scheduled app.exit(0) 1.5 s after quitAndInstall(), killing staging mid-flight, so nothing ever installed and clients looped on "update available" forever. The race shipped in v3.0.46 but kept winning while the mac zip staged in about a second (238 MB); the v3.0.50 artifact (385 MB, Electron 43 + bundled rclone) pushed staging past 1.5 s on every machine and broke macOS auto-update entirely. Windows/Linux are unaffected: their quitAndInstall() hands off to the installer synchronously before returning. Drop the timer and let electron-updater quit + relaunch on its own once staging completes (autoRunAppAfterInstall). Exit only if the updater errors, with a 10-minute failsafe so a silently hung Squirrel can't leave a windowless zombie process behind. Verified end-to-end with a signed harness app on a local feed: the old flow dies at +1.5 s mid-staging, the fixed flow stages in ~1.8 s, installs via ShipIt, and relaunches. Note: the updater that performs a hop is the installed client, so macs on v3.0.46-v3.0.50 still need one manual .dmg install of a build containing this fix; clients on <= v3.0.44 (no timer) auto-update fine.

• Dwynr(15 Jul 26)

  chore: bump deps and version

• Dwynr(10 Jul 26)

  fix: restrict external and local open handlers to safe targets

• Dwynr(10 Jul 26)

  fix: keep multi-item downloads within the destination directory

• Dwynr(08 Jul 26)

  fix(rclone): authenticate the rc interface (drop --rc-no-auth) The in-repo rclone launcher started every role's remote-control server with --rc-no-auth on a fixed loopback port, exposing the full rc API unauthenticated. operations/copyurl writes attacker-controlled bytes to any local path, so a CORS-simple cross-origin POST from any web page the victim opens (no preflight, and it need not read the response) is an arbitrary local file write -> RCE: an autostart/LaunchAgent/Startup entry, or overwriting ~/.bashrc, ssh keys, etc. config/create'ing a local remote likewise yields full local filesystem read/write. Confirmed against the bundled rclone v1.74.3; the foreign Origin header is no barrier. Replace --rc-no-auth with an ephemeral, per-process HTTP Basic pair: RcloneProcess mints RCLONE_RC_USER/RCLONE_RC_PASS via generateRcCredentials() and injects them into the child env (kept out of argv and the process list); the existing RcClient presents the same pair. rclone then answers 401 to every other caller while the app's own rc calls keep working. The rc env vars fail closed (verified end-to-end), unlike serve-s3's RCLONE_AUTH_KEY (rclone#9044), so the s3 --auth-key stays on the CLI.

• Dwynr(03 Jul 26)

  fix(windows): hide the rclone watchdog console (drop detached helper) The crash-safety watchdog spawned cmd.exe /c monitor.v<N>.<role>.bat with detached: true + windowsHide: true. On Windows, DETACHED_PROCESS makes the OS ignore CREATE_NO_WINDOW (what windowsHide sets), so cmd.exe allocated its own VISIBLE console that stayed open for the whole session - the reported stray monitor.v3.drive.bat window. Drop detached on the Windows helper only: windowsHide then hides the console, and the helper still outlives the app for its crash cleanup because Windows does not reap child processes when the parent exits (unref() keeps it off our event loop). POSIX keeps detached - it needs its own process group for the group-kill. rclone itself was already hidden (not detached + windowsHide).

• Dwynr(02 Jul 26)

  fix: reliable app quit + no duplicate instance (all platforms) macOS Dock "Quit"/Cmd+Q left the process alive but window-less for up to 60s, and a relaunch during that limbo spawned a second instance (two windows, two tray icons). Root cause: the will-quit handler preventDefault()'d the quit and ran an async teardown with an untimed worker.stop() and a 60s ceiling, while nothing stopped activate/second-instance from resurrecting the app mid teardown. - will-quit: drop the worker.stop() wait (the worker is an in-process worker_threads thread that dies with the process anyway), keep the already-bounded rclone.killAll() (flush + clean-unmount), cap at 15s, always app.exit. - Guard reactivation while quitting: activate / second-instance / showOrOpenDriveWindow no-op once shouldExitOnQuit is set. - Route every explicit-quit entry point through the graceful path: window-all-closed, tray "Exit" and restart now use app.quit() instead of a hard app.exit that skipped teardown (stale mount / relaunch collision on Windows/Linux). - watchdog: SIGTERM-before-SIGKILL on POSIX so crashes also flush rclone's write-back cache (monitor script version bumped to 3).

• Dwynr(02 Jul 26)

  fix(ci): build macOS on macos-26 with setup-xcode for the .icon Xcode 26's actool (the Icon Composer .icon compiler) crashes on the macos-15 runner: it links macOS-26-era CoreMedia/MediaToolbox/AVFCore symbols that are absent on macOS 15 (dyld sets them to 0xBAD4007), cascading into an AssetCatalogAgent crash. Run the mac job on macos-26 (Tahoe), whose native frameworks match Xcode 26, and pick Xcode with maxim-lobanov/setup-xcode (latest-stable -> the 26.x that matches the local build). Replaces the macos-15 + ad-hoc xcode-select workaround.

• Dwynr(02 Jul 26)

  fix(ci): select Xcode 26 on mac runner for Icon Composer .icon electron-builder compiles mac.icon (build/icons/mac/icon.icon) with actool, which must be >= 26 for the .icon format. The macos runner ships Xcode 26 but defaults to 16.4, so the build failed: "Unsupported actool version ... found 16.4". Pin the runner to macos-15 (which includes Xcode 26) and xcode-select the newest installed Xcode 26 before the build step.

• Dwynr(02 Jul 26)

  fix(ci): pass explicit tag_name to action-gh-release softprops/action-gh-release derives the release tag solely from the run's GITHUB_REF; with no tag_name input it throws "GitHub Releases requires a tag" whenever that ref isn't refs/tags/*. Pin the tag from the release payload (github.event.release.tag_name) on all three build jobs so attaching artifacts never depends on ref inference.

• Dwynr(02 Jul 26)

  fix: refine mac icon glass and lighting settings Update `build/icons/mac/icon.icon/icon.json` to add appearance-specific blur, fill, glass, and translucency specializations, enable combined lighting/specular effects, and slightly reduce the logo scale. This aligns icon rendering behavior across light/dark/tinted appearances.

• Dwynr(02 Jul 26)

  chore(icons): adopt macOS 26 Icon Composer .icon + drop unused icon assets macOS icon: - mac.icon now points at build/icons/mac/icon.icon (Icon Composer). electron-builder derives BOTH the modern Assets.car (CFBundleIconName; macOS 26 light/dark/tinted/clear appearances) and the legacy icon.icns (CFBundleIconFile; older macOS) from it, so old macs keep working - no separate legacy file to maintain. - Removed the runtime app.dock.setIcon() on macOS (status.ts) and the stale assets/icons/app/darwin.icns: a runtime setIcon overrode the bundle icon with a flat image and lost the appearance variants. The dock/Finder icon now comes from the bundle. - afterPack fails the mac build if Assets.car or icon.icns didn't compile (e.g. Xcode 26 missing) instead of silently shipping the default Electron icon. Dropped 31 unused icon files - referenced nowhere in src/ (verified against src/assets/index.ts, the only loader; dynamic paths are ${platform}.ext, overlay/0.png, and the hardcoded tray/*@2x.png names): - app/*Notification.{icns,png,ico} - getAppIcon never loads the notification variants - app/overlay/{1..9,99}.png - getOverlayIcon always returns overlay/0.png - tray/{dark,light}/** - a theme-adaptive tray that was never wired up Windows/Linux runtime icons, the tray @2x set, overlay/0.png, and the build win/png icon sets are unchanged.