Skip to content

Add plugin entry: antigravity-acp - #131

Open
rawizhere wants to merge 1 commit into
get-bb:mainfrom
rawizhere:submit-antigravity-acp
Open

Add plugin entry: antigravity-acp#131
rawizhere wants to merge 1 commit into
get-bb:mainfrom
rawizhere:submit-antigravity-acp

Conversation

@rawizhere

Copy link
Copy Markdown

What

Adds the antigravity-acp plugin to the bb marketplace.

About the plugin

Google Antigravity as a bb agent provider through its official ACP server, with the same provider bridge as bb's built-in ACP agents.

Validation

  • npm run build passes — marketplace.json compiles (83 entries, no errors)
  • Git source tag v0.1.0 exists on the plugin repository

@SawyerHood

Copy link
Copy Markdown
Contributor

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

Thanks for the submission — we really want to get this in. For the first run of the marketplace we are aiming for a small set of very polished plugins, and we will open it up more broadly soon. Here is what we found reviewing the source at the tag your entry resolves to and installing it from that entry into a dev build of BB 0.40:

Blocker 1: the plugin fails to install

Installing git:https://github.com/rawizhere/bb-plugin-antigravity-acp.git@^0.1.0 (resolves to v0.1.2) into a dev build of BB 0.40 fails:

install failed: host bundle build for "antigravity-acp" failed:
host.ts:14:7: ERROR: Could not resolve "@get-bb/plugin-sdk/provider-bridge/acp"

We reproduced it standalone. The cause is a stale package-lock.json: your package.json correctly has @get-bb/plugin-sdk: 0.4.22 in dependencies, but the lockfile still marks node_modules/@get-bb/plugin-sdk with "dev": true from when it was a devDependency. BB's managed git install runs npm install --ignore-scripts --omit=dev --omit=optional, which honours the lockfile, so the SDK never lands on disk — and unlike the SDK root, provider-bridge/acp is deliberately not stubbed by the builder (it is real published code, not a host-implemented shim), so the bundle cannot resolve it.

Fix: delete package-lock.json, re-run npm install, commit, and re-tag. You can verify with npm install --ignore-scripts --omit=dev --omit=optional && bb plugin build . in a clean checkout.

Blocker 2: the plugin id collides with an earlier submission

PR #102 claims the same entries/antigravity-acp.json. We looked carefully at whether either is a copy of the other, and they are notdiff -r shows zero identical files and the architectures are genuinely different (you re-export the canonical SDK bridge and run Google's long-lived agy_acp_server.par; theirs is a hand-written 546-line bridge shelling out to the agy CLI per turn). This is two people picking the same id from the same bb-plugin-<id> convention.

We are awarding the id to #102 on priority: its repo and marketplace PR both predate yours by 5 days, it is MIT-licensed, and a third-party plugin (bb-plugin-usage) already has a merged integration reading the on-disk format it writes.

We would like to list yours too — please rename to a non-colliding id. antigravity-acp-server, antigravity-acp-official or google-antigravity-acp all describe it accurately, and yours is the one that wraps Google's official ACP server. The entry filename, the icons/ asset name and package.json's name all need to change together. Note there is no runtime conflict between the two — you register provider acp-antigravity, they register antigravity.

Also worth fixing

  • The downloaded binary is neither checksummed nor signature-verified. install.ts:165-176 streams an arbitrary URL to disk, :330 chmod 0o755s it, :209-225 symlinks it onto PATH, and the ACP bridge then executes it every turn. The URL is not pinned: fetchDistMap() (:117-143) fetches agentclientprotocol/registry on main, unauthenticated, no pinned commit. Anyone who can land a commit there gets arbitrary-binary-on-PATH on every machine that runs bb antigravity-acp install afterwards. In its favour: it is an explicit opt-in command, and we checked the live registry — its five dl.google.com URLs are character-for-character identical to your FALLBACK_DIST (:26-54), so the fallback is an honest mirror. Please add a SHA-256 check against a pinned digest, or at minimum pin the registry to a commit SHA.
  • Zip-slip on extraction. extractZip (:178-201) shells to tar -xf for zips on macOS/Windows, and bsdtar does not sanitize ../ the way unzip and Python's zipfile.extractall do. Compounding it, helperNameIn (:203-207) links any extracted file matching /^localharness.*/ onto PATH (:347-352). Fixing the trust root above closes this too.
  • Linux launch args are dropped. server.ts:42 hardcodes args: [], but the ACP registry specifies args: ["--uid="] for linux-x86_64 and linux-aarch64 (we confirmed against the live registry). You read entry.args into DistEntry and never use it, so the server may fail to launch on Linux.
  • AGY_ACP_INSTALL_FROM (install.ts:296) silently redirects the download from an env var with no confirmation. Prefer the explicit --from flag.
  • Windows PATH mutation. appendUserPathWindows (:227-239) runs setx Path to permanently modify HKCU\Environment, announced only in a post-hoc note. It also inherits setx's 1024-char truncation hazard.
  • No LICENSE file, and package.json has no license field.
  • Leftover template cruft: package.json:22-36 lists sonner, vaul, @pierre/diffs etc., and tsconfig.json includes app.tsx, components, lib, hooks — none of which exist.

What we liked

This is the cleanest of the three ACP submissions we looked at. It delegates all protocol work to the SDK bridge instead of hand-rolling it, uses execFile with array args throughout so there is no injection surface, touches no secrets, and — unlike a sibling submission — does not auto-install anything. It also matches BB's own first-party house style closely: acp-<agent> provider id, experimental_visibility: "installed", branding.icon as a plugin-relative SVG. Typecheck is clean against the published SDK.

@SawyerHood SawyerHood left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review (Claude Code agent on behalf of the maintainer): requesting changes per the feedback comment above. Ping here when a new version is published and we will re-check.

@SawyerHood SawyerHood added the blocked Waiting on plugin author changes before it can be listed label Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

blocked Waiting on plugin author changes before it can be listed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants