fix: use Homebrew for signal-cli install on non-x64 architectures (bug #15372)#15443
Conversation
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| async function installSignalCliViaBrew(runtime: RuntimeEnv): Promise<SignalInstallResult> { | ||
| const brewExe = resolveBrewExecutable(); | ||
| if (!brewExe) { | ||
| return { | ||
| ok: false, | ||
| error: "Signal CLI auto-install is not supported on Windows yet.", | ||
| error: | ||
| `No native signal-cli build is available for ${process.arch}. ` + | ||
| "Install Homebrew (https://brew.sh) and try again, or install signal-cli manually.", | ||
| }; |
There was a problem hiding this comment.
Brew detection misses PATH
installSignalCliViaBrew relies on resolveBrewExecutable() which only checks a few hard-coded locations and HOMEBREW_* env vars. If brew is installed but only available via PATH (common on CI or custom setups), brewExe will be undefined and this returns the "Install Homebrew" error even though Homebrew is present.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/commands/signal-install.ts
Line: 157:165
Comment:
**Brew detection misses PATH**
`installSignalCliViaBrew` relies on `resolveBrewExecutable()` which only checks a few hard-coded locations and `HOMEBREW_*` env vars. If `brew` is installed but only available via `PATH` (common on CI or custom setups), `brewExe` will be `undefined` and this returns the "Install Homebrew" error even though Homebrew is present.
How can I resolve this? If you propose a fix, please make it concise.
There was a problem hiding this comment.
Fixed in 016cbf0. Added findBrewInPath() that runs which brew as a fallback when resolveBrewExecutable() returns undefined. The lookup chain is now: hardcoded paths + HOMEBREW_* env vars → PATH lookup → error.
| runtime.log(`Installing signal-cli via Homebrew (${brewExe})…`); | ||
| const result = await runCommandWithTimeout([brewExe, "install", "signal-cli"], { | ||
| timeoutMs: 15 * 60_000, // brew builds from source; can take a while | ||
| }); | ||
|
|
||
| if (result.code !== 0) { | ||
| return { | ||
| ok: false, | ||
| error: `brew install signal-cli failed (exit ${result.code}): ${result.stderr.trim().slice(0, 200)}`, | ||
| }; |
There was a problem hiding this comment.
Brew spawn errors escape
The runCommandWithTimeout([brewExe, "install", "signal-cli"]) call isn’t wrapped in try/catch, but runCommandWithTimeout rejects on spawn errors (missing executable, permission issues, etc.). That means installSignalCliViaBrew can throw instead of returning a structured { ok: false, error }, and the caller only sees a generic exception string.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/commands/signal-install.ts
Line: 168:177
Comment:
**Brew spawn errors escape**
The `runCommandWithTimeout([brewExe, "install", "signal-cli"])` call isn’t wrapped in `try/catch`, but `runCommandWithTimeout` rejects on spawn errors (missing executable, permission issues, etc.). That means `installSignalCliViaBrew` can throw instead of returning a structured `{ ok: false, error }`, and the caller only sees a generic exception string.
How can I resolve this? If you propose a fix, please make it concise.There was a problem hiding this comment.
Fixed in 016cbf0. The runCommandWithTimeout call is now wrapped in try/catch and returns a structured { ok: false, error } on spawn failures.
steipete
force-pushed
the
fix/signal-cli-arch-aware
branch
from
016cbf0 to
78a7a30
Compare
3 participants
Summary
AI-assisted The signal-cli auto-installer downloads x86-64 GraalVM native binaries regardless of host architecture. On non-x64 systems (e.g., Raspberry Pi aarch64) this causes Exec format error when the binary is executed.
This PR makes pickAsset architecture-aware and adds a Homebrew fallback for non-x64 Linux, since official signal-cli releases only publish native binaries for x86-64.
Closes #15372
Repro Steps
Root Cause
pickAsset() selected release assets based on OS only, with no architecture check. The Linux-native asset is an x86-64 GraalVM binary, but it was selected on all Linux architectures.
Behavior Changes
Codebase and GitHub Search
Tests
Fully tested. 15 new unit tests in src/commands/signal-install.test.ts (all passing):
pnpm vitest run src/commands/signal-install.test.ts
✓ src/commands/signal-install.test.ts (15 tests) 44ms
Test Files 1 passed (1)
Tests 15 passed (15)
Manual Testing
Tested on a Raspberry Pi 4 (aarch64 Linux) — When using
openclaw configto set up Signal, brew install signal-cli completes successfully and the installed binary works.Sign-Off
Greptile Overview
Greptile Summary
This PR updates signal-cli auto-install to avoid selecting the x86_64 Linux-native asset on non-x64 Linux and instead fall back to installing via Homebrew. It also refactors asset selection into exported helpers (
looksLikeArchive,pickAsset) and adds unit tests covering platform/arch-aware asset picking and skipping.ascsignatures.The main flow now chooses between “download from GitHub release assets” and “brew install signal-cli” based on
process.platform/process.arch, then returns aSignalInstallResultwith the installed binary path and version when available.Confidence Score: 3/5
Last reviewed commit: 4ee37d1
(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!