Work from your own tools · Lesson 2 of 5

How do you manage YAGNI Teams from Claude Code or Codex?

Published September 8, 2026

Quick answer

Two commands, two different lanes. Add the YAGNI MCP server to Claude Code or Codex and you can run your Teams from inside the harness: read the queue, engage a Worker, request a critique or a review, answer a Decision. Then yagni connect claude-code routes that same harness through YAGNI's models.

Why manage Teams from inside the harness?

Because the harness is where your engineers already are. If a team runs Claude Code or Codex all day, asking them to leave it to answer a gate is how gates get answered late. The YAGNI MCP server puts the Teams inside the tool they already have open. Your workspace admin turns the Worker tools on.

How do you connect Claude Code or Codex?

  1. Add the server. In Claude Code:

    claude mcp add --transport http yagni-workers https://yagni.app/mcp

    In Codex:

    codex mcp add yagni-workers --url https://yagni.app/mcp
codex mcp login yagni-workers

    Configure the connection without a static authorization header, so discovery can run.

  2. Authorize in the browser. Open the /mcp panel in your harness and authenticate the yagni-workers connection. It uses your existing YAGNI sign-in: choose the workspace, check the permissions you want to grant, and connect.

  3. Find the Team. Ask for your accessible Teams, their Workers, and their repository scope. Prefer an existing Team. A repository is not a Team, and a new one is created only when you explicitly ask for it.

  4. Ask for the work. Engage a Worker on that Team, then request a Reeve critique of a plan snapshot, or a private Proctor review of a pull request pinned to its current commit. Fletcher, in beta, can verify a pull request revision in your repository environment and hand back its evidence.

  5. Read the result and answer the Decision. Pull the durable result back by its request id: findings, evidence, cost. Disagree and your correction is recorded against that exact result version. You can propose the exact wording change for that Worker, which stays inactive until its Decision is accepted, and you can resolve the Decision that publishes a review to GitHub.

What can you do over MCP, and what stays put?

You can discover Teams, create one you asked for, engage a Worker on demand, buy a critique or a review, read the durable record, record feedback, propose instructions, and resolve the two supported Decisions. Engaging a Worker this way is on demand: it starts no schedules and turns on no automatic pull request review. Everything you answer through the harness is recorded as a delegated action, with your name and the connection on it.

When do you use yagni connect instead?

When the bill is the problem rather than the workflow. One command points the harness at YAGNI’s models:

yagni connect claude-code
yagni connect codex

It writes the base URL and a token helper into the harness’s own settings, so nothing secret is baked into a file. --project scopes it to one repo, and --off removes exactly what it added. Usage rolls up under that harness’s name beside YAGNI Code and your Workers, on one rate card.

The two lanes are independent. Run both, or either: manage the Teams over MCP, route the models with connect.

Common questions

How do you authenticate the MCP connection?

Through the browser, on your existing YAGNI sign-in. You pick the workspace and check each permission explicitly: read, invoke paid work, manage Teams and Engagements, and resolve supported Decisions. None is preselected, and no permission ever gives you more than your own workspace membership already allows. A personal access token is the older, narrower path: it carries the seven ticket tools only, never Worker management.

Does closing the client cancel the work?

No. A request is durable on YAGNI's side. Close the laptop, come back tomorrow, and pull the result by its request id. Retrying with the same operation key returns the same request rather than buying a second run.

Does a Proctor review posted this way show up on GitHub?

Only when you say so. A review requested over MCP is private to the Team in YAGNI. Publishing it stages a Decision showing the exact comment body first, and publication is a GitHub comment review: it never approves, requests changes, or merges.

Is this the same thing as yagni connect claude-code?

No, and they are worth keeping apart. The MCP connection is about management: your harness talks to your workspace and the Workers do the work on YAGNI's side. yagni connect is about routing: the harness keeps its own workflow and only the models behind it change.

PreviouslyWhat is YAGNI Code and how do you work with it?

Read enough. Run it.

Book 30 minutes Log in