Projects & setup
Create a project from a repo, a folder, or nothing — then watch the sandbox configure itself and prove it runs.
A project is a git repo. It's the top-level unit: every thread inside it gets a sandbox cloned from that repo, and all work lands as branches and pull requests against it.
Three ways to start
The New Project dialog has three tabs, all producing the same kind of workspace. Each needs a connected GitHub account.
| Start from | What happens |
|---|---|
| Git URL | Paste any GitHub repo URL. Private repos authenticate with your token. |
| Local folder | The browser's File System Access API detects your git remote and reads .env for secrets — no upload. |
| Empty repo | A private GitHub repo is created for you, so there's always a target for pull requests. |
The sandbox sets itself up
You don't write a setup script. When a project is created, a setup agent brings the environment up in a throwaway sandbox:
- Clones your repo and reads it to detect the right install and dev commands, the port, and any prerequisite services.
- Installs dependencies and starts the dev server.
- Brings up prerequisites — a database, cache, or queue your app needs — in Docker, cross-referenced against your secrets so it never double-provisions something you already configured.
Throughout, you can watch the clone progress, the build console, and the live desktop stream in real time.
It proves the app runs before finishing
Setup doesn't end at "the build passed." The agent proves the app actually serves: it waits for the dev server to answer, screenshots it, and records a short demo of the app running. Then the build parks — the sandbox stays live so you can click around the real app yourself — until you confirm or send feedback. Feedback kicks off a fix-and-re-record loop.
Setup never commits anything to your repo. A fresh clone and install must leave a clean working tree; leftover build artifacts fail the setup rather than getting snapshotted.
Fast threads after that
Once you confirm, the ready environment is snapshotted, and a small warm pool keeps a pre-configured sandbox paused and ready. New threads claim one and boot in seconds instead of re-running the whole setup — they just fast-forward to the latest code and rewrite secrets.
Secrets
Secrets you provide (or that were detected from a local .env) are stored on the project and injected into every sandbox. Because any secret is visible to every sandbox, keep write-capable tokens out of project secrets — scope those per automation instead.