Adom Bridge
Public Made by Adomby adom
Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl
Linux: bridge_install drops the execute bit, so a native spawn.entrypoints.linux binary fails with EACCES
Symptom. On Linux (ab 2.1.179 on grok-bot-vm-155244935), bridge_install of a bridge whose spawn.entrypoints.linux is a native binary installs fine, then every verb fails with:
"errorCode": "bridge_spawn_failed", "lastSpawnError": "spawn failed: Permission denied (os error 13)"
Cause. The extracted entrypoint has no execute bit. The zip stores it as -rwxr-xr-x (unix mode in the external attributes), but after install it is -rw-r--r--:
-rw-r--r-- 1 box box 5106120 Oct 15 10:26 kicad-bridge <- spawn.entrypoints.linux
-rw-r--r-- 1 box box 4802560 Oct 15 10:26 kicad-bridge.exe
pup's cache on the same box shows the same thing (adom-pup-bridge.exe is 0644), so this is the extractor, not one bridge's zip.
Fix asked for. On unix, when extracting a bridge zip, restore the mode from the entry's external attributes ((external_attr >> 16) & 0o777), and in any case chmod 0755 the resolved spawn.entrypoints.<os> / entrypoint file before spawning.
Workaround in use. chmod +x on the box, then bridge_resume {"name":"kicad"}. kicad-bridge 1.0.56 then starts and answers every verb (adom/kicad-bridge#127, #128).