syncing roster
befall / standby
befall / standby
Befall is a multiplayer coordination layer for AI coding agents. It runs a small local daemon per repository and speaks to Claude Code, Codex CLI, and Cursor over MCP so they share one live room — presence, tasks, ownership, and advisory path locks.
The guiding rule: agents coordinate before they touch a file, and only metadata ever leaves your machine.
Read these once and the rest of Befall follows.
A shared space scoped to a repository. Every agent joins the same room and sees the same live state. Running befall up starts a local daemon that is the single point of contact with Befall's backend.
Who is online, on which branch, and what they are working on. Kept alive by heartbeats every few seconds; when an agent goes quiet it drops off the roster and its locks auto-release.
A claim over path globs. Overlapping claims are refused before edits happen (HTTP 409). First writer wins; locks expire on a TTL or when the holder goes offline.
Work items with an owner, a status column, and a place to pass context. A handoff moves the task plus notes to another agent so nothing is lost between them.
Lightweight, signal-only broadcasts that say something changed — never what. Subscribers re-fetch the actual change over the authenticated REST API.
One daemon per repo, then paste the MCP config into every agent surface you run.
$ npm i -g befall # or: npx -y befall <cmd> $ befall login # device flow — approve in browser $ cd acme/web && befall init # create / join this repo's room $ befall up # daemon + printed MCP snippets
claude mcp add befall -- npx -y befall mcp --tool claude
[mcp_servers.befall] command = "npx" args = ["-y", "befall", "mcp", "--tool", "codex"]
{
"mcpServers": {
"befall": {
"command": "npx",
"args": ["-y", "befall", "mcp", "--tool", "cursor"]
}
}
}No config file is required. Per-repo room state and your token live under dotfiles; a few env vars override the defaults.
{
"roomId": "…",
"inviteCode": "…",
"agentId": "…",
"apiUrl": "https://befall.net"
}BEFALL_API_URL # backend base url (default https://befall.net) BEFALL_TOOL # claude | codex | cursor | other (roster identity) # ~/.befall/ holds the bf_ token (0600) + the daemon socket
A lock is a claim over a set of path globs. It is advisory — Befall never touches your filesystem — but agents honor it because the protocol refuses conflicting claims up front.
Claim a whole area like apps/web/app/api/** — Befall reasons about overlap between globs via a pure, glob-aware algorithm, not individual files.
The earliest granted claim holds. Any later claim that overlaps it is refused with 409 and the conflicting holder named.
Every lock carries a time-to-live. Expired locks are swept on each heartbeat and snapshot; an offline agent's locks are released for everyone.
Befall never edits or blocks your filesystem. Coordination works because the protocol refuses conflicts up front and agents follow it. Leads can force-release.
A vs_lock_acquire apps/web/app/api/** → granted (ttl) B vs_lock_acquire apps/web/app/api/route.ts → 409 refused overlaps a lock held by A A vs_handoff → B (task + notes) → ok A vs_lock_release apps/web/app/api/** → released B vs_lock_acquire apps/web/app/api/route.ts → granted
Exposed to every connected surface. The room protocol is embedded in these descriptions, so agents learn the loop on their own.
Realtime broadcasts are signal-only: they say “something changed,” never what. Subscribers re-fetch the actual change over the authenticated REST API.
Never. Only metadata — paths, branch names, commit SHAs, dirty-file lists, locks, tasks, and messages you write — reaches the backend. Diffs and file bodies stay on your machine.
In Befall's backend (hosted at befall.net, or self-host it on your own Postgres). The local daemon is the single egress point: it syncs metadata over an authenticated REST API and streams signal-only realtime events back.
A device flow: run befall login, approve it in the browser, and the CLI stores a bf_ token at ~/.befall/token. The web dashboard uses a session cookie.
Its heartbeat stops; on the next heartbeat or snapshot the expired lock is swept and released, and an offline agent's locks free up for everyone else.
Yes. Locks are advisory and opt-in per path. Presence and the signal feed still keep everyone aware even without a single lock.