# Rift documentation > If you are an AI agent, read https://rift.sh/setup.md first, then https://rift.sh/skill.md. --- title: Get started source: https://rift.sh/docs --- # Get started Install Rift, create a key and share a folder. ## Install ``` $ curl -fsSL https://rift.sh/install | sh ✓ installed rift 0.1.0 to ~/.local/bin ``` One binary for macOS and Linux. A background process starts the first time you run a command and handles sync from then on. ## Create your key ``` $ rift init ✓ created a key for this machine ed25519:7f3a91c0…3a4b5c ✓ folder at ~/rift ``` `rift init` makes this machine's key and a folder, `~/rift`. Everything in that folder is an ordinary file. `rift id` prints the full public key, which is what a coworker needs to share a folder with you. There is no account to create. The private key never leaves this machine. No one can reset it. If you lose it, you lose access to every folder shared with that key. ## Share your first folder Alice makes a folder, puts a file in it, and shares it with Bob's key. ``` # alice $ mkdir ~/rift/team $ cp notes.md ~/rift/team/ $ rift peer add ed25519:c4d5e6f7…b3c4d5 --alias bob ✓ saved bob $ rift share team bob ✓ shared team with bob · write ``` Bob's machine already has the folder. He ran no command to receive it. ``` # bob $ ls ~/rift/team notes.md $ cat ~/rift/team/notes.md ship friday $ cp reply.md ~/rift/team/ ``` `reply.md` appears in Alice's folder without either of them running a sync command. Next: [roles and subfolders](https://rift.sh/docs/sharing.md), or [adding an agent](https://rift.sh/docs/guides.md#agents). --- title: For agents source: https://rift.sh/docs/agents --- # For agents This page is written for an agent that has been asked to use Rift. It is the procedure in order. ## Reading these docs Every page is available as Markdown at the same address with `.md` added. [/llms.txt](https://rift.sh/llms.txt) lists every page, and [/llms-full.txt](https://rift.sh/llms-full.txt) holds the docs in one file. [/setup.md](https://rift.sh/setup.md) is this procedure written as steps for an agent to follow, with the point at which to stop and ask. It covers the setup steps of the [prompt](https://rift.sh/index.md#agent) on the home page, and adds the verify step, the skill and a report. [/skill.md](https://rift.sh/skill.md) is the Rift skill, with the commands and the mistakes to avoid. ## Install and join Run `rift status` first and read its first line. If it says `joined as`, this machine already joined with an invite. Do not run `rift init` and do not use a token. If you were given one, tell the person it was not used and which name this machine joined as. Then go on to Work in a shared folder. If it shows a key that starts `ed25519:` and no `joined as`, the machine's owner set it up and you are working with their key. With no token, go on to Work in a shared folder. If it shows a key and you have a token and a directory from the person, run `rift init --invite --home `, add `--home ` to every `rift` command, and go on to Work in a shared folder. The folder to use is the one `rift status --home ` prints, in place of `~/rift`. If it shows a key and you have a token and no directory, stop and tell the person that this machine already uses their key, that you can see every folder in `~/rift`, and that the token is unused. If they give you a directory, do as above. If they tell you to keep working with their key, do not use the token, and go on to Work in a shared folder. If the command is not found, run `~/.local/bin/rift status`. If it answers, read its first line by the rules above and call the binary by that path from here on. If it is not found there either, install Rift and then join. If Rift is found and prints no folder, skip the install and join with an invite token. Use `RIFT_INVITE` if it is set. If you have no token, stop and ask the person you work for to run `rift invite ` and send you the token it prints. Run `rift init --invite ` once. ``` $ curl -fsSL https://rift.sh/install | sh ✓ installed rift 0.1.0 to ~/.local/bin $ rift init --invite ✓ created a key for this machine ed25519:a1b2c3d4…f0a1b2 ✓ joined as coder ✓ folder at ~/rift ``` ## Work in a shared folder Keep your work inside a folder that `rift ls` lists. Those are the folders shared with you. Everything in them is an ordinary file, so read and write it with the tools you already use. Files you write there reach the person's machines without any further command. A folder it lists as `work/` is at `~/rift/work`. A folder you make yourself under `~/rift` stays private to this machine. If `rift ls` lists no folder, ask the person which folder to use. ## Ask for a folder you cannot see Say which folder and why. A request asks for read access. The person approves or declines from any of their machines. ``` $ rift request work --reason "To re-run the tests with your fix" ✓ asked for work · waiting for approval ``` When the person approves, the folder appears in `rift ls`. Tell the person you asked, carry on with work that does not need the folder, and check `rift ls` again before you use it. If nothing is left that you can do without it, stop and tell the person what you asked for. Do not look for another way to reach the folder. ## Get a file from another agent ``` $ rift ask hermes "the latest report" ✓ received report.pdf from hermes ``` The file arrives in a folder that is shared with you. Run `rift ls` to find it. ## Check that you are in sync ``` # is this machine joined and in sync $ rift status ✓ joined as coder · in sync folder at ~/rift # what you can see $ rift ls work/ ``` If a command fails, read its message and report it as it is. Do not delete Rift's folder or its key to start again, because that removes this machine's identity. ## Install the skill An agent that supports Agent Skills installs the Rift skill with one command. Ask the person before you install it. ``` $ npx -y skills add https://rift.sh -g -y ``` This step needs Node. On a machine that has none, read the skill once in its place. --- title: Use Rift with your agent source: https://rift.sh/docs/use-with --- # Use Rift with your agent Rift needs an agent with a shell, a network connection and a disk that lasts as long as its work. Setup is the same for most agent products. Give the agent the [prompt](https://rift.sh/index.md#agent) with an invite token. Each product keeps a standing instruction in a different place, and each sandbox allows different things. An agent that runs as you on a machine where you already use Rift works with your key and sees every folder in `~/rift`. To give it a key of its own, make an invite and tell the agent to join with `rift init --invite --home ` and to add `--home ` to every `rift` command. `` is a directory you choose for that agent. If you paste the prompt on such a machine and name no directory, the agent stops, tells you it would be working with your key, and waits for you to choose. The standing instruction is short. ``` Keep your work inside a folder that rift ls lists. A folder it lists as work/ is at ~/rift/work. To reach a folder you cannot see, run rift request --reason "". ``` For an agent that joined with `--home `, the same line carries the directory. ``` Keep your work inside a folder that rift ls --home lists, under the folder that rift status --home prints. To reach a folder you cannot see, run rift request --reason "" --home . ``` ## Claude Code Paste the prompt into a session. Put the standing instruction in `CLAUDE.md` in the project, or in `~/.claude/CLAUDE.md` to apply it to every project on that machine. `~/rift` is outside the project, so start Claude Code with `--add-dir ~/rift` or approve the access when it asks. Written from [memory files](https://code.claude.com/docs/en/memory), read in October 2026. ## Codex These steps are for Codex on your own machine. Codex in the cloud is not covered. Codex runs commands in a sandbox whose default mode has no network access and writes only inside the project and temporary folders. Install Rift and run `rift init` yourself, outside Codex, because the installer needs the network and writes outside the project. Codex then works with your key. Then allow network access and add `~/rift` as a writable folder, and put the standing instruction in `AGENTS.md` in the project. Written from [sandboxing](https://learn.chatgpt.com/docs/sandboxing) , [approvals and security](https://learn.chatgpt.com/docs/agent-approvals-security) , [AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md), read in October 2026. ## OpenClaw OpenClaw runs on your own machine and runs commands on that machine by default, so the prompt needs no changes. Put the standing instruction in `~/.openclaw/workspace/AGENTS.md`, which it loads at the start of every session. Written from [running commands](https://docs.openclaw.ai/tools/exec) , [the workspace](https://docs.openclaw.ai/concepts/agent-workspace), read in October 2026. ## Grok Bot Your account has one cloud computer with a command line, and every Bot on it uses that computer. The computer hibernates when idle. xAI treats packages you install by hand as replaceable, so Rift may need installing again after an update. xAI advises against pasting passwords or one-time codes into chat. Its pages describe taking control of the computer for a sensitive step and do not say whether you can type commands there. If you can, run the install and the join from the prompt yourself. If you cannot, paste the prompt with the token, and make that invite under a name you use for nothing else. Put the standing instruction in the Bot's description, under Edit Profile, which is where xAI says rules that should stay true belong. Because your Bots share one computer, they share one Rift key and one `~/rift` folder. Share a folder with that key only if every Bot on the account may read it. A Team Bot that answers in Slack channels runs on a different computer and needs its own invite. Written from [the computer](https://docs.x.ai/grok-bot/computer-and-apps) , [security](https://docs.x.ai/grok-bot/security) , [Bots](https://docs.x.ai/grok-bot/bots) , [Team Bots](https://docs.x.ai/grok-bot/team-bots), read in October 2026. ## Buzz Buzz is a workspace of channels that people and agents share. An agent in it is Claude Code, Codex, goose or another agent that speaks the Agent Client Protocol, running on the machine where you started it. Set Rift up on that machine, or send the prompt to the agent as a Buzz message. The standing instruction goes in that agent's own instruction file. Agents that run as the same user on one machine share one Rift key and one folder. Written from [Block's repository](https://github.com/block/buzz) , [Block's announcement](https://engineering.block.xyz/blog/buzz), read in October 2026. ## dots A dot can work on a computer of yours that you connect to it. Install Rift on that computer first, connect it from the dot's profile, and tell the dot to keep its work in a folder under `~/rift` there. The computer has to stay online with the ChatGPT app open while the dot uses it, and a dot connects to one personal computer at a time. In a workspace, an owner has to allow local computer access. A dot also has a cloud computer of its own. In a workspace, an owner has to allow cloud computer use and cloud network access. OpenAI's pages do not say whether Rift's installer runs there. They say only that the computer can keep its state between uses. OpenAI's pages say to give a preference like this one in conversation. Custom rules, in settings, only control when a dot may take an action. So tell the dot the instruction, ask it to save it to its notes, and ask it to repeat what it saved. Written from [dots](https://learn.chatgpt.com/docs/dots) , [computers and apps](https://learn.chatgpt.com/docs/dots/computers-and-apps) , [controls](https://learn.chatgpt.com/docs/dots/controls) , [admin guide](https://learn.chatgpt.com/docs/enterprise/dots-admin-guide), read in October 2026. ## Claude Tag Claude Tag runs each Slack thread in a new sandbox that is released a few minutes after the reply. Its network goes through a proxy that carries HTTP and HTTPS only, to hosts on an allowlist. Rift's traffic between machines is not HTTP, so it cannot cross that proxy, and a key made in the sandbox is gone a few minutes after the reply. There are two ways to use them together. - Run Claude Tag's sessions on a self-hosted environment, with Rift installed in the runner's image and the runner's own network. Keep Rift's key on a volume that outlasts the runner, because a runner can restart with a fresh disk. Claude Tag cannot use Access bundles in self-hosted sessions yet. - Keep Rift on a second agent on a machine of yours, and have it pick up what Claude Tag posts or pushes. Written from [how it works](https://claude.com/docs/claude-tag/concepts/how-it-works) , [agent identity](https://claude.com/docs/claude-tag/concepts/agent-identity) , [self-hosted environments](https://code.claude.com/docs/en/self-hosted-environments), read in October 2026. ## With other tools Guides for using Rift beside a sandbox, a memory service, a protocol or another tool. - [E2B](https://rift.sh/docs/use-with/e2b.md) - [Daytona](https://rift.sh/docs/use-with/daytona.md) - [Modal](https://rift.sh/docs/use-with/modal.md) - [Sprites](https://rift.sh/docs/use-with/sprites.md) - [Vercel Sandbox](https://rift.sh/docs/use-with/vercel-sandbox.md) - [Mem0](https://rift.sh/docs/use-with/mem0.md) - [Supermemory](https://rift.sh/docs/use-with/supermemory.md) - [Zep](https://rift.sh/docs/use-with/zep.md) - [Rivet Actors](https://rift.sh/docs/use-with/rivet-actors.md) - [MCP](https://rift.sh/docs/use-with/mcp.md) - [A2A](https://rift.sh/docs/use-with/a2a.md) - [ANP](https://rift.sh/docs/use-with/anp.md) - [SLIM](https://rift.sh/docs/use-with/slim.md) - [Tailscale](https://rift.sh/docs/use-with/tailscale.md) - [GitHub](https://rift.sh/docs/use-with/github.md) --- title: Files source: https://rift.sh/docs/files --- # Files Rift keeps your files in one folder, `~/rift`. Make folders and files in it with the tools you already use. Every file is encrypted before it leaves your machine. ## Folders ``` $ mkdir ~/rift/team $ cp notes.md ~/rift/team/ $ ls ~/rift team ``` A folder is private until you share it. ## Add, list, read ``` $ cp -r src ~/rift/team/ $ ls ~/rift/team notes.md src $ cat ~/rift/team/notes.md ship friday ``` Your own machines download every file as it arrives, except a file offloaded to Rift Cloud, which downloads when it is opened. A machine a folder was shared with can list a file before it has the contents, and downloads it the first time something opens it. `rift add`, `rift cat` and `rift get` do the same jobs for a script that works outside the folder. ## Move ``` $ mv ~/rift/team/notes.md ~/rift/team/archive/ $ rift mv team/draft.md public/launch.md ! readers change - bob write + carol read ? move team/draft.md to public/launch.md? y/N ``` Moving a file within a shared folder renames it for everyone. Moving it to a folder with different members changes who can read it. `rift mv` lists those changes and asks you to confirm. A plain `mv` between two such folders makes the same change without asking. Neither move uploads the file again. ## Copy ``` $ rift cp team/weights/run-14.safetensors experiments/run-14.safetensors ✓ copied to experiments/run-14.safetensors 41.8 GB, 0 B uploaded ``` `rift cp` makes a new file without uploading its contents again. Editing one copy afterwards does not change the other. --- title: Sharing source: https://rift.sh/docs/sharing --- # Sharing Share a folder with a key, choose a role and remove access when you need to. ## Share a folder Sharing takes a path, a key and a role. The other machine starts syncing that folder immediately, and nothing else on your machine is visible to it. Bob can edit team. The agent can read it. Neither sees Alice's private folder. ``` $ rift share team bob ✓ shared team with bob · write $ rift share team agent --read ✓ shared team with agent · read $ rift members team alice admin you bob write agent read ``` `bob` and `agent` are aliases Alice saved with `rift peer add`. Aliases exist only on her machine. A full public key works in place of an alias. ## Roles | Role | List and read | Add, edit, move, delete | Share and remove access | | --- | --- | --- | --- | | read | yes | no | no | | write | yes | yes | no | | admin | yes | yes | yes | `write` is the default. Every machine rejects an edit signed by a `read` key. ## Share a subfolder Share `team/docs` with Carol, a contractor, and her machine syncs that subfolder only. Nothing else in `team` reaches her machine, including file names. Bob has the whole folder. Carol has one subfolder of it. ``` $ rift share team/docs carol ✓ shared team/docs with carol · write $ rift members team/docs alice admin you bob write from team carol write ``` Everyone with access to `team` keeps access to `team/docs`. A subfolder share only adds members. ## Restrict a path `--exclusive` limits a path to the keys you name. Members of the parent folder lose access to it. Here Alice shares `.env` with her agent, and Bob can no longer read it. Bob keeps any copy his machine already downloaded, so replace the secrets in it. Bob sees that .env exists. New versions are encrypted with a key he was never sent. ``` $ rift share project-a/.env agent --read --exclusive ✓ shared project-a/.env with agent · read ! bob no longer has access to project-a/.env # bob $ rift cat project-a/.env ✗ permission denied project-a/.env is restricted to 2 keys ``` ## Remove access Bob stops receiving changes. Files he already downloaded stay on his disk. ``` $ rift unshare team bob ✓ removed bob from team · new key $ rift members team alice admin you agent read ``` After `rift unshare`, Bob cannot read anything new in `team`, and the other machines reject any change he sends. The folder gets a new key, and the remaining members receive it. Removing access does not delete files Bob already downloaded. If one held a secret, replace that secret. Moving a file to a folder with different members changes who can read it. See [Move](https://rift.sh/docs/files.md#move). --- title: Guides source: https://rift.sh/docs/guides --- # Guides Worked examples for agents, short-lived runs, deploy machines, media servers and Rift Cloud. ## Add an agent On your laptop, run `rift invite` with a name for the agent. It prints a token. Give the token to the agent, which installs Rift and joins with it. Then share the folders the agent needs. ``` # your laptop $ rift invite coder ✓ invite for coder rift_4f1c…9a2e # where the agent runs $ rift init --invite rift_4f1c…9a2e ✓ created a key for this machine ed25519:a1b2c3d4…f0a1b2 ✓ joined as coder ✓ folder at ~/rift # your laptop $ rift share project-a coder ✓ shared project-a with coder · write ``` The agent works in `~/rift/project-a`, and everything in it is an ordinary file. Its machine now has `project-a` and nothing else from your machine. Your SSH keys and the rest of your home directory were never sent, so no prompt or tool call can reach them. ## A coder and a reviewer The coder edits the project. The reviewer reads all of it and can write only to `reviews`, so a review can never change the code it is reviewing. Two agents on the same project with different roles. The reviewer's edits outside reviews are rejected by every machine. ``` $ rift share project-a reviewer --read ✓ shared project-a with reviewer · read $ rift share project-a/reviews reviewer ✓ shared project-a/reviews with reviewer · write ``` ## Short-lived runs Give each run its own invite and remove its access when the run ends. If the run's key leaks later, it has no access to any folder. ``` # your machine $ rift invite run-481 ✓ invite for run-481 rift_8c2e…41d7 $ rift share project-a run-481 ✓ shared project-a with run-481 · write # the run finishes $ rift unshare project-a run-481 ✓ removed run-481 from project-a · new key ``` ## Deploy from a folder ``` $ rift share website/dist deploy --read ✓ shared website/dist with deploy · read ``` The deploy machine receives `website/dist` each time you build and publishes from it. It has no source code and no secrets, and it cannot change the folder. Remove its access to stop deploys. ## Media servers Alice's server gets the whole library, as write. Her friend's server gets movies, as read. ``` $ rift share media mediaserver ✓ shared media with mediaserver · write $ rift share media/movies friend --read ✓ shared media/movies with friend · read ``` The friend's server downloads a movie the first time the friend plays it. ## Rift Cloud Rift Cloud is storage on the Sia network. Connect a Sia account and Rift uploads every file this machine can read, in the background. ``` $ rift sia init approve this machine in your browser ✓ storage connected $ rift sia status stored 1,204 files 38.2 GB uploading 3 files 212.0 MB retrying 0 files ``` Each file is encrypted before it leaves the machine. The storage hosts see ciphertext and file sizes. They cannot see file names, folders or members. The account that connects pays for what it stores. When Bob connects his own account, the files you shared with him are stored a second time under his account. His copy stays if you delete yours. Rift Cloud is optional, and it is the one feature that needs an account, held with a provider on the Sia network. Without it, a file can be fetched only while a machine that has it is online. --- title: Commands source: https://rift.sh/docs/commands --- # Commands Every Rift command, grouped by what it does. Every command accepts `--json` for scripts and agents, and `--home ` to use a second key on one machine. ## This machine - `rift init`: Create this machine's key and its folder - `rift id`: Print the public key - `rift status`: Show sync and connection state - `rift stop`: Stop the background process - `rift sync `: Sync with every member now, which normally happens automatically ## Files - `rift mkdir `: Create a folder - `rift ls [path]`: List folders, or the names inside one, without downloading - `rift add `: Add local files, or a directory with `-r` - `rift cat `: Print a file - `rift get `: Save a file to a local path - `rift mv `: Move or rename, asking first if the move changes who can read the file - `rift cp `: Copy without uploading the bytes again - `rift rm `: Remove a file, which stays in the trash for 30 days - `rift trash `: List removed files that can be restored - `rift restore `: Restore a removed file - `rift rmdir `: Leave a folder and delete the local copy ## Sharing - `rift peer add --alias `: Save a key under an alias only you see - `rift peer ls`: List saved keys and whether each is connected - `rift share `: Grant write, the default - `rift share --read`: Grant list and download only - `rift share --admin`: Grant write, plus share and remove access - `rift share --exclusive`: Limit a path to the listed keys - `rift unshare `: Remove access - `rift members `: List who has access and at what role ## Agents - `rift invite `: Print a token an agent uses to join under that name - `rift init --invite `: Create a key and join with a token - `rift request --reason `: Ask for read access to a folder - `rift requests`: List the requests waiting for you - `rift approve `: Approve a request - `rift decline `: Decline a request - `rift ask `: Ask another agent for a file ## Rift Cloud - `rift sia init`: Connect a Sia account to this machine - `rift sia status`: Show stored files, uploads in progress and retries - `rift sia clear`: Disconnect Rift Cloud and keep local files --- title: What is Rift? source: https://rift.sh/docs/what-is-rift --- # What is Rift? Rift is an end-to-end encrypted filesystem that you share one folder at a time. You share a folder with a machine's public key, and that machine receives that folder and nothing else. A coding agent in a cloud sandbox needs one folder of your work. Today you give it a git token, an SSH key or the login to a synced drive, and each of those opens more than the one folder the agent needed. A coworker's laptop, a deploy machine, and a second agent that reviews the first all have the same need. ### Permissions are local to one machine Agent tools add allow rules, deny rules and prompts before an edit. The agent's own harness enforces them for one session on one machine. The rules cover files the agent can already reach, and none of them controls which files are sent to that machine. ### Sharing controls what syncs `rift share project-a coder` gives the coder write access to one folder, and that folder starts syncing to the coder's machine. Every machine has its own key. Your laptop and your desktop each have a key, and a folder shared with you reaches both. A machine receives only the folders shared with it. The reviewer below can read the project and cannot change it. Every other machine rejects any change the reviewer signs. Two agents share one project. The coder can edit it. The reviewer can only read it. A deploy machine that was given `website/dist` cannot leak your source, because your source was never sent to it. ``` $ rift share project-a coder $ rift share project-a reviewer --read $ rift share website/dist deploy --read ``` ### Share across companies A key is tied to no company's login, so the same command works across companies. Your agent and a client's agent can work in one folder without either side creating accounts on the other's systems. A contractor gets `team/docs` for the length of the contract and nothing else in `team`. On the last day you run `rift unshare`, and every machine the contractor used loses access. ### Transfer and Rift Cloud Files move directly between machines, encrypted end to end. Connect Rift Cloud and every file is also stored there, so a folder stays available when the other machine is offline. It holds only ciphertext. ### What removing access does After `rift unshare`, the removed member cannot read anything new in the folder from any of their machines. The remaining machines reject every change those machines send. After access is removed, the reviewer receives nothing new. What it already downloaded stays on its disk. Removing access does not erase files a machine already downloaded. A machine that has a file can keep a copy of it. Replace any secret that was in a folder you removed access to. [Install Rift](https://rift.sh/docs.md), or read [the six jobs of file sync](https://rift.sh/blog/the-six-jobs-of-file-sync.md). --- title: Use Rift with E2B source: https://rift.sh/docs/use-with/e2b --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with E2B E2B runs the code and Rift keeps the files. Rift runs on Linux, which is what an E2B sandbox runs. ## Set it up On your own machine, make an invite for the sandbox and share the folder the run should write to. ``` $ rift invite e2b-run $ rift share runs/e2b-1 e2b-run ``` Give the sandbox the token as a secret, for example an environment variable named `RIFT_INVITE`. The sandbox needs outbound network access. A sandbox that kept its disk is already joined. Run `rift status` first, and skip the two commands below if it prints a line that contains `folder at`. Otherwise install Rift and join. ``` $ curl -fsSL https://rift.sh/install | sh $ rift init --invite "$RIFT_INVITE" ``` To skip the install on a fresh sandbox, add the first command to the image or template it boots from. Have the agent keep its work in the shared folder. In the sandbox it appears under its own name, at `~/rift/e2b-1`. ## What you get Files the agent writes there reach your machines as they are written. When the sandbox ends, they are still on your machines. A later sandbox that joins and is given the same folder starts with those files. Before the sandbox stops, run `rift status` and wait for `in sync`. A file still uploading when it stops is lost. When the run is over, remove its access. ``` # your machine $ rift unshare runs/e2b-1 e2b-run ``` The token still lets a machine join under that name, with no folders. If it may have leaked, share nothing more with that name and make an invite under a new name. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs E2B](https://rift.sh/compare/rift-vs-e2b.md) --- title: Use Rift with Daytona source: https://rift.sh/docs/use-with/daytona --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Daytona Daytona runs the code and Rift keeps the files. Rift runs on Linux, which is what a Daytona Linux sandbox runs. ## Set it up On your own machine, make an invite for the sandbox and share the folder the run should write to. ``` $ rift invite daytona-run $ rift share runs/daytona-1 daytona-run ``` Give the sandbox the token as a secret, for example an environment variable named `RIFT_INVITE`. The sandbox needs outbound network access. A sandbox that kept its disk is already joined. Run `rift status` first, and skip the two commands below if it prints a line that contains `folder at`. Otherwise install Rift and join. ``` $ curl -fsSL https://rift.sh/install | sh $ rift init --invite "$RIFT_INVITE" ``` To skip the install on a fresh sandbox, add the first command to the image or template it boots from. Have the agent keep its work in the shared folder. In the sandbox it appears under its own name, at `~/rift/daytona-1`. On Tier 1 and Tier 2, Daytona restricts the network and does not let a sandbox change that. Its page on [network limits](https://www.daytona.io/docs/en/network-limits), read in October 2026, lists package registries, git hosts and model providers as reachable and nothing Rift uses, so plan on Tier 3 or higher. ## What you get Files the agent writes there reach your machines as they are written. When the sandbox ends, they are still on your machines. A later sandbox that joins and is given the same folder starts with those files. Before the sandbox stops, run `rift status` and wait for `in sync`. A file still uploading when it stops is lost. When the run is over, remove its access. ``` # your machine $ rift unshare runs/daytona-1 daytona-run ``` The token still lets a machine join under that name, with no folders. If it may have leaked, share nothing more with that name and make an invite under a new name. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Daytona](https://rift.sh/compare/rift-vs-daytona.md) --- title: Use Rift with Modal source: https://rift.sh/docs/use-with/modal --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Modal Modal runs the code and Rift keeps the files. Rift runs on Linux, which is what a Modal container runs. ## Set it up On your own machine, make an invite for the sandbox and share the folder the run should write to. ``` $ rift invite modal-run $ rift share runs/modal-1 modal-run ``` Give the sandbox the token as a secret, for example an environment variable named `RIFT_INVITE`. The sandbox needs outbound network access. A sandbox that kept its disk is already joined. Run `rift status` first, and skip the two commands below if it prints a line that contains `folder at`. Otherwise install Rift and join. ``` $ curl -fsSL https://rift.sh/install | sh $ rift init --invite "$RIFT_INVITE" ``` To skip the install on a fresh sandbox, add the first command to the image or template it boots from. Have the agent keep its work in the shared folder. In the sandbox it appears under its own name, at `~/rift/modal-1`. ## What you get Files the agent writes there reach your machines as they are written. When the sandbox ends, they are still on your machines. A later sandbox that joins and is given the same folder starts with those files. Before the sandbox stops, run `rift status` and wait for `in sync`. A file still uploading when it stops is lost. When the run is over, remove its access. ``` # your machine $ rift unshare runs/modal-1 modal-run ``` The token still lets a machine join under that name, with no folders. If it may have leaked, share nothing more with that name and make an invite under a new name. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Modal](https://rift.sh/compare/rift-vs-modal.md) --- title: Use Rift with Sprites source: https://rift.sh/docs/use-with/sprites --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Sprites A Sprite runs the code and Rift keeps the files. Rift runs on Linux, which is what a Sprite runs. ## Set it up On your own machine, make an invite for the Sprite. ``` $ rift invite sprite ``` A Sprite keeps its disk, so install Rift and join once, inside the Sprite, with the token the invite printed. ``` $ curl -fsSL https://rift.sh/install | sh $ rift init --invite ``` Then share the folder it should write to, and have the agent keep its work in that folder, which appears in the Sprite at `~/rift/sprite-1`. ``` # your machine $ rift share runs/sprite-1 sprite ``` ## What you get Files the agent writes there reach your machines as they are written. A Sprite pauses about 30 seconds after activity stops, and sync stops with it. After a cold wake its processes start fresh, so run `rift status` on waking, or register Rift as a service on the Sprite. Written from Fly.io's page on the [Sprite lifecycle](https://docs.fly.io/sprites/concepts/lifecycle), read in October 2026. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Sprites](https://rift.sh/compare/rift-vs-sprites.md) --- title: Use Rift with Vercel Sandbox source: https://rift.sh/docs/use-with/vercel-sandbox --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Vercel Sandbox Vercel Sandbox runs the code and Rift keeps the files. Rift runs on Linux, which is what the sandbox runs. ## Set it up On your own machine, make an invite for the sandbox and share the folder the run should write to. ``` $ rift invite vercel-sandbox-run $ rift share runs/vercel-sandbox-1 vercel-sandbox-run ``` Give the sandbox the token as a secret, for example an environment variable named `RIFT_INVITE`. The sandbox needs outbound network access. A sandbox that kept its disk is already joined. Run `rift status` first, and skip the two commands below if it prints a line that contains `folder at`. Otherwise install Rift and join. ``` $ curl -fsSL https://rift.sh/install | sh $ rift init --invite "$RIFT_INVITE" ``` To skip the install on a fresh sandbox, add the first command to the image or template it boots from. Have the agent keep its work in the shared folder. In the sandbox it appears under its own name, at `~/rift/vercel-sandbox-1`. ## What you get Files the agent writes there reach your machines as they are written. When the sandbox ends, they are still on your machines. A later sandbox that joins and is given the same folder starts with those files. Before the sandbox stops, run `rift status` and wait for `in sync`. A file still uploading when it stops is lost. When the run is over, remove its access. ``` # your machine $ rift unshare runs/vercel-sandbox-1 vercel-sandbox-run ``` The token still lets a machine join under that name, with no folders. If it may have leaked, share nothing more with that name and make an invite under a new name. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Vercel Sandbox](https://rift.sh/compare/rift-vs-vercel-sandbox.md) --- title: Use Rift with Mem0 source: https://rift.sh/docs/use-with/mem0 --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Mem0 An agent can keep facts in Mem0 and files in Rift. ## Set it up The two need no connection to each other. Keep calling Mem0 for what the agent should remember, and have the agent write its files in a Rift folder that is shared with it. When what the agent should remember is about a file, include the file's path, relative to the shared folder, in what you send to Mem0. That part of the path is the same on every machine that has the folder, so an agent on another machine that recalls the fact can open the file. ## What you get Mem0 holds what the agent has learned. Rift holds the reports, datasets and other files that knowledge refers to, on the agent's own disk and on yours. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Mem0](https://rift.sh/compare/rift-vs-mem0.md) --- title: Use Rift with Supermemory source: https://rift.sh/docs/use-with/supermemory --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Supermemory An agent can keep what it has learned in Supermemory and the files it works on in Rift. ## Set it up The two need no connection to each other. Keep calling Supermemory for what the agent should remember, and have the agent write its files in a Rift folder that is shared with it. When what the agent should remember is about a file, include the file's path, relative to the shared folder, in what you send to Supermemory. That part of the path is the same on every machine that has the folder, so an agent on another machine that recalls the fact can open the file. ## What you get Supermemory holds what the agent has learned. Rift holds the reports, datasets and other files that knowledge refers to, on the agent's own disk and on yours. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Supermemory](https://rift.sh/compare/rift-vs-supermemory.md) --- title: Use Rift with Zep source: https://rift.sh/docs/use-with/zep --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Zep An agent can keep facts in Zep and files in Rift. ## Set it up The two need no connection to each other. Keep calling Zep for what the agent should remember, and have the agent write its files in a Rift folder that is shared with it. When what the agent should remember is about a file, include the file's path, relative to the shared folder, in what you send to Zep. That part of the path is the same on every machine that has the folder, so an agent on another machine that recalls the fact can open the file. ## What you get Zep holds what the agent has learned. Rift holds the reports, datasets and other files that knowledge refers to, on the agent's own disk and on yours. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Zep](https://rift.sh/compare/rift-vs-zep.md) --- title: Use Rift with Rivet Actors source: https://rift.sh/docs/use-with/rivet-actors --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Rivet Actors A Rivet Actor can hold an agent's session state and schedule, and a Rift folder can hold the files it writes, on a worker that runs as a long-lived process on a machine you operate. ## Set it up A serverless worker has no lasting disk and cannot run Rift, so these steps are for a worker on a machine you operate. On your own machine, make an invite for that worker and share the folder it should write to. ``` $ rift invite worker $ rift share runs/worker-1 worker ``` On every machine that runs workers, install Rift and join with the token the invite printed. ``` $ curl -fsSL https://rift.sh/install | sh $ rift init --invite ``` The actor's code reads and writes ordinary files in that folder, which appears on the worker at `~/rift/worker-1`. Keep each file's path, relative to that folder, in the actor's state, and keep the file itself in Rift. ## What you get Rivet Actors keeps the session, its queue and its schedule. Rift keeps the files the session writes, and brings them to your machines and to any other agent you share that folder with. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Rivet Actors](https://rift.sh/compare/rift-vs-rivet-actors.md) --- title: Use Rift with MCP source: https://rift.sh/docs/use-with/mcp --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with MCP An agent can call tools through MCP and keep its files in Rift. ## Set it up Share one Rift folder with the agent and with the machine that runs the MCP server. A tool then returns a path in that folder in place of the bytes. A file server that speaks MCP can also be pointed at `~/rift`, and the agent reaches the same files through its tools. ``` # your machine $ rift invite mcp-server $ rift share handoff hermes $ rift share handoff mcp-server ``` On the machine that runs the MCP server, install Rift and join with the token the invite printed. ## What you get MCP carries the request and the reply. Rift carries the files, encrypted, and only to the agents the folder was shared with. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs MCP](https://rift.sh/compare/rift-vs-mcp.md) --- title: Use Rift with A2A source: https://rift.sh/docs/use-with/a2a --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with A2A One agent can hand another a task over A2A while both keep their files in Rift. ## Set it up Share one Rift folder with both agents, as write for the agent that sends files and read for the one that receives them. The sender writes a file to that folder and sends its path, relative to that folder, over A2A, in place of the bytes. ``` # your machine # save the other agent's key first if it belongs to another owner $ rift peer add ed25519:3e4f5a6b…2d3e4f --alias openclaw $ rift share handoff hermes $ rift share handoff openclaw --read ``` ## What you get A2A carries the request and the reply. Rift carries the files, encrypted, and only to the agents the folder was shared with. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs A2A](https://rift.sh/compare/rift-vs-a2a.md) --- title: Use Rift with ANP source: https://rift.sh/docs/use-with/anp --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with ANP Agents can find and message each other over ANP and keep their files in Rift. ## Set it up Share one Rift folder with both agents, as write for the agent that sends files and read for the one that receives them. The sender writes a file to that folder and sends its path, relative to that folder, over ANP, in place of the bytes. ``` # your machine # save the other agent's key first if it belongs to another owner $ rift peer add ed25519:3e4f5a6b…2d3e4f --alias openclaw $ rift share handoff hermes $ rift share handoff openclaw --read ``` ## What you get ANP carries the request and the reply. Rift carries the files, encrypted, and only to the agents the folder was shared with. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs ANP](https://rift.sh/compare/rift-vs-anp.md) --- title: Use Rift with SLIM source: https://rift.sh/docs/use-with/slim --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with SLIM Agents can talk over SLIM and keep their files in Rift. ## Set it up Share one Rift folder with both agents, as write for the agent that sends files and read for the one that receives them. The sender writes a file to that folder and sends its path, relative to that folder, over SLIM, in place of the bytes. ``` # your machine # save the other agent's key first if it belongs to another owner $ rift peer add ed25519:3e4f5a6b…2d3e4f --alias openclaw $ rift share handoff hermes $ rift share handoff openclaw --read ``` ## What you get SLIM carries the request and the reply. Rift carries the files, encrypted, and only to the agents the folder was shared with. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs SLIM](https://rift.sh/compare/rift-vs-slim.md) --- title: Use Rift with Tailscale source: https://rift.sh/docs/use-with/tailscale --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with Tailscale Tailscale connects machines, and Rift syncs files. ## Set it up The two need no connection to each other. Install Rift on each machine and share folders as usual. ## What you get Your machines reach each other over Tailscale, and each one holds its own copy of the shared folders. The files stay available when the machine that shared them is off. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs Tailscale](https://rift.sh/compare/rift-vs-tailscale.md) --- title: Use Rift with GitHub source: https://rift.sh/docs/use-with/github --- [Use Rift with your agent](https://rift.sh/docs/use-with.md) # Use Rift with GitHub Git holds the source and its history. Rift carries what Git leaves behind, such as reports, datasets, screenshots and video. Git's FAQ says not to use a cloud syncing service on any part of a repository, and that applies to Rift too. ## Set it up Keep the repository where it is, outside `~/rift`. Have the agent write the files Git does not track to a Rift folder. Syncing a repository can corrupt it, as [Git's FAQ](https://git-scm.com/docs/gitfaq), read in October 2026, says. ## What you get Everything a run produces outside the repository is on every machine you use. ## How they differ The comparison says what each one does, who can read your files and when to choose which. [Rift vs GitHub](https://rift.sh/compare/rift-vs-github.md) --- title: Security source: https://rift.sh/security --- # Only the keys you choose can read your files. Rift is encrypted end to end. We do not hold your keys, so we cannot read your files or hand them to anyone else. ## How it works. ### Identity Every machine and every agent makes its own key the first time it runs Rift. There is no account and no password. ### Encryption A file is encrypted on the machine that wrote it, before it leaves. Everything moving between machines is ciphertext, and so is everything in Rift Cloud. ### Access You share a folder, a subfolder or a single file with a key, as read or write. An agent receives what was shared with its key and nothing else from your machine. ### Requests An agent that needs more asks for it and says why. You approve or decline from any of your machines. ### Removal Removing access gives the folder a new key. Nothing written afterwards can be opened with the old key. ### The network Relay servers and storage hosts see IP addresses, public keys, and the size and timing of encrypted traffic. They do not see file contents or file names. ## Limits. A removed agent keeps the files it already downloaded. Agents that run as the same user on one machine can read each other's files. Every machine that receives a folder has to run Rift. Rift has not had an independent security audit. ## Read the details. [Sharing docs](https://rift.sh/docs/sharing.md) [Privacy policy](https://rift.sh/privacy.md)