Point cmux NIGHTLY's SUFeedURL to files.cmux.com/nightly/appcast.xml
(Cloudflare R2) instead of the GitHub Release asset. R2 uses atomic
PutObject for replacement, eliminating the transient SUDownloadError
2001 that occurs when GitHub Release assets are being overwritten
during a nightly publish.
The isNightly detection (checks for "/nightly/" in the URL) still
works with the new R2 URL. DMGs continue to be served from GitHub
Releases. Only the appcast feed URL changes.
Stable builds are unchanged (still use GitHub Releases).
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
* Simplify R2 upload to appcast-only (keep DMGs on GitHub)
DMGs are immutable per-build on GitHub Releases (unique filenames,
no overwrite), so there's no race condition for them. Only the
appcast.xml needs atomic replacement, which R2 PutObject provides.
Upload the original appcast.xml as-is (GitHub Release DMG URLs)
to R2. No sed URL rewriting, no DMG uploads, less storage/bandwidth.
* Move R2 appcast upload after GitHub Release publish
The R2 appcast references GitHub Release DMG URLs, so it must be
uploaded after the DMGs exist on GitHub. Previously the R2 upload
ran before the publish step, creating a brief window where the
appcast pointed to a not-yet-existing DMG.
* Add semver guard to stable R2 appcast upload
Prevents a backport tag (e.g. v0.62.1 pushed after v0.63.1) from
overwriting the stable appcast with an older version. Uses sort -V
to compare all non-prerelease tags and only uploads if the current
tag is the highest.
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
* Add R2 dual-write for nightly appcast and DMGs
Upload nightly DMGs and appcast to Cloudflare R2 (files.cmux.com)
alongside the existing GitHub Release assets. R2 uses atomic PutObject
so the appcast never 404s during replacement, fixing the transient
SUDownloadError 2001 that occurs when GitHub Release assets are
being overwritten.
DMGs are uploaded before the appcast so the feed never references a
file that doesn't exist yet. The GitHub Release upload is unchanged,
so existing nightly users are unaffected.
A follow-up PR will switch the Sparkle feed URL in the app bundle
from GitHub Releases to R2 after manual verification.
* Add continue-on-error to R2 steps
R2 upload failures should not block the existing GitHub Release
publish. This keeps the nightly pipeline safe while R2 is new.
* Add R2 dual-write for stable release appcast and DMG
Same pattern as nightly: upload DMG then appcast to R2
(files.cmux.com/stable/) alongside the GitHub Release.
Both steps use continue-on-error so R2 failures can't
block the release.
* Address review feedback: cache headers, no double build, AWS CLI guard
- Add Cache-Control headers: immutable versioned DMGs get max-age=1yr,
mutable appcast.xml and latest DMG get no-cache to prevent stale CDN
- Replace separate appcast generation step with sed URL replacement,
avoiding a second Sparkle clone+build (signature is over DMG content,
not the URL)
- Add AWS CLI availability check with fallback brew install
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Match the nightly workflow's universal build approach so stable releases
support both Apple Silicon and Intel Macs. Adds -destination, ARCHS,
ONLY_ACTIVE_ARCH=NO flags and a post-build architecture verification step.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* Switch release builds to macOS Tahoe runner
Use warp-macos-26-arm64-6x for release builds to match nightly. Also add
a dry-run artifact upload path for workflow_dispatch so the release
pipeline can be tested without creating a real release.
* Gate release upload on event_name, not just ref prefix
Prevents workflow_dispatch triggered on a tag ref from accidentally
uploading real release assets.
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Use warp-macos-26-arm64-6x for nightly builds to get the latest Xcode
toolchain. Deployment target stays at 14.0 (Sonoma), so built binaries
remain compatible with Sonoma, Sequoia, and Tahoe.
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
* Fix nightly SSH remote daemon checksum mismatch
Each nightly build overwrites the shared cmuxd-remote-* assets on the
nightly release, but older nightly DMGs have manifests with checksums
from their build time. When a user's nightly is even one build behind,
the downloaded binary doesn't match their embedded manifest.
Two-layer fix:
1. CI: version nightly remote daemon asset names with the build number
(e.g. cmuxd-remote-darwin-arm64-2362248028801) so each nightly's
manifest points to immutable files. Unsuffixed "latest" copies are
still uploaded for tooling compatibility.
2. Client: on checksum mismatch, fetch the live manifest from the
release and verify against that. This handles users on older
nightlies that predate the CI fix.
Fixes https://github.com/manaflow-ai/cmux/issues/1745
* Fix unsuffixed checksums file to use generic filenames
Regenerate cmuxd-remote-checksums.txt from the unsuffixed alias
binaries so `shasum -c` works against the generic asset names.
Also document that unsuffixed manifest intentionally keeps versioned
downloadURLs and that aliases don't carry attestation.
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
* Remove fork PR guards from CI workflows
Fork PRs are already gated by GitHub's "Require approval for outside
collaborators" setting. The workflow-level guards were redundant and
prevented WarpBuild jobs from running even after maintainer approval.
* Address review feedback: extend guard test, skip upload on fork PRs
- Guard test now covers build-ghosttykit.yml and ci-macos-compat.yml
(not just ci.yml)
- Skip xcframework upload when GHOSTTY_RELEASE_TOKEN is unavailable
(fork PRs), so the build still validates without failing at publish
* Check GHOSTTY_RELEASE_TOKEN at runtime instead of step if
secrets context can't be reliably used in step if: conditions.
Check the env var inside the script instead.
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
On WarpBuild runners without a GUI session, XCUIApplication.launch()
blocks ~60s then fails with "Failed to activate application (current
state: Running Background)". Wrap launch() in XCTExpectFailure so the
test can continue — keyboard and element APIs work via accessibility
even when the app is in .runningBackground.
Increase test execution time allowance from 120s to 180s to account
for the 60s activation timeout on headless runners.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The browser find focus test was failing because XCUIApplication.launch()
cannot foreground-activate the app on headless CI runners (WarpBuild)
without a display. The display resolution test already had its own virtual
display, but it was scoped to that step only.
Create a persistent virtual display at the start of the ui-regressions job
that stays alive for all test steps. Also switch the browser test from
`test` to `test-without-building` since the build step already ran.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The sandboxed XCTest runner can't write the start signal file to /tmp/.
Added --start-delay-ms to create-virtual-display.m as alternative to
--start-path. CI uses 10s delay so the test captures baseline render
stats before churn begins. Test skips start signal write when
pre-launched.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The XCTest runner is sandboxed, causing Process-spawned apps to
inherit sandbox restrictions. The CI step now:
1. Builds for testing first (separate step)
2. Launches display helper and app from the shell (non-sandboxed)
3. Waits for app diagnostics and render stats
4. Writes manifests for the test to find the pre-launched state
5. Runs test-without-building
The test detects the pre-launch manifest and skips its own app launch.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
XCUIApplication.launch() hard-fails with a 60-second timeout when
it can't foreground the app on headless CI runners. This test never
uses XCUIApplication for interaction (no taps/keys) — it only reads
a diagnostics file.
Replace with NSWorkspace.openApplication which launches through
Launch Services, passes env vars via OpenConfiguration, and returns
immediately without blocking on activation failure.
Also add CI retry loop since runner environment is flaky.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reverts cbb21872, 54ec524a, 10fd323b, 75375ab7, 82a16aa7 — all
attempts to fix display resolution UI test foreground activation
on CI that introduced regressions. Restores the state from the
last fully green CI run (56a4d258).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
XCUIApplication.launch() fails to activate the app on headless CI
runners, reporting "Failed to activate application (current state:
Running Background)". With continueAfterFailure=false, this kills the
test before ensureForegroundAfterLaunch can retry.
Fix by temporarily setting continueAfterFailure=true around launch(),
then retrying activation via app.activate(). Also add a retry loop in
the CI workflow since foreground activation is inherently flaky on
headless runners.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Rapid pushes to main spawn 7+ WarpBuild jobs simultaneously, causing
intermittent runner failures (shutdown during submodule clone, lost
communication). Add workflow-level concurrency groups to ci.yml and
build-ghosttykit.yml.
On PRs, stale runs are canceled when a new push arrives. On main, runs
queue serially (cancel-in-progress is false to avoid GitHub treating
cancelled runs as failures).
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Change cancel-in-progress from true to false so concurrent nightly
runs queue instead of being killed.
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
PR #1783 added -skip-testing for
testCmdWClosesWindowWhenClosingLastSurfaceInLastWorkspace in ci.yml
but missed ci-macos-compat.yml. The test hangs on headless runners
because Ghostty PTY teardown blocks without a TTY.
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
* Fix CI test timeout: stream xcodebuild output and bump timeout to 30m
The test split PR (#1717) applied output streaming (tee) and timeout bump
only to ci-macos-compat.yml, not ci.yml. The main CI tests job was still
capturing all xcodebuild output in a $() subshell (making logs blank) and
using a 20 minute timeout (too tight after the test file split).
Port the same fixes from ci-macos-compat.yml:
- Stream xcodebuild output via tee so CI logs show progress in real time
- Bump timeout-minutes from 20 to 30
- Update the SPM retry guard test for the new tee pattern
* Fix hanging test: auto-confirm window close in last-surface Cmd+W test
testCmdWClosesWindowWhenClosingLastSurfaceInLastWorkspace hung for 26+
minutes on CI because it sent Cmd+W to close the last surface without
setting debugCloseMainWindowConfirmationHandler. The window close path
shows a modal confirmation dialog that blocks the RunLoop indefinitely
on headless runners.
Set the handler to auto-confirm, matching the pattern used by
testCmdCtrlWClosesWindowAfterConfirmation.
* Skip last-surface close test on CI: PTY teardown blocks on headless runners
The confirmation handler fix wasn't sufficient. The hang is in Ghostty
surface/PTY teardown when closing the last terminal surface, not the
window close confirmation. Shell process termination blocks indefinitely
on headless CI runners without a TTY.
Skip with XCTSkip when CI env var is set. The test still runs locally
and can be covered via E2E on runners with virtual displays.
* Skip hanging test via -skip-testing flag in xcodebuild
The CI env var isn't visible inside xcodebuild's test host process, so
the XCTSkip approach didn't work. Use -skip-testing on the xcodebuild
command line instead.
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
- Swift app: feedback API endpoint, docs URLs, changelog URL, CLI help
- PostHog proxy: r.cmux.dev -> r.cmux.com
- All 20 README files: docs and blog links
- Homebrew cask: homepage URL in update-homebrew workflow
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
CmuxWebViewKeyEquivalentTests.swift grew to 15,907 lines with 100+ test classes.
Swift compiles per-file, so this single file serialized all type-checking onto one
compiler process, pushing CI past the 20-minute timeout after core-file changes.
Split into 10 domain-based files (1k-3k lines each) so Xcode can compile them in
parallel. Also bump timeout-minutes from 20 to 30 for headroom, stream xcodebuild
output via tee instead of capturing to a variable (makes CI logs debuggable), and
add 5 test files that were missing from the pbxproj Sources build phase.
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Zig 0.15.2's MachO linker can't resolve libSystem on macOS 26 (the
version number jump from 15 to 26 breaks zig's SDK handling). The unit
tests don't need the CLI helper binary at runtime, so we skip the zig
build on macOS 26 by setting CMUX_SKIP_ZIG_BUILD=1, which creates a
stub binary to satisfy the Xcode Run Script file check.
Smoke test (full app build + launch) is skipped on macOS 26 since it
needs the real CLI helper.
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Migrate CI/CD to WarpBuild, consolidate test jobs
Replace all macOS runner labels across workflows:
- depot-macos-latest → warp-macos-15-arm64-6x
- macos-15 → warp-macos-15-arm64-6x
- macos-14 → warp-macos-14-arm64-6x
Consolidates tests + tests-depot into a single tests job that runs
unit tests, regressions, UI tests, and lag tests sequentially on one
WarpBuild runner. Ubuntu jobs remain on ubuntu-latest.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Upgrade stale zig on runners that have an outdated version pre-installed
WarpBuild macos-14 ships zig 0.15.1 but the project requires 0.15.2.
The install step skipped because zig was found, just outdated.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Pin zig 0.15.2 via direct tarball instead of Homebrew
Homebrew's zig bottle for macOS 14 (Sonoma) is stuck at 0.15.1 but the
ghostty submodule requires 0.15.2. Download zig directly from
ziglang.org to guarantee the correct version on all runner images.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix zig tarball URL: arch-os order is aarch64-macos, not macos-aarch64
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Create /usr/local/bin and /usr/local/lib before copying zig
WarpBuild runners don't have /usr/local/lib by default.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add 20-min timeout to WarpBuild jobs
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix UI test hang: stream output instead of variable capture, use GitHub runner for macOS 14
The OUTPUT=$(...) pattern buffers all xcodebuild output into a bash
variable. For the full cmux scheme (build + UI tests), this can be
hundreds of MB, causing the shell to hang. Replace with tee streaming.
macOS 14 on WarpBuild consistently hangs (unit tests timeout at 20min
vs 4min on macOS 15, same M4 Pro hardware). Use GitHub-hosted macos-14
runner for compat tests instead, which works on main today.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Split UI tests to GitHub-hosted runner (WarpBuild can't activate GUI apps)
WarpBuild macOS VMs leave XCUIApplication stuck in "Running Background"
state, causing every UI test to burn ~62s waiting for activation and
timing out the job. Root cause: WarpBuild ephemeral VMs don't provide
a full GUI session for app activation.
Split CI into parallel jobs:
- tests: WarpBuild (unit tests + regressions, ~6 min)
- tests-ui: GitHub-hosted macos-15 (UI tests + lag regression)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Move tests-ui to WarpBuild with TCC permission grants
Grant accessibility, post-event, and screen capture TCC permissions
to Xcode and XCTest processes on WarpBuild ephemeral VMs. This should
fix "Failed to activate application (Running Background)" errors that
prevent XCUITests from bringing the app to foreground.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add GUI session diagnostics and DevToolsSecurity for WarpBuild UI tests
Add session diagnostics (who, console user, GUI domain, WindowServer,
loginwindow) to understand WarpBuild VM session state. Also enable
DevToolsSecurity and security authorizationdb for XCTest process
control. Try bootstrapping GUI session if missing.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Fix TCC permissions: use Xcode-Helper + user DB (CircleCI approach)
Previous TCC grants used wrong client IDs (com.apple.dt.Xcode) and
only wrote to the system database. CircleCI's proven approach grants:
- kTCCServiceAccessibility to com.apple.dt.Xcode-Helper (not Xcode)
- kTCCServiceDeveloperTool to com.apple.Terminal
- Both system AND user-level TCC databases
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Reduce UI test timeout to 15s for WarpBuild expected failures
WarpBuild Virtualization.framework VMs cannot activate macOS GUI apps
(XCUIApplication stuck "Running Background"). Tests still execute and
report expected failures. But the 62s per-test activation timeout
makes 30+ tests take 30+ minutes total.
Set per-test timeout to 15s so expected failures resolve quickly.
Full interactive UI test coverage runs via test-e2e.yml on
GitHub-hosted runners with proper display support.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Replace XCUITest run with build + lag regression on WarpBuild
WarpBuild Virtualization.framework VMs cannot activate macOS GUI apps
(XCUIApplication stuck "Running Background" with 62s activation
timeout per test). Tried TCC permissions, DevToolsSecurity, virtual
display, reduced timeouts, nothing fixes the framework-level issue.
Replace tests-ui job with tests-build-and-lag:
- Build the full cmux scheme (verifies compilation)
- Run workspace churn typing-lag regression (socket-based, no GUI)
- XCUITests run via test-e2e.yml on GitHub-hosted runners
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Move macOS 14 compat to WarpBuild (no GitHub-hosted runners)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add diagnostic workflow to probe WarpBuild GUI activation
Tests multiple app activation approaches on WarpBuild VMs:
- open -a, NSWorkspace, NSRunningApplication.activate, osascript
- Virtual display state before/after CGVirtualDisplay
- TCC/accessibility permissions, Quartz session info
- VM type detection
This is a workflow_dispatch-only diagnostic to determine if
XCUITest can work on WarpBuild with the right configuration.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Trigger GUI probe on branch push (workflow_dispatch needs main)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Rewrite GUI probe with Swift (Python lacks AppKit on WarpBuild)
v1 failed because WarpBuild's Python isn't a framework build and
can't import AppKit/Quartz. v2 uses a compiled Swift binary to test
NSRunningApplication.activate(), osascript, Quartz session state,
display info, and AX trust.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* GUI probe v3: try 5 approaches to unlock WarpBuild screen
1. defaults write (screensaver, loginwindow, pmset)
2. automationmodetool enable-automationmode-without-authentication
3. CGSSessionSetScreenLocked private API + System Events keystroke
4. sysadminctl -screenLock off + keychain unlock
5. CGEvent simulation (mouse move + Return key to dismiss lock)
Each approach is followed by an activation check to see if it worked.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Test GUI activation on macOS 14, 15, and 26 (Tahoe)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add DerivedData and GhosttyKit caching to CI workflows
Major caching improvements across ci.yml and ci-macos-compat.yml:
- Cache GhosttyKit.xcframework keyed on ghostty submodule SHA
(skip download on cache hit)
- Cache DerivedData keyed on OS + Xcode version + Package.resolved +
project.pbxproj (enables incremental builds across runs)
- Remove explicit DerivedData wipe (rely on cache key invalidation)
- Use download-prebuilt-ghosttykit.sh in compat workflow too
This should significantly speed up macOS 14 compat tests which were
taking 20+ min due to full recompilation every run.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Bump macOS 14 compat timeout to 45 min for cold cache seeding
The DerivedData cache wasn't saved because the job timed out at 30 min,
causing the post-job cache save step to be skipped. 45 min gives enough
headroom for the first uncached run to complete and seed the cache.
Subsequent runs should be much faster with incremental builds.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Use Depot runners for E2E tests (WarpBuild has screen lock on macOS 15/26)
WarpBuild VMs on macOS 15 and 26 have CGSSessionScreenIsLocked=1, which
prevents XCUIApplication activation. Depot runners have working GUI
activation. Can switch back to WarpBuild once they fix the VM images.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Skip smoke test on macOS 14 compat, remove GUI diagnostic workflow
macOS 14 was slow because it built the full app (cmux scheme) on top of
unit tests (cmux-unit scheme). Unit tests are the real compat check;
smoke test runs on macOS 15 only. Also removes the temporary
test-warpbuild-gui.yml diagnostic workflow.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Replace Sonoma with Tahoe in compat matrix, drop macOS 14
Swap macOS 14 (Sonoma) for macOS 26 (Tahoe). Smoke test runs on
macOS 15 only (WarpBuild screen lock blocks app activation on 26).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Drop macOS 26 from compat matrix (zig 0.15.2 linker failure)
Zig 0.15.2 can't link against the macOS 26 (Tahoe) SDK: undefined
symbols for basic libc functions (_abort, _free, _fork, etc.). The zig
toolchain needs an update to support Tahoe. Keep macOS 15 only for now.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Lawrence Chen <lawrencecchen@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
