Cursor Projects Multiplayer: Whose Agent Can Touch Production?

Cursor made Projects multiplayer on 10 November 2026. Aryaman Khandelwal's post is the source: invite teammates into a Project, plan and ship alongside all of your agents, shared task board, shared context, agent-to-agent talk across people. It is rolling out in beta to all Cursor users. Create a Project in the left nav and invite.

That is a collaboration launch. It is also a permissions launch. One person's fleet was already enough to delete a production volume when the token allowed it. Several people's coordinators, sharing context and unblocking each other, multiply the same surface. The question is not whether multiplayer is useful — on-call handover is the example Cursor is proud of — it is whose agent can touch production once the invite lands.

This note is for teams about to turn a private Project into a shared one. We cover what shipped, how it differs from Live Apps, where cloud-agent secrets and GitHub access actually sit, why "agents will agree on the schema order" is not a gate, and what to lock before the second human joins. The incident that still defines this class of failure is Cursor deleted a production database. Claude Code's same-week CI lesson is auto mode 2.1.319: unattended agents fail differently than a laptop.

What Projects was, and what multiplayer adds

Cursor introduced Projects in September 2026 as a way for one engineer to direct a fleet through a coordinator. Workers did the large-scale work; the human steered. Context lived in that person's chats. A new hire rebuilt it.

Multiplayer, 10 November, keeps the one-to-one chats. Each teammate still has a coordinator and workers with local context. On top, Cursor adds:

• A shared context system: requirements, diagrams, specs, mockups. Built once, grown with the work. A decision in one chat is available to every agent in the Project.
• A shared task board: who is doing what, what each person's agents are running, the PR behind each task.
• Invites: a teammate joining gets that shared layer pre-configured. Cursor's line is that they skip repetitive setup.
• Agent-to-agent communication across teammates. Coordinators "spot overlap" and "agree on the order of work." The product-page example: reviews plus a redesign land in one design. The database example: a feature that reads a schema and a teammate changing that schema "agree up front" so you do not hit a merge conflict.

On-call is the story Cursor tells hardest. Their teams run rotations in a shared Project. When an engineer took over, their coordinator checked in, then picked up in-flight work, unattended issues, incident notes, and which Slack channels, Linear boards, and threads to watch. In-progress work can be handed over: the new person's agent takes it on.

Beta, all users, left-nav Project, invite. There is no separate "multiplayer SKU" in that post. If you can create a Project, you can share one.

Live Apps is a different product

Five days earlier Cursor shipped Live Apps: cloud agent builds an app, optional Postgres, Cursor SSO, a URL, publish checks. That is a host. Projects multiplayer is a room. Mixing them in a stand-up is how you get the wrong checklist.

Live Apps risk is a public or team link and an agent-provisioned database. Projects risk is people and fleets in your git and MCP. A designer invited to a Project does not automatically publish a Live App. A backend engineer whose cloud agent has the production MCP and repo write does not need Live Apps to break prod. Run both checklists if you use both. Do not skip this one because publish checks passed on an internal dashboard.

Cloud Agents docs are the layer under both: isolated VMs, cloned repos, secrets, MCP, hooks, GitHub/GitLab/Bitbucket/Azure DevOps, Slack @cursor, PR comments, Linear. Agents work on a branch and push for handoff. You need read-write on the repo and dependents. That write is the production-adjacent permission, with or without a shared Project.

Whose agent can touch production

Cursor's multiplayer post does not publish a new IAM matrix. Production reach is the union of Project membership and what that member's agents can already do. Spell the union out before you invite.

Project invite. Shared context includes specs, incident notes, Linear, channels, and — in the on-call story — enough for a coordinator to continue the rotation. That is operational knowledge. An intern's agent that can read how last night's incident was mitigated is useful. The same agent with a deploy MCP is a different invite.

GitHub (or GitLab, Bitbucket, Azure DevOps) write. Cloud agents push branches and open PRs. Comment @cursor on a PR or issue kicks an agent. If the teammate's Cursor account is connected to a repo they can write, their coordinator can write. Cursor's share-agent rules are stricter for viewing a run: team membership is not enough; the viewer must connect source control and have access to that repository. Viewing is read-only unless a team admin enables team follow-ups. Follow-ups let teammates send messages and continue the work. That admin toggle is a production control. Leave it off until you know who may steer another person's agent.

Secrets. Cloud-agent secrets live in the dashboard, workspace/team-scoped, injected at agent start. A secret added after a run does not appear in that run. Snapshots can include .env.local if you put it in the snapshot; Cursor recommends the Secrets tab instead. Multiplayer does not isolate secrets per Project in the launch post. Assume a teammate's cloud agent in the same Cursor team sees the same secret set you gave cloud agents, unless you have split teams or environments on purpose.

MCP. Cloud agents use team MCP servers from cursor.com/agents. HTTP and stdio, OAuth where needed. A Project that "unblocks" a schema change via MCP to the database is only as safe as that server's credentials. If MCP can DROP, two coordinators agreeing on order is irrelevant.

Slack and Linear. @cursor from a channel the intern is in is another kickoff path. Shared Project context plus a Slack trigger is how an on-call bot becomes an unattended prod actor at 2am. Restrict which channels may invoke the app.

Local vs cloud. Projects include local chats with coordinators. A local agent still has the human's laptop tokens: gh, cloud CLIs, .env. Inviting someone whose laptop is logged into prod AWS is inviting that key, whether or not they "only wanted shared specs."

