Codex, Cursor and other MCP clients
By Soumen Sarkar · October 2026
Playbook. Codex, Cursor and other MCP clients get the same team tools but no hooks. How to connect them and which calls to make at each moment.
How do Codex, Cursor and other MCP clients work on a VibeFlock team?
They connect to the same team record over MCP and call the same tools, so a Codex or Cursor agent can look first, state assumptions, build on work in progress and hand off just as a Claude Code session does. What they don't have is Claude Code's hooks: nothing fires on its own. The agent calls the tools itself, at the right moments, following the instructions the server sends when it connects and the ones you put in its instructions file.
This playbook sets that up so a team mixing clients works as one.
Who is this for?
Teams where people use different agents on one codebase: one person in Claude Code, another in Codex, a third in Cursor. Also anyone who uses an MCP client other than Claude Code and wants their sessions to know what the rest of the team is doing.
What do you get?
- Every agent, whatever the client, reading and writing the same decisions, assumptions and handoffs.
- A Codex session that continues a handoff a Claude Code session left, and the other way round.
- Clear instructions for the moments hooks would otherwise cover.
What changes without hooks?
In Claude Code, hooks call the right tool at the right moment: an area brief on first touch, news at every turn, reasons at commit, a handoff when the session stops. In any other client, the agent has to make those calls itself. Here is each moment and the call that covers it:
- Start of a session:
session_brief(project) reads the team's state since the last session: reversed calls, your tasks, teammates' updates, the rules to follow and the decisions that stand. - Before changing a file:
work_context(project, file) returns what the team knows about that file's area, with edited: true when the agent changes it, so teammates see the area is being changed. area_brief(project, path) gives the same brief for any file or folder on demand. - Starting something others might touch:
start_work(goal, plan, expectedBy). - Something unclear:
search_memory or recall first, then state_assumption if the record is silent. - Building on unfinished work:
wait_on(what) returns its plan now. - Between requests:
session_inbox(project) returns what's new for this work: answers and corrections, work it waited on that landed, decisions that clash or were settled. - Commit or pull request:
change_story() writes the reasons and returns a link for the description. - Stopping:
hand_off(done, unfinished, nextStep, openQuestions, traps) if the work is unfinished, finish_work(outcome) if it's done.
Step 1: Connect the client
Mint a token on /connect. Minted while you're signed in to your team, it acts as you on that team; minted signed out, it's personal and sees only your own documents. An agent can call whoami to tell which it has.
Then add the server to your client:
- Codex CLI: /connect gives a block to add to
~/.codex/config.toml, under [mcp_servers.campfyrr], with the server's URL and the token. Restart Codex afterwards. Field names for remote MCP servers have changed between Codex versions, so if it doesn't take, check codex --help or Codex's documentation. - Cursor and other MCP clients: /connect gives a JSON block in the common
mcpServers shape, with the URL and an Authorization header carrying the token. Most clients accept it in their own MCP configuration; check your client's documentation for where that file lives and the exact key names. - Claude on the web or desktop: "Add to Claude" on /connect adds Campfyrr as a custom connector. You sign in and pick the team; no token to paste.
Keep the token out of anything you commit.
Step 2: Use the same project name everywhere
Every tool takes a project. Claude Code's hooks use the repository's folder name, so use the same name in every client. If the repository is called storefront, every agent passes project: "storefront", and work from Claude Code, Codex and Cursor lands side by side. A Codex agent passing "Storefront app" instead would write to a separate project, and nobody in the first one would see its assumptions.
Step 3: Write the moments into the agent's instructions
When the client connects, the server sends instructions that describe these moments, and most agents follow them. Writing them into the file your agent reads at the start makes them reliable. For Codex that's AGENTS.md; for Cursor and others, whatever rules or instructions file the client reads.
Start with the team agent instructions template, then add the calls:
We use Campfyrr. This client has no automatic hooks, so make these calls yourself,
always with project: "storefront".
- At the start of a session, call session_brief once and read it before working.
- Before changing a file in a part of the code you haven't touched this session,
call work_context with the file, and edited: true once you change it. Follow the
decisions it lists; build on work in progress there, not around it.
- When you start something others might touch, call start_work with the goal,
the plan and when it should be done.
- When something is unclear, search first (search_memory). If the record doesn't
answer it, call state_assumption with what you're assuming, likely answers and
the stakes, and keep going.
- At the start of each new request, call session_inbox and act on any corrections.
- When you commit or open a pull request, call change_story and put its link in
the description.
- Before you stop: hand_off if the work is unfinished, finish_work if it's done.
After a meaningful chunk of work, log_work in plain words.
Step 4: Look first, with search
Every connected agent can search what the team wrote. search_memory(query) returns the passages that answer a question, each with a link to the exact place. recall(query, level) reads what the team knows about something, short version first: one line per document at level 0, key takeaways at level 1, matching passages at level 2. list_decisions is the register of decisions, and gather_rules returns the rules in force.
Example: a Cursor agent in Search · lib/search wonders whether to add a separate search service. It calls search_memory("search service") and finds a decision: search uses Postgres full-text search, because the corpus is small and another service costs more to run. It follows the decision and moves on. Nobody was asked. That's answer it yourself at work.
Step 5: State assumptions, and check for answers
When the record is silent, state_assumption records what the agent is assuming. If the team's record already settles it, the answer comes straight back. Otherwise it goes to whoever made the closest decision or last worked in that area, and the agent keeps going.
Without hooks, a correction reaches the agent when it next calls session_inbox. That's why the instructions ask for it at the start of each request. In a long session with few prompts, it's worth asking the agent to check after each big step too.
Step 6: Leave the work explained
No Stop hook writes a handoff for these clients, so the agent writes one. Ask for it explicitly at the end of a session ("hand off before you stop") until it becomes routine. A good handoff names what's done, what's unfinished, the next step, open questions and traps, and any approaches dropped, so nobody tries them again.
The same goes for the reasons at commit: change_story writes them from what was recorded during the work, so the more the agent recorded (decisions, assumptions, what it built on), the better the reasons read.
Step 7: Log the work in plain words
The last habit is the one that tells the rest of the team what happened. After a meaningful chunk of work, the agent calls log_work with a few sentences a non-engineer can follow: the outcome first, what changed for users or the team and why, with file names in filesTouched rather than the summary. Approaches it tried and abandoned go in dropped, so teammates working in the same area are told. Claude Code can file a short entry from a hook; in other clients, this is the only way the day's work reaches the team's updates.
What should you watch for?
- No brief at the start. An agent that skips
session_brief works without the team's state. Check its first few calls. - Drifting project names. Different names in different clients split the team's record. Pick one and put it in the instructions.
- Missed corrections. A session that never calls
session_inbox keeps building on an assumption someone has already corrected. - No handoff. A session closed without
hand_off leaves nothing for the next person. Make it the last line of the instructions. - A personal token on a team. Its agent sees only its own documents. Mint it while signed in to the team.
How do you know it's working?
- Work in progress from Codex and Cursor sessions appears next to Claude Code's, with goals and plans.
- Assumptions from those sessions get answered from the record or by the right person.
- Handoffs cross clients: a Cursor session picks up where a Claude Code session left off.
- Pull requests from every client carry a reasons link.
- People stop asking "which agent did this, and why?"
What does Campfyrr do for these clients?
Everything except the hooks. Every MCP client gets the same tools and the same server instructions when it connects. Assumptions are settled from the record when it can, and otherwise sent to the right person; each shows in the project's Activity feed with an "Answer it" link to a page where it's answered in one click. Decisions are checked against the ones that stand as they're recorded, and when one clashes, the newer call stands. Handoffs written with hand_off show in the Activity feed as work paused partway, with the next step. Work logs from log_work become each person's daily update in plain words.
What these clients don't get is anything automatic: no brief at session start, no area brief on first touch, no news each turn, no handoff when the session stops. Those happen when the agent makes the call. What MCP is and how it connects agents to a team explains the protocol underneath, and Claude Code hooks for VibeFlock shows what the hooks add where they're available.
The principle behind this: Answer it yourself: Look first. If the answer isn't there, assume it or decide it.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).