ci: run macOS tests on Apple Silicon to avoid build-timeout flakiness

[kmatsunami]

Problem

swift-test-macos shards intermittently fail with a timeout, not a test failure. In run 28084754287 (push to main), shard (3,4)'s Swift Test step (timeout-minutes: 35) spent ~20 min building the full GUI-inclusive test target + swift test list discovery on the Intel runner before any test ran (08:13:31 → 08:33:19), leaving too little time for the 127 sharded swift test groups (run with CODEXBAR_TEST_GROUP_SIZE=1). The step hit 35 min and was killed mid-run (log ends with Terminate orphan process: pid (swift)). No assertion failed.

Root cause: swift-test-macos runs on macos-15-intel, where the cold Swift build of the test target is slow and variable, and the build runs inside the 35-min test budget with no .build cache.

Change

Run swift-test-macos on Apple Silicon (macos-15) instead of macos-15-intel. ARM runners build Swift substantially faster, so the build fits comfortably within the existing 35-min budget. One line in .github/workflows/ci.yml.

Trade-off / notes

• This drops x86_64 test coverage in the CI matrix. The x86_64 release binary is unaffected — release-cli.yml still builds it on macos-15-intel (left untouched).
• If keeping Intel test coverage is preferred, lower-touch alternatives are caching .build (actions/cache) or moving swift build --build-tests into a separate step outside the 35-min timeout. Happy to switch to either.

🤖 Generated with Claude Code

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 25, 2026, 6:51 AM ET / 10:51 UTC.

Summary
This PR changes .github/workflows/ci.yml so swift-test-macos runs on macos-15 instead of macos-15-intel.

Reproducibility: yes. The cited current-main workflow run shows swift-test-macos (3, 4) failed in the Swift Test step after about 35 minutes while the other shards and non-macOS jobs completed.

Review metrics: 2 noteworthy metrics.

• Workflow diff size: 1 file changed, 1 addition, 1 deletion. The implementation surface is small, so the main review burden is the CI coverage tradeoff rather than code complexity.
• macOS test architecture: Intel runner replaced with Apple Silicon runner. This changes which macOS architecture runs the Swift test suite on every qualifying CI run.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Update the PR body with a completed exact-head GitHub Actions run showing all changed macOS shards finish successfully.
• If maintainers want to retain Intel coverage, revise toward the documented cache or build-timeout alternative instead of replacing the runner.

Proof guidance:

• [P1] Needs real behavior proof before merge: No completed after-fix workflow proof is available yet; the contributor should update the PR body with exact-head Actions results after the macOS shards finish, redacting private details if any logs are copied.

Risk before merge

• [P1] Merging as-is stops running the macOS Swift test suite on Intel; the release workflow still builds x86_64 artifacts, but Intel-only test failures would no longer be caught by regular CI.
• [P2] The exact-head PR workflow had not completed the changed macOS shards during review, so the claimed timeout improvement still needs live Actions proof before merge.

Maintainer options:

1. Require completed ARM workflow proof
   Wait for all four exact-head swift-test-macos jobs on macos-15 to complete and link the successful run before considering merge.
2. Preserve Intel coverage with a different fix
   If Intel test execution remains required, revise the workflow to cache .build or move the test build outside the 35-minute step timeout instead of changing the runner label.
3. Accept ARM-only macOS tests
   Maintainers can deliberately accept the coverage tradeoff because x86_64 release builds remain in release-cli.yml, but that policy choice should be explicit.

Next step before merge

• [P1] The remaining action is maintainer review of CI architecture coverage plus completed exact-head Actions proof, not an automated code repair.

Security
Cleared: The diff only changes a GitHub-hosted runner label and introduces no new permissions, third-party actions, secrets handling, downloads, or script execution paths.

Review details

Best possible solution:

Either preserve Intel test coverage with a cache or build-step split, or explicitly accept ARM-only macOS CI after exact-head Actions proof shows the timeout is resolved.

Do we have a high-confidence way to reproduce the issue?

