Shared rules in code review

Two coding agents don’t share a chat history. If Claude Code learns a team rule in one session, Codex doesn’t know it in the next. Connect both to one brain and the rule only has to be written down once.

In this example, Claude Code saves three team rules to a brain. Later, Codex reviews a teammate’s pull request against those rules without ever seeing the Claude Code session, and it catches every rule the pull request breaks.

The recording is a real run, edited for length.

The project

The project is a small, made-up checkout API for an online store, written for this example. It lists products and creates orders, working out the subtotal, sales tax and total on the server. The team has three rules:

None of these rules appear in the README or in code comments. The brain is the only place they’re written down.

Claude Code saves the rules

Claude Code checks that the code follows each rule, then captures them:

We're onboarding AI tools to this repo. Our team rules are: (1) money is always integer cents,
never floating-point dollars; (2) every API error uses the shape { error: { code, message } } via
ApiError and toErrorBody; (3) prices and totals are computed on the server from the catalog, never
taken from the request. Check that main follows these rules, then save each rule, with the files it
lives in, to my Living Brain called 'Shop API'.

It captures one note per rule. Each note names the files and functions the rule applies to.

The brain compiles them into pages

The brain compiles the three notes into 14 pages with 34 connections between them. Some pages cover a whole rule, such as Money Representation Rule. Others cover one place where a rule applies, such as formatCents or toErrorBody. Each page lists the note it came from, so you can trace any page back to the rule Claude Code captured.

Naming the files and functions in each note gives the brain more to build pages from, so a reviewer can find a rule by searching for the code it’s looking at.

A pull request breaks the rules

A teammate adds discount codes. All 12 tests pass, but the change breaks all three rules:

Codex reviews against the brain

Codex starts with no knowledge of the Claude Code session:

Review the changes on branch feature/discount-codes compared to main. Before reviewing, look up our
team decisions in my Living Brain called 'Shop API' using the livingbrain MCP tools, and check the
change against them. List every violation with file and line, quote the decision it breaks, and
suggest the fix. Do not modify any files. Answer in English.

It finds the brain with brains_list and lists its pages with workspace_list_pages. Then it reads the diff and opens the relevant pages with workspace_get_page. It reports all three violations and quotes the rule behind each one, for example:

1. High — client-controlled prices
   Location: src/cart.ts:9-10, 26, 30, 36, 41, 46-47
   Decision broken:
   > "Prices and totals [must be] computed on the server from the catalog, never taken
     from the request."
   Fix: Remove unitPrice from request input and always use product.priceCents.

It also flagged other problems in the same change, such as a malformed discount code causing a 500 error and unknown codes being accepted without one.

Set it up in your repository

Coding agent memory keeps each developer’s configuration in user scope, because the key works across your whole organization. You can commit the configuration to the repository instead, as long as the key comes from an environment variable. Then everyone who clones the repository gets the brain, and nobody commits a key.

Use one subject for the whole project, so every developer’s agents read and write the same pages. Generate one UUID and use it in place of YOUR_PROJECT_SUBJECT_ID. The subject ID isn’t a secret, so it can go in the committed file.

{
  "mcpServers": {
    "livingbrain": {
      "type": "http",
      "url": "https://livingbrain.fernmcp.dev/livingbrain",
      "headers": {
        "x-api-key": "${LIVING_BRAIN_API_KEY}",
        "x-subject-id": "YOUR_PROJECT_SUBJECT_ID"
      }
    }
  }
}

Each developer sets LIVING_BRAIN_API_KEY in their own environment.

Tips

• Ask the reviewer to quote the rule. A finding that quotes the page it relies on is easy to check, and it shows the rule came from the brain rather than the model’s general advice.
• Name the code a rule covers. Listing files and functions in a capture helps a search for that code find the rule.
• Capture a rule once, from any agent. Whichever agent captures a rule, every connected agent can read it.
• Keep approval on tools that change pages. A review only needs to read. Start from the table in Limit what the agent can do, and also allow brains_list and workspace_list_pages, which this review calls.

Coding agent memory covers when an agent should search and capture, and what makes a useful capture.