Running agents in parallel is easy. Running them in parallel without one silently undoing the other takes a few rules. Here's a setup you can copy.

Rule 1: one working directory per agent

Two agents editing the same checkout is the fastest way to lose work. One rewrites a file while the other is halfway through a change to it, and neither notices.

Git worktrees fix this with no extra tools. A worktree is a second working directory attached to the same repository, on its own branch.

# from your main checkout
git worktree add ../myapp-claude -b agent/claude-checkout-flow
git worktree add ../myapp-codex  -b agent/codex-webhook-retries

git worktree list

Start Claude Code in ../myapp-claude and Codex in ../myapp-codex. Each has its own files and its own branch, and both share the same history, so you merge their branches like any two feature branches.

When a task is done and merged:

git worktree remove ../myapp-codex
git branch -d agent/codex-webhook-retries

Some desktop apps do this for you. Traycer, an open-source app for Mac, Windows and Linux, runs Claude Code, Codex, Cursor and OpenCode side by side with a worktree per agent.

Rule 2: one job per agent

Worktrees stop file collisions. They don't stop two agents from solving the same problem two different ways. Give each agent a task with a clear edge: a feature, a bug, a module. "Claude Code does the checkout UI, Codex does webhook retries" works. "Both of you improve payments" doesn't.

Write the split down where both agents can see it. If it lives only in your head, you're the coordination layer, and you'll forget at 6pm.

Rule 3: claim before you start

Even with separate jobs, agents wander. The checkout UI touches the payments client; so do the webhook retries. A claim is a cheap signal that says "I'm editing this, work around it."

The low-tech version is a claims section in a file both agents read:

## Claims (update before editing, clear when done)
- src/payments/client.ts: codex, webhook retries, started 2026-10-25 14:10

Tell both agents in AGENTS.md to check it before editing a file and to add their own claim. It's crude, and it depends on agents following the instruction, but it catches the common overlap.

Tools that do this properly:

• Concord MCP (open source, MIT) is a local-first coordination layer for coding agents. Agents claim files through one MCP server, and when a second agent tries to claim the same file, it's told who already owns it. Agents can also message each other and hand off tasks.
• DMN shows each agent's status and the files it has claimed. Its claims are advisory: they never block a write, and they expire on their own. It's free, with the Windows app listed as coming soon.

Rule 4: a handoff protocol, not a handoff habit

When an agent stops, whether it finished, hit a limit or got stuck, it should leave a handoff. Make it a protocol by putting the template in AGENTS.md:

## When you stop
Write a handoff with these headings, under 40 lines:
- Branch and worktree
- Done (files changed)
- Not done, in order
- Failed (and commands not to rerun)
- Decisions made, one line each with the reason
- Release any claims you hold

A few details make this work in parallel:

One handoff per agent. A single HANDOFF.md that both agents overwrite is a race. Use handoffs/claude.md and handoffs/codex.md, or a store that keeps versions.

Commit it on the agent's branch. The handoff then travels with the code it describes, and the merge brings both together.

Read before starting. The opening instruction for any session is "read the handoffs and claims first." Put that in AGENTS.md too.

Rule 5: merge like a person

Agents are good at producing branches and less good at noticing that two branches made conflicting assumptions. Review merges yourself. A quick check that pays off: compare the "Decisions made" sections of both handoffs before you merge. If one agent decided retries live in the client and the other assumed the server, you've found the conflict before it reaches main.

Putting it together

repo/
  AGENTS.md          # rules, claims protocol, handoff template
  handoffs/
    claude.md
    codex.md
../myapp-claude/     # worktree, agent/claude-*
../myapp-codex/      # worktree, agent/codex-*

Claude Code reads AGENTS.md when there's no CLAUDE.md, or through an @AGENTS.md import at the top of one. Codex reads it by default. Both agents get the same rules, separate directories, visible claims and a handoff to read.

Where files start to strain

This all runs on plain files, and it holds up for two agents on one repo. It strains when:

• claims and handoffs need to be visible across several repos or machines
• a chat-based agent doing research needs the same context as the coding agents
• you want a record of which agent changed what and why without digging through commits
• you want agents to wait for your approval before something leaves the repo

That's where a shared workspace over MCP comes in.

Disclosure: I'm the founder of TokenRip, built for this part. Each agent signs in through MCP or the rip CLI. rip workspace load <workspace> returns your instructions, what waits on that agent, the pinned decisions, recent sessions with the reason for each change, the latest handoff notes and open tasks. Taking a task starts a lease (two hours by default over MCP), so a second agent can see it's held. Leaving a handoff is one command:

rip artifact publish handoff.md --type markdown --title "Handoff" \
  --workspace-id <workspace> --handoff --why "Ship webhook retries before Friday"

Every write needs a --why, and a write without one is refused. A chat agent can join too; our FAQ is upfront that we haven't wrapped up our own ChatGPT testing. 1 GB is free, at https://tokenrip.com.

Keep the worktrees and the one-job rule either way. A shared workspace replaces the claims file and handoff folder; it doesn't replace giving each agent its own place to work.

