Live branches, sandboxes and agents

Live branches

A live branch is an ordinary branch that several people and agents edit at once. Each save travels to everyone else within a fraction of a second: people through rebasely mount, which syncs a real directory you open in any editor, and agents through the API or MCP tools. The unit is a saved range of lines, not keystrokes.

Turning live on

A writer turns live on from the repository's Live page, with rebasely mount <branch> --create, or through the API (POST /api/v1/repos/<org>/<repo>/live with {"ref": "<branch>"}). Turning it off writes a final checkpoint and disconnects everyone.

The default branch can be live only after an owner allows it in the repository's settings, under Live and sandboxes. Branches protected with required checks cannot be live.

Checkpoints are real commits

Rebasely commits the live state of the branch as a checkpoint after 10 seconds without edits, after 200 edits, and at least every 2 minutes while edits keep coming. A checkpoint is a normal commit on the branch, authored by whoever made most of its edits, with the others as co-authors. Clones and fetches see checkpoints only, so they always get a consistent tree. Pushes made by checkpoints do not start workflows unless a workflow asks for them with on: push: {checkpoints: true}, and then at most once every 5 minutes.

Pushing to a live branch

You can still push with git. Rebasely first writes a checkpoint of any pending edits, then accepts your push if it builds on that checkpoint, and sends your changes to everyone connected. If live edits landed after your last fetch, git says fetch first (or live branch moved: fetch first): pull, then push again. Force-pushing or deleting a live branch is refused until live is turned off.

When two edits meet

Each edit names the version of the file it was made against. An edit made against an older version is moved past the newer changes when they touch other lines. When two edits touch the same line, the later one is refused with the current lines, and the sender reads again and retries. rebasely mount does this for you: it merges cleanly when it can, and otherwise keeps your version next to the file as a conflict copy. Changes to other kinds of files (images, archives) are last writer wins. Paths under .git, .gitmodules, .gitattributes, symlinks and paths matching the repository's ignored patterns are never edited live.

Watching

Members of the organization see each live branch on the repository's Live page: who is connected, which files are changing, the recent changes and the latest checkpoint. On a public repository, anyone signed in can watch, read-only. People who are not signed in see checkpoints through git and the code page, but not live edits.

Limits

Live branches, sandboxes and agents are free within these limits during the beta. An edit past a limit is refused with a reason and, where waiting helps, a time to retry.

Organizations without a verified owner or a paid plan also share a monthly amount of live edits, and a number of live edits a second, with each other. When the month's amount is used up, their live edits are refused until the month ends; at the rate, for a few seconds. Reading, git and checkpoints keep working. Your organization's numbers for this month are on its Trust and limits page.

Sandboxes

A sandbox is a hidden branch for one task, named refs/sandbox/<owner>/<name>. It is created in milliseconds from any branch or commit, does not show up in branch lists or clones, and expires after 24 hours without a push (people can ask for up to 30 days, agents up to 7). Only its owner and the repository's owners push to it.

rebasely sandbox create --from main --name fix-login --worktree ../fix-login
git push origin HEAD:refs/sandbox/<owner>/fix-login
rebasely sandbox checks fix-login --wait
rebasely sandbox merge fix-login --into main --mode squash

--mode is ff (the default), merge or squash; a squash turns the sandbox's commits into one commit on the target. Conflicting merges write nothing and list the files and lines. rebasely sandbox list and rebasely sandbox delete do what they say. Workflows run on a sandbox only if they declare on: sandbox, and such runs never get secrets.

A sandbox can be live too: create it with {"live": true} through the API or the sandbox.create tool, and it works like any live branch until it is merged or deleted.

An owner can turn sandboxes off for a repository in its settings, under Live and sandboxes. Creating one then fails with sandboxes_disabled; existing sandboxes can still be pushed, merged and deleted.

Agents

An agent is an automated tool with its own identity in an organization, shown as <org>/<name> in pushes, live edits, checkpoints and the audit log. Owners of the organization create agents under Settings, Agents (it needs a recent passkey confirmation). An agent never signs in and cannot administer anything.

• Tokens start with dga_. Each works only on the repositories you list for it, and can be limited per repository to ref patterns such as refs/heads/agent/* (* matches within one part of a ref, ** across parts). Without patterns it may push wherever its role allows.
• Scopes: repo:read, repo:write, actions:read, actions:write, statuses:write, live:read, live:write and sandbox:write. An agent works in its own sandboxes whatever its ref patterns say.
• Each agent has its own limits (live edits a second and a day, pushes an hour, API requests a minute, open live sessions, sandboxes, Actions minutes and egress), which an owner can raise up to the plan's ceiling. The agent cannot change them.
• Disabling an agent stops its writes at once, closes its live connections, revokes every token and cancels its running jobs. Revoking one token leaves the agent's other tokens working. Nothing else in the organization changes.

Give an agent its token in REBASELY_TOKEN, never your own. rebasely agent init adds the Rebasely agent skill to a repository, which tells coding agents to use one sandbox and one git worktree per task.

rebasely mount

Mount a live branch to edit it in any editor. The sync daemon watches the directory, sends each save as a change and writes other people's changes into your files.

rebasely mount feature/login ~/code/app     # sync in the foreground; Ctrl-C stops it, the mount stays
rebasely mount feature/login --daemon       # run the daemon in the background
rebasely mount my-idea --create             # create the branch from the default branch and turn live on
rebasely mounts                             # every mount and its state
rebasely unmount feature/login              # stop syncing and remove the mount
rebasely mount gc                           # remove stale mounts that have nothing unsent

• Every mount lives under ~/.rebasely (or $REBASELY_HOME; an existing ~/.duragit keeps being used): one shared object store per repository and one git worktree per branch, so a second branch of the same repository mounts without a fresh clone. The path you give is a symlink to the mount.
• --adopt takes an existing clone at that path: its uncommitted changes are sent as edits, and the clone is moved aside, never deleted.
• Offline, saves wait in a queue and are sent when the connection comes back. When your change and someone else's touch the same lines, the file gets their version and yours is kept as <file>.duragit-conflict-<date-time>, with a notice in the terminal. A local edit is never dropped silently.
• More than 200 files changed within 2 seconds (a checkout, a formatter) pause sending and ask first; --burst send or --burst hold answers in advance.
• Ignored: .git, whatever .gitignore excludes, the repository's ignored patterns and editor temporary files.
• The daemon keeps origin/<branch> at the latest checkpoint, so git diff origin/<branch> shows what is not committed yet. It never moves your local branch or the index.
• rebasely unmount keeps a mount with unsent edits until they are delivered; --discard drops them.

The credential is REBASELY_TOKEN, or the token rebasely auth login stored for git (it asks for live:read and live:write by default).

rebasely mcp and the MCP server

Agents that speak the Model Context Protocol use Rebasely's tools directly. Either run the local proxy, which uses the credential the CLI has:

rebasely mcp                                # a stdio MCP server; --host staging|production|<url>

or point the agent's MCP client at https://rebasely.com/mcp (Streamable HTTP) with the header Authorization: Bearer dga_... (an agent token) or dgp_... (a personal token). Tokens are accepted in that header only, never in the URL.

A private repository the token cannot reach gets the same answer as one that does not exist.