Yes. The cited current-main workflow run shows swift-test-macos (3, 4) failed in the Swift Test step after about 35 minutes while the other shards and non-macOS jobs completed.

Is this the best way to solve the issue?

Unclear. Switching to Apple Silicon is a narrow fix for build-time budget pressure, but the best solution depends on whether maintainers want to keep Intel test coverage through caching or a separate build step.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against ada3660e9d61.

Label changes

Label changes:

• add P2: This is a normal CI reliability improvement for a real main-branch macOS test timeout with limited repository-scope blast radius.
• add merge-risk: 🚨 automation: The diff changes CI runner selection and removes Intel execution from the regular macOS Swift test matrix.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No completed after-fix workflow proof is available yet; the contributor should update the PR body with exact-head Actions results after the macOS shards finish, redacting private details if any logs are copied.

Label justifications:

• P2: This is a normal CI reliability improvement for a real main-branch macOS test timeout with limited repository-scope blast radius.
• merge-risk: 🚨 automation: The diff changes CI runner selection and removes Intel execution from the regular macOS Swift test matrix.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No completed after-fix workflow proof is available yet; the contributor should update the PR body with exact-head Actions results after the macOS shards finish, redacting private details if any logs are copied.

Evidence reviewed

What I checked:

• Current CI runner: Current main runs the swift-test-macos job on macos-15-intel with a 35-minute Swift Test step inside a 40-minute job. (.github/workflows/ci.yml:89, ada3660e9d61)
• PR diff surface: The PR changes only .github/workflows/ci.yml, with 1 addition and 1 deletion at the macOS runner label. (.github/workflows/ci.yml:89, 328eddda6e48)
• x86_64 release build remains: The release CLI workflow still includes a macos-x86_64 matrix entry on macos-15-intel, so this PR changes test coverage rather than release artifact architecture. (.github/workflows/release-cli.yml:77, ada3660e9d61)
• Reported timeout is real: The cited main-branch run concluded failure at head ada3660e9d614d7533acb9e519df64baeace8212; swift-test-macos (3, 4) failed in Swift Test after about 35 minutes while other shards completed. (ada3660e9d61)
• Current PR checks pending: At review time the PR's swift-test-macos jobs were still pending or in progress, so there was not yet completed exact-head proof that the ARM runner resolves the timeout. (328eddda6e48)
• Workflow provenance: Blame ties the current macOS test job and Intel runner line to the workflow introduction commit, with a later CI observability commit touching nearby workflow behavior. (.github/workflows/ci.yml:89, f380287041b8)

Likely related people:

• steipete: The current CI and release CLI workflows, including the Intel macOS test runner and x86_64 release matrix, appear to date to commit f380287. (role: introduced behavior; confidence: high; commits: f380287041b8; files: .github/workflows/ci.yml, .github/workflows/release-cli.yml)
• Yuxin-Qiao: Recently changed CI workflow summaries and macOS shard observability in the same workflow area via ci: add workflow summary observability #1718. (role: recent area contributor; confidence: medium; commits: f2dede1d9086; files: .github/workflows/ci.yml, Scripts/ci_macos_test_gate.sh)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[kmatsunami]

Closing — the exact-head CI proof refuted the premise of this PR.

On the macos-15 run (run 28164706265), the ARM runner did speed up the build (checkout→build→swift test list ~7.5 min vs ~20 min on Intel, job ~10 min total), but swift-test-macos (3, 4) still failed — not on the 35-min step budget, but here:

Command timed out after 120s: swift test --no-parallel --filter (^CodexBarTests\.AntigravityCLISessionTests/)
Process completed with exit code 124

So the real cause of the shard-3 flakiness is AntigravityCLISessionTests intermittently hanging and hitting the per-suite 120s timeout (CODEXBAR_TEST_SUITE_TIMEOUT=120) — a flaky/hanging test, not the runner architecture. The slow Intel build had merely masked it by hitting the 35-min step timeout first.

Switching runners doesn't fix that, so this change isn't the right fix. The actual flaky suite should be fixed instead. Closing.