This is a hands-on guide. The syntax below comes from each tool's MCP docs as of October 2026.

Pick the server first

Two shapes matter here.

Local (stdio). Each client launches its own copy of the server as a child process. Sharing only works if those copies read and write the same storage. The reference Knowledge Graph Memory Server is the example used below.

Remote (Streamable HTTP). One server runs somewhere else, and every client talks to it over HTTP. Sharing works as long as all clients authenticate as the same account or workspace. Hosted memory tools and shared workspaces work this way.

Start local if you just want to try it. Go remote if the agents run on different machines or you want people in the loop too.

Option A: one local memory file for all three

The Knowledge Graph Memory Server (@modelcontextprotocol/server-memory, MIT) stores entities, relations and observations in a JSONL file. Its MEMORY_FILE_PATH environment variable sets where. By default the file sits in the server's own directory, which is easy to get wrong across clients, so set it explicitly to one absolute path.

Its README covers the concurrency question directly: each client starts its own server process, and every write takes an exclusive lock file next to the memory file, so writes from different processes take turns and none is lost. The directory holding the file must be writable. The README lists Node.js 24 or later when the server runs through npx.

Pick a path, for example /Users/you/agent-memory/memory.jsonl, and use it everywhere.

Claude Code

claude mcp add --env MEMORY_FILE_PATH=/Users/you/agent-memory/memory.jsonl \
  --transport stdio memory -- npx -y @modelcontextprotocol/server-memory

Two details from the Claude Code docs. Everything after -- is passed to the server untouched. And --env takes several KEY=value pairs, so if the server name comes right after --env, the CLI reads the name as another pair and rejects it; keep another option such as --transport stdio between them, as above. Use --scope if you want the server available beyond the current project.

Cursor

Create .cursor/mcp.json in the project, or ~/.cursor/mcp.json for every project:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": {
        "MEMORY_FILE_PATH": "/Users/you/agent-memory/memory.jsonl"
      }
    }
  }
}

Codex

Edit ~/.codex/config.toml, or a project-scoped .codex/config.toml:

[mcp_servers.memory]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-memory"]
env = { MEMORY_FILE_PATH = "/Users/you/agent-memory/memory.jsonl" }

command is required for stdio servers; args and env are optional.

Option B: one remote server for all three

Remote servers use a URL instead of a command. The examples use a placeholder, https://mcp.example.com/mcp; swap in your server's endpoint.

Claude Code

claude mcp add --transport http shared https://mcp.example.com/mcp

If the server takes a bearer token instead of OAuth:

claude mcp add --transport http shared https://mcp.example.com/mcp \
  --header "Authorization: Bearer $SHARED_MCP_TOKEN"

Inside Claude Code, /mcp shows server status. Removing a remote server with claude mcp remove also deletes the OAuth tokens Claude Code stored for it.

Cursor

