From 4b1142e762ed3ea3737e26fe46167513147ac20c Mon Sep 17 00:00:00 2001 From: Joseph Mearman Date: Sun, 13 Sep 2026 15:23:25 +0100 Subject: [PATCH] fix(sea): drop Intel macOS from the release matrix, an unsupported Node SEA platform MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A real macos-26-intel runner confirmed the packaged binary SIGSEGVs within a second of starting, every time. Node's own SEA docs state plainly, under Platform Support, "macOS (arm64 only; x64 is not currently supported and is skipped in the tests)" — nodejs/node#62893 tracks the identical crash upstream, unresolved. This is a genuine gap in Node's own SEA feature for that platform, not something fixable in this repository, unlike the earlier native-Windows named-pipe work, which had a real fix available. cc-peer's regular npm package (and npx cc-peer) already works fine on Intel macOS — verify-macos (macos-26-intel) runs the real, unbundled module there — only the standalone SEA executable can't be built for it, so that job keeps the platform while sea drops it. README updated to state this precisely rather than claim every platform pair ships a binary. --- .github/workflows/ci.yml | 3 +-- README.md | 3 ++- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 56923fb..6fb25f2 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -168,10 +168,9 @@ jobs: strategy: fail-fast: false matrix: - # Every (platform, arch) pair on a standard runner image: two darwin legs (macos-26-intel is GitHub's current x64 counterpart to macos-latest's arm64 — see verify-macos's own comment on why this isn't macos-latest-large or the retired macos-13), two linux, two win32. Windows was excluded here previously (a genuine Node limitation: no filesystem-path AF_UNIX support on Windows, only named pipes — nodejs/node#55979), but CcPeer now branches to a real named pipe on native Windows (see paths.ts and win-proc-info.ts), so both legs build a working binary again. build-sea.ts qualifies each asset name by process.platform AND process.arch so shared-OS legs cannot clobber each other's release upload, and gives win32 its .exe. + # One darwin leg, two linux, two win32 — deliberately not two darwin legs. macos-26-intel (x64) is excluded here specifically, not as a runner-availability guess: Node's own SEA docs state plainly, under Platform Support, "macOS (arm64 only; x64 is not currently supported and is skipped in the tests)" (nodejs.org/api/single-executable-applications.html), and a real run confirmed it — the packaged binary SIGSEGVs within a second of starting on a genuine macos-26-intel runner (nodejs/node#62893 tracks the same crash upstream, unresolved). This is a gap in Node's own SEA feature for that platform, not something fixable here: cc-peer's regular npm package (and npx cc-peer) already works fine on Intel macOS, proved by verify-macos (macos-26-intel) running the real, unbundled module there — only the standalone SEA executable can't be built for it. Windows was excluded here previously too (a genuine Node limitation: no filesystem-path AF_UNIX support on Windows, only named pipes — nodejs/node#55979), but CcPeer now branches to a real named pipe on native Windows (see paths.ts and win-proc-info.ts), so both legs build a working binary again — an actual fix, unlike Intel macOS's SEA gap, which has none available. build-sea.ts qualifies each asset name by process.platform AND process.arch so shared-OS legs cannot clobber each other's release upload, and gives win32 its .exe. include: - os: macos-latest - - os: macos-26-intel - os: ubuntu-latest - os: ubuntu-24.04-arm - os: windows-latest diff --git a/README.md b/README.md index ab30560..1c72707 100644 --- a/README.md +++ b/README.md @@ -53,7 +53,7 @@ peer.on("idle", (n) => console.log(`session ${n.state}`)); await peer.stop(); ``` -Every release is also mirrored to the GitHub Packages registry as `@exadev/cc-peer` (GitHub Packages requires owner-scoped names), and single-executable binaries for every platform/architecture pair ship as release assets. +Every release is also mirrored to the GitHub Packages registry as `@exadev/cc-peer` (GitHub Packages requires owner-scoped names), and single-executable binaries ship as release assets for every platform/architecture pair Node's own SEA feature supports (see Limitations for the one exception). The REST facade (`npx cc-peer`) serves `GET /sessions`, `POST /messages`, `POST /idle-subscriptions`, `GET /events` (SSE), and a self-describing `GET /openapi.json` on loopback with a bearer token. @@ -62,5 +62,6 @@ The REST facade (`npx cc-peer`) serves `GET /sessions`, `POST /messages`, `POST - **Same-process constraint**: receipts and idle notices only reach the process that owns the peer's listening socket (the protocol verifies return addresses via kernel peer-pids). Do not split `CcPeer` listening and sending across processes or differently-owned workers. - **Single machine**: the local protocol is Unix-socket only. Writing to cloud sessions directly is blocked by design (device-attestation-signed events); bridged sessions reachable locally still work via their local mirror. - **Windows uses a named pipe, not a Unix socket**: Node's `net` module has no real AF_UNIX support on Windows (its local domain there is a named pipe, under `\\.\pipe\`, not an arbitrary filesystem path — [nodejs/node#55979](https://github.com/nodejs/node/issues/55979)), and Claude Code's own docs confirm it uses exactly that on native Windows. `cc-peer` branches to a named pipe there automatically; nothing to configure. Windows also requires a valid, matching auth line on every inbound connection (macOS and Linux tolerate an absent or foreign one). The exact `procStart` string format `cc-peer` computes on Windows is its own convention (PowerShell's process start time, ISO-8601) rather than a confirmed match for a real native-Windows Claude Code session's own registry entries, which is not publicly documented. +- **No single-executable binary for Intel macOS**: Node's own SEA feature doesn't support macOS x64 at all (its docs state plainly, under Platform Support, "macOS (arm64 only; x64 is not currently supported and is skipped in the tests)"; [nodejs/node#62893](https://github.com/nodejs/node/issues/62893) tracks the same crash). This is a gap in Node's own runtime, not in `cc-peer` — the regular npm package (and `npx cc-peer`) works fine on Intel macOS; only the standalone binary can't be built for it. - **File transfers to Claude sessions** wait on an upstream feature flag (`tengu_send_file`) before Claude-side materialisation activates; peer-to-peer transfers work today. - Verified against Claude Code 2.1.269; treat every Claude Code upgrade as a potential protocol change.