A drive is your team's shared workspace: the repo, the environment, and the agent sessions. It runs wherever you choose and connects out to coshell.ai over one authenticated tunnel. This guide covers every way to set one up and keep it running.
$ curl -fsSL https://coshell.ai/install | bash $ coshell host initYour own laptop is a drive too. Teammates reach it through the tunnel while it is awake, and the doctor warns you before the machine would sleep on them.Waiting for the first command
$ curl -fsSL https://coshell.ai/install | bash $ coshell host initThe Mac under the desk becomes a drive for the whole team. A launchd agent keeps it running and reconnects after a reboot.Waiting for the first command
#cloud-config
runcmd:
- curl -fsSL https://coshell.ai/install | bash
- coshell host initDigitalOcean, Hetzner, Vultr, Linode, or anything that takes cloud-init. Paste one file into the machine’s user data.Waiting for the first commandSelf-hosting works on macOS and Linux, arm64 or x64. Windows runs the CLI inside WSL. The machine needs outbound internet and, if it is a laptop, a reason to stay awake while teammates are using it.
coshell signup, which creates the account, names the org, and enrolls the machine you are on as your first drive in one go.Two commands. The first installs the CLI, the second enrolls this machine as a drive, asks how you want it installed, and prints the drive name when it is online.
One line on macOS and Linux. On Windows, run it inside WSL.
Signs you in if you are not already, then registers this machine as a drive. Pick system-wide unless you want the drive inside a container: the wizard detects your container runtime and recommends resources.
The drive shows up in the browser at coshell.ai/app for everyone on your org, and coshell attach opens the same drive from any terminal.
Already signed up on another machine? coshell host init on the new one adds it as another drive. Every drive has its own name, its own sessions, and its own access list.
The same drive, provisioned by the provider instead of by hand. The template asks for an enroll token and nothing else. The token is never put in a link: you paste it into the provider's own environment-variable prompt as COSHELL_ENROLL_TOKEN.
Drives deployed from a cloud template receive runtime updates automatically. You do not need to redeploy.
The drive listens on 127.0.0.1 only and reaches the edge over an outbound WebSocket that it holds open with reconnect and backoff. The edge authenticates every request, injects who you are, and forwards it down the tunnel. The drive never trusts a client directly, so attribution and access cannot be spoofed from a laptop.
Enrollment installs a background service: a launchd LaunchAgent on macOS, a systemd user unit on Linux. It starts at login, survives reboots, keeps the connection through idle periods, and reconnects when the host wakes.
| coshell host status | Is the drive online, which port it bound, and when the tunnel last connected. |
| coshell host doctor | Checks the machine for common problems. On a Mac it warns when the machine will sleep and disconnect the drive; sudo pmset -a sleep 0 keeps it awake while hosting. |
| coshell host logs | Tails the drive's log. |
| coshell host update | Updates the drive runtime in place. Cloud templates do this on their own. |
| coshell host restart | Restarts the service. |
| coshell host stats | Size, compute, and disk for this drive, and a warning when the machine has less than the recommended resources. |
| coshell host unenroll | Removes this machine as a drive and revokes its secret. |
A drive is happy on a modest machine. The runtime is a single compiled binary, and the agent's own work is whatever your project needs: a dev server, tests, a browser preview. Manage Drive in the app shows the drive's size, compute, and disk, and warns when a machine has less than recommended.
Requests from the browser or the CLI go through the edge to reach the drive, and responses come back the same way. The edge authenticates and forwards; the drive holds the repo, the environment, and the sessions. On the Enterprise tier, Coshell runs on your own infrastructure end to end.
Yes. Run coshell host init on each machine. Teams usually keep a drive per project or per client, and each has its own sessions, access list, and model settings.
Sessions pause. Nothing is lost: the drive keeps its state on disk, the service reconnects when the machine is back, and teammates resume the same session.
Yes. Choose containerized during coshell host init. The wizard detects your container runtime and recommends resources. The container publishes no ports and mounts no host paths.
Enroll the new machine, push your work through git as usual, and unenroll the old one. Sessions are per drive, so treat a move as a new drive rather than a migration.
Install the CLI, run coshell host init, and the drive is online for everyone on your org.