{
  "mcpServers": {
    "shared": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Add a headers object for static auth headers. For OAuth servers, Cursor's docs also cover giving static OAuth client credentials in mcp.json when a provider doesn't support dynamic client registration.

Codex

[mcp_servers.shared]
url = "https://mcp.example.com/mcp"
bearer_token_env_var = "SHARED_MCP_TOKEN"

For OAuth servers, leave out the token line and run codex mcp login shared. Codex tries configured bearer tokens and headers first, then stored OAuth credentials.

Keep the token out of the repo

Use environment variables for tokens, as above, rather than pasting them into a project config you commit. If the server supports a separate key per agent, give each client its own, so you can revoke one without breaking the others.

Prove the three share it

A green status light means the client connected. It doesn't mean they share data. Test it.

1. Write from Claude Code. Ask it to save one small, checkable fact through the server, such as "The payments service is owned by the platform team."
2. Confirm it landed. For the local server, open the JSONL file and look for it. For a remote server, check its web view if it has one.
3. Read from Cursor. In a new chat, ask who owns the payments service. The answer should come from the server, so ask the agent which tool it used.
4. Read from Codex. Same question, same check.
5. Reverse it. Write a different fact from Codex and read it from Claude Code.

If an agent answers without calling the server, it guessed. Be explicit in your instructions: add a line to your AGENTS.md such as "Before starting, check the shared memory server for project facts, and save anything the next agent should know."

Common failures

• Facts saved but not found: two clients are pointing at different memory files. Print the path each config uses.
• Server never starts in one client: Node is missing or too old on that machine's path. Run the npx command by hand.
• Claude Code rejects the add command: check the --env placement described above.
• Remote server works in one client only: the clients signed in as different accounts, so they're reading different data.

When memory is not the whole story

A memory server stores facts. If your agents also hand each other drafts and tasks, you'll want versions, a record of who changed what, and somewhere to approve outside actions.

Disclosure: I'm the founder of TokenRip, a remote MCP server built for that case. It uses Streamable HTTP with OAuth 2.1 or a per-agent API key, and its setup guide walks an agent through connecting itself with your email and a six-digit code. Agents load a workspace's pinned decisions, open tasks and recent changes, and every write states why. Claude Code, Codex and Cursor are among the agents the site lists. On the chat side, our FAQ flags that we still owe a complete test of our own in ChatGPT. 1 GB is free, at https://tokenrip.com.

Whichever server you choose, the test in this post is the part to keep. Run it again any time you add a client.

This post walks through the setup and the checks. Everything here comes from each tool's own docs as of October 2026.

Step 1: write the shared file

Start with what every agent needs on every run and nothing else. A reasonable skeleton:

# AGENTS.md

## Setup
- Install: `pnpm install`
- Dev server: `pnpm dev`
- Tests: `pnpm test` (run before proposing any commit)

## Conventions
- TypeScript strict mode
- Business logic lives in `src/services/`, never in route handlers
- Use the shared `Button` component for every button

## Don't touch
- `migrations/` (generated)
- `vendor/`

## Decisions
- See `docs/decisions/` for why things are the way they are

Two principles keep it useful:

It loads every time. Each tool reads the file at session start, relevant or not. Every line costs context on every run, so leave out anything that only matters for one task.

Rules, not state. "Tests use Vitest" belongs here. "I was halfway through the billing refactor" doesn't. Work in progress goes in a handoff note or a shared store (more on that at the end).

Step 2: Codex

Codex reads AGENTS.md without any configuration. It reads a global one in ~/.codex, then each AGENTS.md from the repository root down to the directory you started in, so a nested file adds rules for that part of the tree.

The limit to know about: Codex stops reading project instructions after 32 KiB by default, a limit set by project_doc_max_bytes in its config. If your combined files go over that, the rest is cut. Most teams never get close, but a monorepo with nested files can.

Step 3: Cursor

Cursor supports AGENTS.md in the project root and in subdirectories. A nested AGENTS.md applies when the agent works with files in that directory or below it. Cursor's docs position it as a simple alternative to .cursor/rules for plain markdown instructions without metadata.

If you already have .cursor/rules, you can keep both. Use project rules for things that need Cursor-specific options, like rules scoped to file globs, and keep the shared conventions in AGENTS.md. One gotcha from the same docs: project rules need the .mdc extension, and a plain .md file in .cursor/rules is ignored because it has no frontmatter, so don't move your shared file in there.

Step 4: Claude Code

Claude Code has its own file, CLAUDE.md, and reads AGENTS.md under one condition: by default it reads AGENTS.md only when there's no CLAUDE.md in your working directory or any directory above it.

So you have two clean options.

Option A: no CLAUDE.md. Claude Code finds AGENTS.md and loads it. In an interactive session it shows a line saying no CLAUDE.md was found and which AGENTS.md it loaded.

Option B: keep a CLAUDE.md and import the shared file.

# CLAUDE.md
@AGENTS.md

## Claude Code only
- Use plan mode for changes under src/billing/

Imports are expanded at load time. Relative paths resolve from the file that contains the import, and imports can nest up to four hops deep.

The gotchas that stop a file from loading

These are the cases where everything looks right and a tool still isn't reading your rules.

A CLAUDE.local.md counts as a CLAUDE.md. Per the Claude Code docs, CLAUDE.md, .claude/CLAUDE.md and CLAUDE.local.md in your working directory or above all count for the "is there a CLAUDE.md?" check. Add a CLAUDE.local.md for your personal, uncommitted notes in a repo that relies on AGENTS.md, and Claude Code stops reading AGENTS.md for you. The docs describe a setting to keep both; otherwise, import @AGENTS.md from your local file.

Some files are never read. Claude Code does not read AGENTS.local.md, AGENTS.override.md, or anything under a .agents/ directory.

Your global file doesn't block it. A ~/.claude/CLAUDE.md in your home directory doesn't count for the check and loads alongside AGENTS.md. Same for an organization-managed CLAUDE.md and .claude/rules/ files.

Size creep. Remember the 32 KiB default in Codex. If you nest files across a big monorepo, check the total.

Step 5: verify each tool

Don't trust the setup until you've seen it work in all three.

1. Add a harmless, checkable rule to AGENTS.md, like: "When asked for the project codename, answer 'heron'."
2. Start a fresh session in each tool and ask for the codename.
3. In Claude Code, run /memory to see which instruction files it loaded.
4. Remove the test rule once all three pass.

A tool that answers without the codename is reading something else. Check the gotchas above before anything more exotic.

What AGENTS.md can't do

A rules file solves the static half of the problem. It can't tell Codex what Claude Code changed an hour ago, which approach failed, or which task is already in progress. You'd have to edit the file constantly, and agents rarely keep it current on their own.

For that moving half, the common answers are a handoff note the outgoing agent writes, or a shared store all three tools connect to over MCP, since all three are MCP clients.

Disclosure: I'm the founder of TokenRip, a shared store of that kind. Claude Code, Codex and Cursor reach it over MCP or the rip CLI, and each run begins by loading one common workspace: pinned decisions, open tasks, recent sessions with a stated reason for each change, and the latest handoff note. Chat apps can connect as well; per our FAQ, our own ChatGPT run-through isn't finished, so that path is untested by us. 1 GB is free. It's at https://tokenrip.com.

Keep the rules in AGENTS.md either way. A shared store is for what changes; the file is for what doesn't.