Skip to main content
A project is the context group your threads run in. It owns the repository catalog (which repos a machine gets, and each repo’s base branch), the dev environment, environment variables, snapshots, automations, and integration routing like Linear team mappings. Start a thread in a project and its machines come up with that project’s repos and configuration without you naming anything. For human members, projects don’t gate access: every enabled member of the organization can read every non-personal thread in every project. Service users are the exception, each carrying its own project access (all projects, or an explicit list). Repository reach comes from GitHub, never from the catalog: a human’s clones and pushes use their own GitHub access, a service user’s run through the Capy GitHub App installation, and putting a repo in a project’s catalog grants neither anything new.

​
Repositories

A project carries an ordered list of repositories, each with a base branch: the branch machines check out and PRs target by default. The list can be empty: repoless projects are first-class for research, planning, and general computer-use work. It can also be long; there’s no cap on repos per project. Connecting the GitHub App grants access; it never edits the project’s catalog. You pick what the App may reach in GitHub’s installer, then pick what the project contains in Capy’s repository picker. Two separate choices, so an org-wide App install doesn’t dump every repo into every project.

​
Identity

Each project has a name, an icon and color (how its threads render in shared lists), and a short uppercase code of up to four letters that prefixes thread references: CAPY-42 is thread 42 of the project with code CAPY. The code is editable at any time; references travel by id underneath, so a rename never breaks anything. The project id is in the URL whenever you’re on the project’s pages: the whole route parameter after /project/ (newly created projects use project_... ids; imported projects keep their original id). That id is what the API takes as projectId when creating threads.

​
Working across projects

Threads from every project share one list, with project filters, so a project shapes context without walling off navigation. Folders and tags are organization-wide and can mix threads from different projects freely. Create a project from the project switcher, set its repos and base branches, then point the dev environment at it. That’s the whole setup: every thread started in it from then on gets the same workspace.