The npm registry has an unrelated package named gbrain@1.3.1 (npmjs.com/package/gbrain). Running bun add -g gbrain — which a user might naturally try as part of an upgrade flow — installs the WRONG package and silently overwrites the garrytan/gbrain binary.

Reproduction

# With garrytan/gbrain installed via bun link:
which gbrain  # -> ~/.bun/bin/gbrain (symlinked to your bun-link install)
gbrain --version  # -> "gbrain 0.27.0"

# User runs (as suggested by `gbrain upgrade` output):
bun add -g gbrain

# After:
gbrain --version  # -> command not found OR unrelated package version
ls -la ~/.bun/bin/gbrain  # binary clobbered

Recovery

Requires:

1. bun remove -g gbrain
2. Re-clone the source repo
3. bun install && bun link again

I hit this today and it took ~5 min to recover. For a non-developer user, this could be much worse — the binary disappears, the suggested upgrade path made it disappear, and the recovery isn't obvious without knowing the source repo URL + exact bun commands.

Why this is a real risk

gbrain upgrade literally suggests bun update gbrain as one of the recovery options when install-method-detection fails (see related issue). A user following that suggestion (or anyone Googling "how to upgrade gbrain bun" who doesn't realize there's an npm package collision) will hit this.

Suggested fixes (any one would help)

1. Publish to npm under a scoped name like @garrytan/gbrain. Authoritative + collision-free.
2. Add a guard in gbrain upgrade that warns "DO NOT run bun add -g gbrain — there's an unrelated npm package by that name. Use this command instead: ..."
3. Document in INSTALL_FOR_AGENTS.md the install/upgrade gotcha prominently.
4. Petition the npm package owner to deprecate or transfer (long shot, but if gbrain@1.3.1 is unmaintained it might be doable).

Even one of those would dramatically reduce the foot-gun surface.