Sparkle auto-update fails on macOS (non-sandboxed): SUSparkleErrorDomain(4005) / Timeout: agent connection was never initiated

[nhodges]

cmux version

0.64.9

macOS version

macOS 26.4.1

Mac chip

Apple Silicon (M1/M2/M3/M4)

Installation method

Direct download (DMG)

Can you reproduce this on cmux NIGHTLY?

I could not test NIGHTLY

Bug description

Summary

Auto-update in cmux v0.64.9 fails on macOS with Sparkle error 4005 (underlying error 10, "agent connection was never initiated"). The update downloads and
verifies (EdDSA signature OK), but the install handoff to Sparkle's Installer XPC times out, so no version ever gets installed. Manually replacing
/Applications/cmux.app with the latest .dmg works, so the published artifact is fine — the issue is in how Sparkle is bundled.

Environment

• cmux: v0.64.9 (also reproduces with the published v0.64.11 download flow — same bundle layout)
• macOS: 15.x (Darwin 25.4.0)
• Sparkle: 2.8.1, embedded in cmux.app/Contents/Frameworks/Sparkle.framework/
• App signing: notarized Developer ID, team 7WLXT3NR37, matches across cmux, Autoupdate, Updater.app, and Installer.xpc — not a Team ID mismatch.

Symptom in the UI

Message: An error occurred while running the updater. Please try again later.
Domain: SUSparkleErrorDomain
Code: 4005
Failure: The remote port connection was invalidated from the updater...
Debug: SUSparkleErrorDomain(4005) | ... | underlying=SUSparkleErrorDomain(10) Timeout: agent connection was never initiated

The error text suggests sandboxing entitlements, but the app isn't sandboxed — see Root Cause below.

Root cause

cmux.app ships the Sparkle helper XPC services intended for sandboxed apps:

cmux.app/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices/
├── Downloader.xpc
└── Installer.xpc (CFBundleIdentifier = org.sparkle-project.InstallerLauncher)

But cmux.app is not sandboxed (codesign -d --entitlements - on the main exec returns no com.apple.security.app-sandbox key), and:

• Installer.xpc has no entitlements at all (codesign -d --entitlements - on it returns the executable path with no entitlements blob).
• The main app has no com.apple.security.temporary-exception.mach-register.com.cmuxterm.app-spki / -spkp / -spks exceptions.

When Autoupdate runs, it sets up Mach service listeners on com.cmuxterm.app-spki (Installer Connection) and com.cmuxterm.app-spkp (Installer Launcher) and then
waits for Installer.xpc to call back. Installer.xpc launches but cannot reach those Mach services — Sparkle's Updater.app logs the symptom directly:

Updater: activating connection: mach=true ... name=com.cmuxterm.app-spkp
Updater: failed to do a bootstrap look-up: xpc_error=[3: No such process]
Updater: [Sparkle] Agent failed..
Updater: [Sparkle] Error: Agent Invalidating without having the chance to reply to installer
Autoupdate: [Sparkle] Error: Timeout: agent connection was never initiated

Per Sparkle's sandboxing docs, the XPC services should either be removed for non-sandboxed apps (Sparkle uses an in-process installer instead) or kept with the
matching Mach-register temporary-exception entitlements + XPCService.JoinExistingSession / application-groups wired up correctly. cmux ships them with neither,
which is the configuration that produces this specific timeout.

Fix (recommended)

In the macOS build pipeline, delete Sparkle.framework/Versions/B/XPCServices/ (both Installer.xpc and Downloader.xpc) before code-signing the framework and the
app. Sparkle falls back to the in-process installer path for non-sandboxed apps, which is the supported configuration. Make sure to re-sign the framework after
removal so the seal stays valid:

inside the build, after Sparkle is copied into the app bundle, before signing

rm -rf "/Contents/Frameworks/Sparkle.framework/Versions/B/XPCServices"
codesign --force --options runtime --timestamp
--sign "Developer ID Application: Manaflow, Inc. (7WLXT3NR37)"
"/Contents/Frameworks/Sparkle.framework/Versions/B"

then sign the rest of the app as usual

Alternative: keep the XPC services and add the documented Mach-register entitlements + plist wiring. Simpler to just drop them since cmux isn't sandboxed.

How to reproduce

