Use Fungi

Git hosting for many AI agents with Bonsai

Give each coding agent its own fork, push with ordinary Git and an Oyster key, and see which agent pushed each commit before reviewing a Change.

When multiple coding agents work on one repository at once, give each one a fork instead of a shared checkout. Bonsai hosts those repositories on Oyster. Each agent pushes with ordinary Git and its own Oyster key. The network graph shows one lane per fork and colours commits by the key that pushed them.

That attribution comes from the authenticated push, not the commit’s author field. The agent never needs the host’s Cloudflare Artifacts credential.

Before you start

Follow Run your own Oyster to deploy Oyster and install its starter Apps with npx oyster install-apps. Bonsai uses Cloudflare Artifacts for Git storage through Burrow. The laptop-only Oyster setup does not provide that storage.

Sign in at $OYSTER_URL/login with your owner key, open Bonsai, and choose a canonical repository for the work. The commands below use an existing repository named koi-pond.

1. Give each agent a key

Create a named key as the owner:

curl -X POST -H "Authorization: Bearer $OYSTER_OWNER_KEY" \
  -H 'content-type: application/json' \
  -d '{"name":"morel","grants":[{"capability":"apps.use","targets":{"kind":"all"}}]}' \
  "$OYSTER_URL/api/keys"

The response shows plaintext once, beginning oyk_. Keep it private and make it available to that agent as KEY. The name is also the key’s ID.

This example grants access to every App on that Oyster, including Apps installed later. It lets the holder act as the owner in those Apps without a per-call write prompt. It is not a credential limited to one Git fork. See the MCP and key guide before issuing it.

Repeat with a different name and key for each agent. Sharing a key loses the push attribution that distinguishes the agents.

2. Fork and clone

With Morel’s key, request its fork:

curl -X POST -H "Authorization: Bearer $KEY" \
  -H 'content-type: application/json' \
  -d '{"repo":"koi-pond"}' \
  "$OYSTER_URL/apps/bonsai/methods/repos.fork"

git -c http.extraHeader="Authorization: Bearer $KEY" \
  clone "$OYSTER_URL/git/bonsai/koi-pond--morel.git"

repos.fork creates the caller’s <repo>--<name> fork, or returns its existing fork. Fork the canonical repository, not another agent’s fork.

Give each agent its own clone and task. It edits and commits in that clone, then pushes through Oyster’s Git door:

git -C koi-pond--morel -c http.extraHeader="Authorization: Bearer $KEY" push

Oyster admits the key at its Git door and holds the provider credential itself. Do not put that provider credential in the repository or agent prompt.

3. Follow the work

Open Bonsai’s Overview. The network graph draws each fork in its own lane and the live feed records pushes. Merges fold back into main.

New fork work also opens a Change. Bonsai measures it against main on each push: commits ahead and behind, and the diff it would bring in. Review the actual diff rather than using an agent’s completion message as proof.

4. Review and merge the exact head

The UI and agent tools use the same method API:

Method	Purpose
`changes.list` / `changes.get`	Inspect proposals and their current heads.
`changes.open`	Open a proposal explicitly from a source branch.
`changes.approve`	Record an eligible person’s approval of an exact head.
`changes.merge`	Let a person maintainer merge that reviewed head.
`changes.close`	Close a proposal without merging it.

Approval and merge take the repository, Change number and exact head SHA. Agents report reviews as checks; they do not approve or merge their own work through these person-only doors. Failing or pending checks block a merge. Bonsai always writes a merge commit.

If main has moved and the merge conflicts, Bonsai records the conflicting paths. Hand the work back to the agent: pull main, resolve the conflict, and push the resolution before reviewing the new head.

Discover the current method inputs through Oyster’s MCP catalog before calling them. Connect an MCP client if the agent should use App tools as well as Git.

Storage and access

Bonsai’s backend keeps repository-page copies in its SQLite storage. Its Git binding creates, forks, reads and merges repositories in Cloudflare Artifacts, scoped to the installation. Burrow owns the Git smart-HTTP adapter; Oyster owns credential custody.

To stop a key’s future access, the owner can call POST $OYSTER_URL/api/keys/revoke with {"keyId":"morel","requestId":"<a unique request id>"}. Revocation does not undo commits already pushed or merged.

For host setup, return to the Oyster quick start.