Slow initial boot time — possible macOS quarantine of bundled argmax binary

[modem-app]

Problem

Users are reporting very slow initial boot time.

Source: User feedback on Slack — includes screenshot and screen recording showing the delay.

Investigation Notes

• The bundled argmax binary may be triggering macOS Gatekeeper/quarantine checks on first launch, adding significant delay to boot time.
• Not yet confirmed as the root cause — needs further investigation.

Possible Next Steps

• Profile app startup to identify where time is spent
• Check if the argmax binary has the quarantine xattr (com.apple.quarantine) after download
• Test with xattr -d com.apple.quarantine on the binary to see if boot time improves
• Consider code-signing the binary or stripping the quarantine flag during installation
• Look into notarization if not already done

[devin-ai-integration]

Investigation: App Startup Performance & Argmax Binary Quarantine

Summary

After tracing the full startup path, build pipeline, and binary bundling process, the argmax quarantine hypothesis does not explain slow startup — the argmax sidecar is never launched on app boot. However, there are real quarantine/code-signing concerns that would affect first-use latency when a user starts transcription, and several other startup bottlenecks worth investigating.

---

1. Startup Sequence Analysis

The app entry point (apps/desktop/src-tauri/src/lib.rs) does the following on launch:

1. spawn_root_supervisor() — Creates a ractor-based DynamicSupervisor actor (lightweight, async — not a bottleneck)
2. Sentry initialization — Configures error reporting with DSN, fingerprint, user scope
3. Audio provider creation — Instantiates ActualAudio (or MockAudio in dev)
4. ~40 plugin registrations — Each plugin's init() → setup() runs synchronously during tauri::Builder::build()
5. setup() closure — Tray menu creation, AGENTS.md write, db2().init_local() (async), supervisor monitoring
6. Legacy bundle rename check (updater2 plugin) — On macOS, checks if the app was previously named "Hyprnote" and schedules a rename + relaunch. If triggered, this calls std::process::exit(0) and relaunches, which would appear as a very slow "first launch"
7. Window show — AppWindow::Main.show()
8. Update check loop — check_and_download() runs every 30 minutes in a background task

Key finding: No sidecar binaries are spawned during startup. The argmax binary (char-sidecar-stt) is only launched on-demand when a user explicitly starts the external STT server via start_external_server() in plugins/local-stt/src/ext.rs.

2. Argmax Binary Bundling

How it's included (.github/workflows/desktop_cd.yaml:109-120):

# Download pre-built binary from Cloudflare R2
aws s3 cp s3://argmax/stt apps/desktop/src-tauri/binaries/char-sidecar-stt-${{ matrix.target }}
chmod +x ./apps/desktop/src-tauri/binaries/char-sidecar-stt-${{ matrix.target }}
# Add to tauri.conf.json externalBin array
./scripts/sidecar.sh "./apps/desktop/${{ env.TAURI_CONF_PATH }}" "binaries/char-sidecar-stt"

What scripts/sidecar.sh does: Simply appends the binary path to bundle.externalBin in the Tauri config via jq. No signing, no quarantine stripping.

Code-signing status:

• The argmax binary is downloaded as a pre-built blob from S3 — it is NOT compiled during CI
• Tauri's bundler should code-sign all externalBin entries with the app's signing identity during tauri build (it signs everything in Contents/MacOS/)
• However, there's a known Tauri issue (#11992) where sidecar notarization can fail — worth verifying the binary actually passes codesign -v in the built DMG
• No quarantine attribute stripping exists anywhere in the codebase — no xattr -d com.apple.quarantine calls

Other bundled binaries follow the same pattern:

• check-permissions — compiled from Swift at build time via build.rs, added to externalBin
• char-chrome-native-host — compiled from Rust via cargo xtask prepare-binaries, added to externalBin
• None have quarantine handling

3. Quarantine Impact Assessment

On startup: None. The argmax binary is not executed during app initialization.

On first transcription use: Potentially significant. When a user first starts the external STT server:

