Repository navigation
[Bug]: Intel-only gh makes local Apple Silicon environment appear disconnected #14590
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop (with a server-side error)
What happened
T3 Code showed my local MacBook as disconnected even though its backend was running on the same laptop. Opening General settings showed:
Reconnect Cesar’s MacBook Pro to change its settings.
The problem was an Intel-only gh executable left in /usr/local/bin on an Apple Silicon Mac. Running it directly failed with bad CPU type in executable. Installing native gh and fully restarting T3 fixed the connection.
Steps to reproduce
This is the configuration where I encountered the problem; I have not recreated it on a clean machine.
- On an Apple Silicon Mac, have an Intel-only
ghon the PATH used by T3, with no working native version taking precedence. In my case it was/usr/local/bin/gh. - Open T3 Code desktop and connect to the local environment.
- Open Settings → General for that environment.
Expected behavior
A GitHub CLI failure should report which executable failed and why. If GitHub CLI probing is optional, it should leave the local environment usable and mark GitHub integration unavailable.
Actual behavior
The local environment appeared disconnected. The settings page asked me to reconnect the laptop without showing the underlying error or a way to resolve it.
Impact
Major degradation: I could not access the environment’s settings until the CLI installation was fixed.
Version and environment
- T3 Code desktop: 0.0.44
- macOS: 27.0 (26A428), Apple Silicon / arm64
- Environment: this same laptop, backend at
http://127.0.0.1:3774 - Failing CLI: Intel-only GitHub CLI 2.97.0 under
/usr/local
Evidence
The backend responded over HTTP. Logs showed successful WebSocket authentication, followed by an error in the client’s server-config subscription:
EnvironmentAuth.authenticateWebSocketUpgrade: Success
RpcClient.subscribeServerConfig: spawn Unknown system error -86
Server traces also recorded spawn Unknown system error -86 in process execution and GitHub CLI calls. The local CLI check confirmed the incompatible executable:
$ uname -m
arm64
$ file /usr/local/bin/gh
/usr/local/bin/gh: Mach-O 64-bit executable x86_64
$ gh --version
zsh: bad CPU type in executable: gh
This suggests a CLI probe failure reaches the settings subscription and causes the environment to be treated as disconnected. I have not traced the code path, so that part still needs confirmation.
Workaround
Install native GitHub CLI, ensure it takes precedence on PATH, then fully quit and reopen T3 Code. In my case, installing gh with Apple Silicon Homebrew put it at /opt/homebrew/bin/gh and resolved the issue.
I also repaired an outdated background service from 0.0.42 to 0.0.44 first. That did not resolve the issue; replacing the incompatible gh executable and restarting did.
Offer to help
If a maintainer agrees this should be addressed, I’m happy to investigate and contribute a focused fix. Would you prefer isolating the CLI probe failure so the environment stays connected, surfacing the underlying error in the UI, or both? I’ll wait for agreement on the scope before starting.
Activity
camptx commentedon Oct 1, 2026
One additional detail: I first encountered this issue after upgrading this laptop to macOS Golden Gate (27.0). I haven’t confirmed whether the upgrade caused the failure, but the timing may help with investigation.
juliusmarminge commentedon Oct 1, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the thorough report and the evidence. This is a real bug: a
ghthat's on PATH but can't run shouldn't make the local environment look disconnected.On macOS, errno -86 is
EBADARCH. Node reports it asspawn Unknown system error -86, which is the same failure asbad CPU type in executablefor the x86_64/usr/local/bin/ghon your Apple Silicon machine. Command lookup only checks that the file exists and is executable, so a wrong-architecture binary passes and T3 treatsghas installed.GitHubCli.fromVcsErroronly turns a spawn failure into "GitHub CLI is not available" when the platform error isNotFound. Any other spawn failure, including a bad CPU type, becomes a generic "GitHub CLI command failed."The desktop client doesn't mark an environment as connected until
subscribeServerConfigdelivers its first snapshot, and if that call fails or the subscription dies later, the session closes. Settings shows "Reconnect {name} to change its settings" whenever the environment isn't in the connected set, and that message doesn't include the underlying error. That's the screen you hit, even though the backend was up and the websocket upgrade succeeded.A fatal error on the websocket applies to the whole connection, so it fails every in-flight call, including
subscribeServerConfig. That fits your log, where authentication succeeds and then the config subscription dies with the same spawn error recorded on the GitHub CLI process spans. The config snapshot itself doesn't spawngh(on 0.0.44 or onmain), and source-control discovery does catch a probe failure and marks the CLI as missing, so the probe alone isn't supposed to drop the connection. The gap is that aghthat can't run can still show up as an environment disconnect instead of an integration failure. Updating past 0.0.44 won't fix it. Putting a nativeghahead of the Intel binary on PATH is the right workaround for now.macOS 27 could be why this started for you, if Rosetta had been running that
/usr/local/bin/ghbefore. But any arm64 machine with a wrong-architectureghearlier on PATH can hit it. No existing issue covers this.To your scope question: both parts you suggested are worth doing, and keeping the connection up is what unblocks Settings. The environment should stay connected when an optional CLI fails to spawn, and a bad CPU type should be treated the same as not installed. The error should name the executable and the reason (the path and the architecture mismatch), so GitHub integration shows as unavailable instead of asking you to reconnect the laptop. This is separate from configuring a custom CLI path. A focused PR that links this issue is very welcome.
delu999 commentedon Oct 2, 2026
I encountered the same issue on T3 Code Nightly
0.0.45-nightly.20261002.2572, macOS 27.0 (26A428), Apple Silicon (arm64). The local backend was running and listening on loopback, but the composer repeatedly showed “pc is reconnecting”.The
ghexecutable resolved from T3’s PATH was an Intel-only Mach-O (x86_64). Runninggh --versiondirectly failed withbad CPU type in executable.The server traces recorded this sequence:
Replacing the incompatible executable at the same PATH location with the official macOS arm64 GitHub CLI 2.102.0 (download verified against the published SHA-256 checksum) resolved the problem. T3 reconnected automatically, without restarting the app. Subsequent
ws.rpc.server.discoverSourceControlandEnvironmentRpc.currentSessioncalls succeeded, including repeated session calls over the following minutes.This confirms that the problem also affects the October 2 nightly. The incompatible local CLI explains the spawn failure, but T3 should keep the environment connected and show an actionable GitHub integration error when that optional executable cannot run.