Cloud sessions

How to put fibers on a cloud session. A cloud session starts on a brand new machine every time, so the fibers you installed on your computer isn’t there. Something has to install fibers as the machine boots, and on Claude Code on the web that something goes in the environment’s Setup script box.

Setting up an environment

Each environment is set up once, by hand, in its settings. There are three parts.

Setup script. Paste these two lines, first in the box if it has other steps:

echo "fibers: install line v1"
curl -fsSL https://fibers.dev/install.sh | sh || echo "fibers: install failed"

The installer puts the fibers command where any agent can run it, and when Claude Code is there it also installs the fibers plugin: its hooks (small scripts Claude Code runs at set moments, such as session start) and its skills (instructions Claude can load for fibers tasks). It’s written to finish successfully even when the install doesn’t complete, so it can’t stop a session starting. Put it first because an earlier step that fails can end the script before it gets here.

The first line is a marker. Claude Code on the web keeps a setup script that ran successfully and reuses it, running it again only when its text changes. If you need it to run afresh, change v1 to v2.

Variables. Two of them:

• FIBERS_API_TOKEN. The board’s token for this environment. The workspace owner creates one per environment, so a leaked token can be revoked without touching the others.
• NODE_USE_ENV_PROXY=1. Lets the plugin reach the board through the sandbox’s proxy.

Allow-list. Three hosts. The first serves the installer; the other two are the board’s service, and it needs both.

fibers.dev
charming-swordfish-323.eu-west-1.convex.cloud
charming-swordfish-323.eu-west-1.convex.site

Other sandboxes

The same two lines work in any sandbox’s setup step, such as the script Blocks runs after it clones a repo. The sandbox needs curl and Node 20 or newer, and ~/.local/bin on the agent’s PATH: the installer puts fibers there but can’t add that folder to the PATH itself. Sandboxes that run their setup on every boot pick up a newer installer by themselves, so the marker matters less there. Agents other than Claude can still run fibers commands; only Claude sessions get the hooks and skills.

What a cloud session gets

The fibers command, the session hooks and the fibers skills, all from the latest release. Claiming, logging and releasing work is the reliable part. Live presence on the board is best-effort, because some heartbeats don’t make it through the sandbox’s proxy. Every session in one environment appears under that environment’s token name, so two people sharing an environment look the same on the board.

Inviting a second developer

Access to a workspace is a grant on a person, and the workspace owner mints it from the web app. No invitation email goes out and there’s no step to accept: the grant exists the moment the address is added, and the other person claims it by signing in with that address.

1. Owner: open the workspace’s Members page (/w/<slug>/workspace/members), enter the other person’s email, and press Add member. The page then shows the two commands below, ready to send.
2. The other person, on their machine, in the repo they will work in:

fibers login   # once per machine: signs in via browser with the address that was added
fibers init --workspace <slug>   # in the repo root: binds the checkout to the workspace

fibers login opens the browser; the sign-in has to be with the same email address the owner added, because that address is what binds the sign-in to the grant. Until they sign in, the Members page lists them as not signed in yet. Removing someone on the same page revokes their membership: their personal sign-in no longer reaches the workspace. A workspace token they created with fibers init is a separate credential, and it keeps working until it is revoked on its own. Removing a member doesn’t yet revoke their tokens; that’s still to be built.

If something is off

Ask the cloud session to run fibers doctor. It says which part is missing. Without it, fibers work ls failing with service unreachable twice in a row means the allow-list, and a 401 (the service not accepting the token) means the token. If fibers isn’t found at all, look in the setup log for a curl error or a line starting fibers:, which names what’s missing (Node, for example). Fix that, then change the marker so the setup runs again.