1. plugins/local-stt/src/server/external.rs:128 spawns the sidecar via cmd.spawn()
2. If the binary retains com.apple.quarantine xattr (set by browsers/Homebrew on download), macOS Gatekeeper performs a full scan
3. For a large ML binary like argmax, this scan can take 5-30+ seconds on first execution
4. The quarantine attribute is typically set on files downloaded from the internet. Since the app is downloaded (via DMG), macOS may propagate quarantine to all files within the bundle

Important nuance: Tauri's bundler signs the app and its contents, and Apple notarization should clear Gatekeeper for the main app. But the quarantine xattr on the sidecar binary inside the bundle depends on:

• Whether macOS propagates quarantine into the .app bundle contents
• Whether Tauri's signing properly covers the sidecar
• Whether notarization ticket stapling covers embedded binaries

4. Other Potential Causes of Slow First Boot

a) Legacy Bundle Rename (updater2 startup_migration)

High suspicion. For users upgrading from "Hyprnote" to "Char", the maybe_schedule_legacy_bundle_rename_on_launch() function:

• Spawns a shell script that waits for the current process to exit
• Moves the .app bundle (potentially requiring admin privileges via osascript)
• Relaunches the app from the new location
• Calls std::process::exit(0) immediately

This would make the first launch after a rename appear to take a very long time (app starts → exits → shell waits → moves → relaunches).

b) ~40 Synchronous Plugin Initializations

Each plugin's setup() runs during tauri::Builder::build(). Notable ones:

• tauri_plugin_settings — resolves vault base path, reads filesystem
• tauri_plugin_db2 — init_local() is async but still spawned during setup
• tauri_plugin_store / tauri_plugin_store2 — reads persistent state from disk
• tauri_plugin_tantivy — search index initialization
• tauri_plugin_listener / tauri_plugin_listener2 — audio subsystem setup
• tauri_plugin_window_state — restores window position/size

c) Database Initialization

db2().init_local() runs async during setup — on first launch this creates the SQLite/LibSQL database and runs migrations.

d) Sentry Initialization

Sentry client setup with minidump handler runs synchronously before plugin registration.

5. Recommendations

1. Add instrumentation to startup path — Add tracing::info! with timestamps or use std::time::Instant around each major phase (supervisor spawn, plugin init, setup closure, window show) to identify the actual bottleneck on real user machines.

2. Strip quarantine on sidecar binaries — Even though argmax isn't launched at startup, add quarantine stripping for when it is first used:

   // In sidecar2 plugin or external server pre_start
   #[cfg(target_os = "macos")]
   {
       let _ = std::process::Command::new("xattr")
           .args(["-d", "com.apple.quarantine", &sidecar_path])
           .output();
   }

3. Verify sidecar code-signing in built DMG — Download a release DMG and run:

   codesign -dv --verbose=4 "Char.app/Contents/MacOS/char-sidecar-stt"
   spctl --assess --type execute "Char.app/Contents/MacOS/char-sidecar-stt"
   xattr -l "Char.app/Contents/MacOS/char-sidecar-stt"

4. Profile the legacy bundle rename path — Check if the updater2 startup migration is triggering for users reporting slow boot. This causes an exit+relaunch cycle that would feel like a very long startup.

5. Consider lazy plugin initialization — Move heavy plugin setups (tantivy, listener, db2) to be lazily initialized on first use rather than at app startup.

6. Add quarantine stripping to all bundled binaries — Apply the same xattr -d treatment to check-permissions and char-chrome-native-host as a preventive measure.

---

TL;DR

• Argmax is NOT launched on startup — it's on-demand only, so it can't cause slow boot
• Legacy bundle rename (Hyprnote → Char migration) is a likely culprit for first-launch slowness — it exits and relaunches the app
• ~40 synchronous plugin inits could accumulate significant startup time
• Quarantine concerns are real but affect first transcription use, not app boot
• No quarantine stripping exists anywhere in the codebase — should be added
• Sidecar code-signing should be verified in the actual built DMG