Projects

projects.yaml is portable: it holds no local paths, so the same crew works on any machine.

my-app:
  repo: you/my-app        # owner/repo, a git URL, or empty for a folder with no remote
  team: dev               # the team that usually handles it
  about: The main product # one line for the orchestrator

Where each project is on this machine is kept in the crew, in .claude/local/places.json, which git leaves out. Projects stay wherever you keep them; nothing is cloned into a crew. Your orchestrator runs these commands when you ask in plain words (“work on github.com/you/app”, “my blog is in ~/src/blog”):

Command	What it does
cadrei project add <name> <repo> [team] [about]	clone into your projects folder, record the place, trust the folder
cadrei project add <name> --path <dir> [--repo <repo>]	register a git folder you already have (its repo is taken from origin)
cadrei project link <name> <dir>	set or change where a project’s folder is on this machine
cadrei project unlink <name> [--untrust]	remove a project from the crew; the folder is never touched
cadrei project sync	clone every project that has a repo but no folder on this machine
cadrei project trust <name> | --all	trust project folders in Claude Code
cadrei project path <name>	print a project’s folder
cadrei project dir [<dir>]	show or set the projects folder (asked once per machine; ~/Developer is suggested)

cadrei project on its own lists these. Project names may use letters, digits, ., - and _. One project may belong to several crews.

Refused folders. Add, link and trust refuse /, your home folder, anything inside or containing ~/.cadrei, a crew’s team folder, ~/.claude, and the top folder of a 0.1.x cadre (its projects/<name> folders can be linked). Trust also needs the top folder of a git repository.

Missing projects. When a project’s folder is gone, cadrei never unlinks it by itself. cadrei ls marks it, and your orchestrator offers to clone it again, point to its new folder (suggesting a repository with the same origin in your projects folder), or unlink it. A folder on a drive that isn’t connected says so. cadrei up and cadrei attach refuse a missing project.

Trust. Adding, linking and cloning a project marks its folder as trusted in Claude Code (~/.claude.json, or $CLAUDE_CONFIG_DIR/.claude.json), so members start there without the trust prompt. Cadrei records the physical path and, when different, the path as you wrote it. The edit keeps every other key and their order, keeps a backup of the original at .claude.json.bak-cadrei (the first one is never overwritten), writes atomically, checks again just before writing (a running session may rewrite the file), and skips with a warning on any doubt. Trust also lets that repository’s own .claude/settings.json rules and hooks take effect, so add only repositories you trust, or pass --no-trust. That’s why the first run, cadrei project sync and a GitHub restore never trust a repo with its own Claude Code settings (.claude/settings.json, .claude/settings.local.json, .mcp.json, or skills, agents or commands in any of its folders, and for a worktree or a submodule, the same in its main checkout or superproject) without asking you; your orchestrator asks before it adds one too.

A new crew’s own folder, ~/.cadrei/<name>, is trusted the same way, with the same checks, so your orchestrator opens without a prompt: by the first run and by cadrei new. That only works once Claude Code has run at least once on this machine, since Claude Code makes ~/.claude.json on its first launch and cadrei never creates that file. Until then, cadrei says Claude Code will ask, and you say yes once. A restored crew, from GitHub or from an archive, is never trusted in advance: its files came from somewhere else, so Claude Code asks, and you say yes only if it’s your backup. A crew that already exists isn’t trusted by these commands either.