How do I limit what a Claude Code crew can touch while it does framework migrations in a Node/TypeScript app?

Tares gives you five levers to limit a Claude Code crew: the repos your gh login can write to, the merge setting, the reviewer bar, halting the crew and leaving the releaser off. You set most of them once, when you run tares factory crew up the first time, and you can halt the crew at any moment. Together they decide what the crew can push, what it can merge and whether anything ships beyond main.

How it works

The crew is a set of Claude Code sessions on your machine: an orchestrator, a reviewer, builders and, only if you ask, a releaser. Each lever below bounds a different part of what they can do.

• Your gh login. Builders push branches and open pull requests with your gh login. They can only write to repos that login can write to. Tares reads pull request, CI and merge state with its own GitHub access, set under Settings > GitHub on a local Tares or with Connect GitHub on Tares Cloud.
• The merge setting. On the first run you choose whether the crew merges on its own after review and green CI, or waits for your yes. A single project can also wait for your yes before every merge while the rest of the crew merges by itself.
• The reviewer bar. The reviewer reviews every pull request to a fixed bar and posts its verdict on the pull request. A builder merges only once the reviewer passes it and CI is green. You can also turn on a second model, through the optional Codex CLI, that checks every commit.
• Halt. tares factory crew halt stops merges, pushes and new sessions until you run tares factory crew resume.
• The releaser. It tags and deploys, and it exists only if you ask for one. Without it, tickets end at merged on main.

The first run also asks how many builders run at once and what you always allow. Tares keeps your answers, so a crew that restarts keeps the same limits.

Set it up

1. Sign in to gh with an account whose write access covers only the repos the migration needs. Builders cannot push anywhere that login cannot write.

   gh auth login

2. Install the CLI and start Tares as described in Get started. Locally that means tares up, then tares mcp --transport streamable-http in a second terminal. On Tares Cloud you sign in with tares login instead.

3. Bring up the crew and answer the settings questions with the tight choices: merge only after your yes, no releaser, the second-model check on if you have the Codex CLI, and a low number of builders at once.

   tares factory crew up

4. Plan the migration from the repo it touches. The planning session writes milestones with acceptance checks and tickets, so you can read the scope before you hand the project to the crew.

   tares factory spec "what you want to build"

5. Answer the crew’s questions in the orchestrator’s session. Each arrives one at a time with a recommendation. Use the status and doctor commands to see what is running and whether the setup is sound.

   tares factory crew attach orchestrator
   tares factory crew status
   tares factory doctor

6. If a migration goes somewhere you do not want, halt the crew with a reason. Merges, pushes and new sessions stop, and the plan and tickets stay on Tares. Resume when you are ready, or stop every station with tares factory crew down.

   tares factory crew halt "pausing the migration to review"
   tares factory crew resume

For a Node/TypeScript app, tares factory doctor also checks the language server. It finds TypeScript through tsconfig.json and JavaScript through package.json. When the server is missing, it prints the install commands, and crew up offers to run them only if you say yes. This helps builders and the reviewer search the code, and it does not change what the crew may touch.

What you get

• A crew that can write only to the repos your gh login covers.
• Merges that happen only after the reviewer passes the pull request and CI is green, or only after your explicit yes if you choose that.
• A reviewer that checks every pull request to the same fixed bar, with an optional second model checking every commit.
• A stop button that freezes merges, pushes and new sessions at any time and lets you pick up again without losing the plan, tickets or your answers.
• No tags or deploys unless you asked for a releaser. Work ends at merged on main.
• A record on Tares of the plan, the reviews, the assumptions the crew made and your answers, so you can check each milestone afterwards.

When something else fits

• If you want to drive each step yourself, use tares factory session instead of the crew. It opens one Claude Code session bound to the project, still on Tares.
• If a project needs your approval on every merge while the rest of the crew merges freely, set that on the one project rather than for the whole crew.
• If you want deploys handled for you, ask for the releaser, and expect it to tag and deploy beyond main.

Related