fctl is an open source software factory for Claude Code: agents work in sandboxes on machines you own, around the clock, on your Claude subscription. You describe the work and follow along live from the web app, your terminal or the Claude apps, and anyone you share a project with can steer the agents too.
fctl's code is on GitHub, MIT licensed: hyperstructure/fctl has all of it, from the control plane to the CLI. app.fctl.sh is a managed control plane that hyperstructure runs, by invitation or early access; you can also host every part of fctl yourself, on a machine of yours or on Cloudflare (self-hosting). Either way, the agents run on your machines.
Three pieces make up a factory:
- The control plane — a Worker with Durable Objects and D1
that serves the web app and the API, keeps every session's event log, and
hands work to runners. One per team (yours might be
app.fctl.sh). It runs on Cloudflare, or in one container on any machine or Kubernetes cluster. - Runners — your machines (a spare Mac is ideal). On each, the
fctl hostservice connects out to the control plane and runs each session in its own Linux VM. - Clients — the web app, the
fctlCLI, and the Claude apps on your phone and desktop through Remote Control.
| If you want to… | Read |
|---|---|
| Start using fctl on an instance someone set up | Getting started |
| Drive everything from a terminal or a script | The CLI |
| Hand work to fctl from an agent or a program, and wait for it | fctl for agents |
| Call fctl's API from your own tools | The HTTP API |
| Run agents from CI or a bot, such as review agents on your pull requests | Automation |
| Run your own instance, on a machine of yours or on Cloudflare | Self-hosting |
| Know what sessions run in, give a project its own image, or choose the images a host runs | Sandbox images |
| Understand how the pieces talk to each other | Architecture |
| Know what fctl does with your credentials | Security |
| Work on fctl itself | Development |
Agents find all of this summed up in llms.txt, at
https://fctl.sh/llms.txt and at /llms.txt of every instance: what fctl
is, its words, how to drive it safely and where the details are. Each page
here is also at https://fctl.sh/docs/<page>.md as Markdown, and all of
them are in https://fctl.sh/llms-full.txt.
- Project — a repository plus what agents need to know to work in it (setup script, instructions, model, secrets). Projects have members.
- Session — one agent working on one task: one Claude conversation in
one sandbox, on its own branch. Sessions are numbered per project
(
my-app#12). Its agent pushes, comments, triages or only reads on GitHub. - Access token — a token for scripts, CI and bots, which can be limited to reading or running sessions, to some projects, and in what its sessions' agents may do on GitHub.
- Memory — a project's notes for its agents: what earlier agents and people learned that the repository doesn't say. Each session's agent starts with them.
- Retrospective — what an agent records as it finishes a piece of work: how it ended, what it worked on, the approach it took, what got in the way and what a future agent should know. One for each piece of work: the agent updates it as later turns carry on with that work.
- Runner — a machine that runs sessions: a Mac or Linux machine with
the
fctl hostservice on it, registered with the control plane. It runs several sessions at once, each in a sandbox of its own, for every workspace it's added to. A workspace's Runners tab, andfctl runnersfrom any machine, list and manage them. - Host — the
fctl hostservice, the software that makes a machine a runner: it connects to the control plane, makes a sandbox for each of the runner's sessions and starts its agent there.fctl hostcommands (install,status,drain) act on the machine you run them on. One machine runs one host and is one runner: "host" names the software on the machine, "runner" the machine as fctl and your workspaces see it. - Agent Floor — the web app's home page, where it opens: the box for your next task, and every active session as a thread of light.