1. Install cmux v0.64.9.
2. Use the in-app "Check for Updates" against the published appcast at https://github.com/manaflow-ai/cmux/releases/latest/download/appcast.xml.
3. Update downloads and verifies, then fails with the 4005 error above.
4. Tail ~/Library/Logs/cmux-update.log and log show --predicate 'process == "Autoupdate" OR process == "Updater"' to see the bootstrap-lookup failure.

Workaround for affected users

Download the latest cmux-macos.dmg from Releases and drop the new cmux.app over /Applications/cmux.app. Future updates will keep failing until the build change
above ships

Expected behavior

I should be able to update through the cmux app

Steps to reproduce

How to reproduce

1. Install cmux v0.64.9.
2. Use the in-app "Check for Updates" against the published appcast at https://github.com/manaflow-ai/cmux/releases/latest/download/appcast.xml.
3. Update downloads and verifies, then fails with the 4005 error above.
4. Tail ~/Library/Logs/cmux-update.log and log show --predicate 'process == "Autoupdate" OR process == "Updater"' to see the bootstrap-lookup failure.

Shell and environment

No response

Relevant logs or crash reports

Screenshots or screen recordings

No response

Additional context

No response

[LesterWeng]

Message: 运行更新程序时出现错误，请稍后再试。
Domain: SUSparkleErrorDomain
Code: 4005
Failure: The remote port connection was invalidated from the updater. If your application is sandboxed, please ensure Installer Connection & Status entitlements are correctly set up: https://sparkle-project.org/documentation/sandboxing/ . Otherwise if Autoupdate is not adhoc signed, your app must be signed with a matching team ID. For additional details, check Console logs for Autoupdate
Feed: https://github.com/manaflow-ai/cmux/releases/latest/download/appcast.xml
Debug: SUSparkleErrorDomain(4005) | 运行更新程序时出现错误，请稍后再试。 | underlying=SUSparkleErrorDomain(10) Timeout: agent connection was never initiated | feed=https://github.com/manaflow-ai/cmux/releases/latest/download/appcast.xml
Log: /Users/lester/Library/Logs/cmux-update.log

[LukeSal88]

+1, reproducing 0.64.13 → 0.64.14 (macOS 26.4.1, arm64, non-sandboxed). Deterministic across every 0.64.x update for ~1 month.

A unified-log capture (/usr/bin/log show --predicate 'eventMessage CONTAINS[c] "cmuxterm"') shows the installer XPC agent connects fine — it's the progress agent (-spks / com.cmuxterm.app-sparkle-progress) that never connects back, so the host times out after ~19s:

16:17:42.008 launchd      Successfully spawned Autoupdate[32620] for com.cmuxterm.app-sparkle-updater
16:17:42.208 Autoupdate   peer connection com.cmuxterm.app-spki.peer[7029]   <- installer connected OK
   (~19s gap, no progress-agent connection)
16:18:01.394 cmux         updater error 4005 / underlying (10) agent connection was never initiated
16:18:01.648 launchd      failed lookup: name = com.cmuxterm.app-spkp, requestor = Updater[32970], error = 3: No such process

So "agent connection was never initiated" really means the progress agent, not the installer. This points at #1960 (codesign --deep stamping wrong entitlements on the Sparkle XPC services) — wrong XPC entitlements would drop the progress agent's connection while signatures still validate.

Workaround: quit cmux, download the release DMG, replace /Applications/cmux.app manually — deterministic. The in-app updater and a quit/relaunch retry don't help.

[mengxihex]

Confirming this still reproduces on 0.64.13 → 0.64.14 (current latest) — Apple Silicon, macOS 15 (Darwin 25.5.0). Not fixed in the newest build.

Same SUSparkleErrorDomain(4005) | underlying=(10) Timeout: agent connection was never initiated, right after extracting(100%), on every update check (06-04, 06-05, 06-08 in my logs). Manual cmux-macos.dmg swap works fine (0.64.14 is notarized, Team 7WLXT3NR37, Gatekeeper-accepted) — consistent with the XPCServices root cause above; only the bundled Sparkle helper config is at fault.

[edvina]

Getting the same behavior on 0.64.13 -> 0.64.14. Apple Silicon, Tahoe 26.5.

[JiveDig]

Same issue here. Installing from the latest dmg file from Releases worked though. @LukeSal88 thanks for that tip.