Summary
After bun install -g gbrain (or when gbrain is later updated), the symlink at ~/.bun/bin/gbrain points to cli.ts which lacks the executable bit. Direct execution fails with Permission denied, breaking any MCP client that invokes the symlink path directly.
Environment
- OS: Linux 6.17.13 (Debian-based, Proxmox LXC)
- bun: 1.3.12
- gbrain: 0.9.3
- MCP client: Hermes Agent (hermes_cli.main gateway)
Reproduction
$ ls -la ~/.bun/bin/gbrain
lrwxrwxrwx ... /home/eric/.bun/bin/gbrain -> ../install/global/node_modules/gbrain/src/cli.ts
$ ls -la ~/.bun/install/global/node_modules/gbrain/src/cli.ts
-rw-rw-r-- ... src/cli.ts
$ /home/eric/.bun/bin/gbrain --help
bash: /home/eric/.bun/bin/gbrain: Permission denied
cli.ts has the correct shebang (#!/usr/bin/env bun), but mode 664 lacks the x bit.
Impact
MCP clients configured per the README (command: gbrain, args: ["serve"]) fail to start the stdio server. Observed in Hermes Agent logs:
WARNING tools.mcp_tool: Failed to connect to MCP server 'gbrain'
(command=/home/eric/.bun/bin/gbrain): [Errno 13] Permission denied
Notable behavior
The permissions get reset on every gbrain update. My logs show gbrain MCP worked for several hours on 2026-04-13, then broke the moment cli.ts was last written (during an update at 18:41), after which every subsequent restart failed. So this is not purely a first-install issue — it recurs.
Workaround
Invoking via bun run explicitly works:
bun run ~/.bun/install/global/node_modules/gbrain/src/cli.ts serve
A wrapper script that execs via bun is a functional workaround but defeats the point of the global bin entry.
Possible fixes
- Packaging: add a
postinstall in package.json that runs chmod +x src/cli.ts after install
- bun-side: if
bun link is responsible, its linking logic should preserve or set +x on shebang-bearing bin targets. (Worth confirming whether this is bun's behavior or the package's responsibility.)
- Fallback: ship a small shell wrapper as the bin target and invoke
bun run cli.ts from there
Happy to contribute a PR if you have a preferred direction.
Summary
After
bun install -g gbrain(or when gbrain is later updated), the symlink at~/.bun/bin/gbrainpoints tocli.tswhich lacks the executable bit. Direct execution fails withPermission denied, breaking any MCP client that invokes the symlink path directly.Environment
Reproduction
cli.ts has the correct shebang (
#!/usr/bin/env bun), but mode 664 lacks thexbit.Impact
MCP clients configured per the README (
command: gbrain,args: ["serve"]) fail to start the stdio server. Observed in Hermes Agent logs:Notable behavior
The permissions get reset on every gbrain update. My logs show gbrain MCP worked for several hours on 2026-04-13, then broke the moment cli.ts was last written (during an update at 18:41), after which every subsequent restart failed. So this is not purely a first-install issue — it recurs.
Workaround
Invoking via
bun runexplicitly works:bun run ~/.bun/install/global/node_modules/gbrain/src/cli.ts serveA wrapper script that execs via bun is a functional workaround but defeats the point of the global bin entry.
Possible fixes
postinstallin package.json that runschmod +x src/cli.tsafter installbun linkis responsible, its linking logic should preserve or set +x on shebang-bearing bin targets. (Worth confirming whether this is bun's behavior or the package's responsibility.)bun run cli.tsfrom thereHappy to contribute a PR if you have a preferred direction.