Hooks. Cloud agents run .cursor/hooks.json from the repo (and enterprise-managed hooks on Enterprise). beforeShellExecution and preToolUse are the place to fail closed on production-shaped commands. User-level ~/.cursor/hooks.json does not run on cloud VMs. If your only deny is on your laptop, the teammate's cloud coordinator never saw it.

None of this requires malice. Cursor's own overlap example is two people, two agents, one product page. Replace "reviews" with "migration" and "redesign" with "widen the column." Coordinators that "agree" can still both push, both use MCP, both skip the human who owns on-call.

What "agents agree" does not lock

The database example in the launch post is the one to take literally and then refuse as a control.

Cursor says: if your feature reads from a database while a teammate changes the schema, agents agree on order up front so neither hits a merge conflict. That is git conflict avoidance. It is not:

• a migration lock
• a hold on prod apply
• a guarantee both agents used staging
• a record you can show in an incident review

PocketOS was one agent, one human, a staging task, a shared volume id, nine seconds. Multiplayer adds a second coordinator that might "helpfully" continue the credential fix. Shared context means the new on-call agent knows the incident is a Railway volume mismatch. If that agent's environment still has a token that can delete the volume, handover just transferred the gun.

Merge conflicts are the easy failure. The hard one is two PRs that both apply, both pass CI, and together drop a column a third worker still writes. Humans already fail that without agents. Fleets make it faster. The fix is the same boring stack: expand-contract migrations, required reviewers, environment-scoped secrets, and a deny on apply-to-prod from the agent. Not a better prompt in the shared spec.

On-call handover is powerful and concentrated. The incoming engineer's agent inherits in-flight work and the list of systems to watch. If "keep an eye on" includes a production MCP, you have staffed an unattended responder. Cursor says the coordinator checked in first. Check-in is not confirm-on-delete. PocketOS had a rule in the prompt and ignored it.

Shared context is a secret store

Requirements docs and mockups are the happy path. Incident notes, Linear tickets with customer payloads, .env examples pasted into a spec, warehouse screenshots — those also land in "the shared layer built once and grown with the team's work." A new teammate's agents get it on invite. So does every worker those agents spawn.

Treat the Project like a repo wiki that agents read by default:

• No live secrets in specs. Rotate anything that was ever pasted.
• Customer data in tickets stays in the ticket tool with its own ACL, or is redacted in the shared layer.
• On-call notes name systems and owners, not tokens.
• Offboarding: remove the person from the Project and revoke their GitHub, Slack @cursor, and cloud-agent presence. Shared context without a seat is still in the layer until you edit it.

Cursor's agent-viewing rule (repo access required, not merely team membership) is the right instinct. Apply it to Project invites. Not everyone on the Cursor team belongs in the production on-call Project.

What to lock before the second human joins

1. Two Projects if you need two trust levels. Prototyping vs anything with prod MCP or prod secrets. Do not "just invite the company."
2. Cloud-agent secrets are staging or empty in the shared Project. Production apply stays a human pipeline.
3. Team follow-ups off until you want other humans steering a running agent.
4. @cursor on PRs and Slack limited to people who may write that repo. Repo ACL is the real invite list.
5. Hooks in the repo, not only on laptops: fail terraform apply / production kubectl / railway volume shaped commands on cloud agents.
6. MCP servers for the team cannot drop prod data. If they can, they do not belong on the Project that designers join.
7. Required reviewers on main and on migration paths. Agent-opened PRs are still PRs.
8. Handover test: invite a second account, confirm their coordinator can see the board, confirm it cannot run the prod MCP. If it can, the invite was a production grant.
9. Live Apps separately. A shared Project is not a publish check.

If you cannot tick 2, 5, and 8, do not run on-call in that Project yet. Use it for specs. Keep the fleet that can ship on one person's laptop with a scoped token, or on CI with the same fail-closed idea as Claude Code auto mode.

When multiplayer is the right room

Use it when the work is parallel product development, the tokens are staging, PRs still need people, and the value is shared specs plus a board. Cursor's reviews-and-redesign example fits. On-call fits after prod MCP is out of the agents' environment and handover is a checklist, not an inherited credential.

Skip it — or split Projects — when a contractor, a designer, and a backend lead would otherwise share one secret set; when the only "environment" is production; when @cursor in Slack can apply. Beta software plus a fleet plus prod is how nine-second deletes get a team.

The generated app can still be the part that holds. Defaults around it — token, volume id, who is in the Project — are what fleets change without opening a file. That split is unchanged from the outage note. Multiplayer just adds more hands on the same defaults.

Billing follows the same cloud-agent meter: plan usage at the selected model's rate, spend limits when you first use cloud agents. Two coordinators plus workers is not a free collaboration layer. Watch the bill when on-call handoff keeps a fleet warm overnight. A shared board full of idle agents is still token spend, and it is still a fleet that might hold a secret.

How Techtribe takes a multiplayer Project from here

On the scope call we look at who is in the Project, which cloud-agent secrets and MCP servers those seats inherit, whether team follow-ups and @cursor are on, and whether a second account's coordinator can reach production. You leave with a fixed scope and a price. The call is free.

When the fix is splitting Projects, hooks, and staging secrets, it is a short repair. When the product is already live and the fleet is how you ship, the honest path is a Production MVP or a Dedicated Team: your repo, scoped credentials, review gates, evals. Live Apps if you also published a URL. Prices are on packages.

Bring the Project, the invite list, and one teammate account that should not deploy. If their agent can, that is the meeting.