Cursor Projects: руководство по совместной работе в Multiplayer (бета 2026)

С 10 ноября 2026 года Cursor превратил Projects из инструмента для одного разработчика в общее пространство команды. Теперь координатор может общаться с координатором коллеги, заранее замечать пересечения в изменениях кода и передавать незавершённые pull request'ы. Для безопасной работы нужны Cursor 3.26.13 или новее, аккаунт Teams и чёткие правила для общих файлов контекста: иначе неподтверждённое предположение одного агента может незаметно изменить план для всей команды.

Что изменилось в Projects Multiplayer 10 ноября

Multiplayer Projects развивает запущенную 10 сентября 2026 года однопользовательскую бету Projects. Вместо одного пользователя теперь есть рабочее пространство для нескольких участников: у каждого — свой изолированный чат один на один с координатором, а Task Board и Project Agent Store (/cursor/stores/self) общие. Согласно официальной документации Cursor Projects, обновление от 10 ноября разделяет личные рабочие контуры и общее состояние команды по восьми ключевым параметрам:

Кому доступен Multiplayer и как настроить рабочее пространство

По документации Cursor Projects, для общего Project нужен тариф Cursor Teams или Enterprise, клиент 3.26.13 либо новее и отдельный доступ каждого приглашённого к репозиторию. Функция недоступна на Free, Plus и Legacy Hobby. Приглашения также нельзя отправлять, если включён Privacy Mode (Legacy), Project работает на self-hosted machines или архивирован.

Этап 1. Создаём базовый Project за 4 шага

Сначала владелец создаёт рабочее пространство в окне Agents Cursor:

1. Откройте Projects в левой панели: перейдите в Agents Window, найдите в сайдбаре раздел Projects и нажмите New Project.
2. Задайте имя Project: выберите иконку и укажите ограниченное по смыслу название, ориентированное на результат. Если оставить поле пустым, будет использовано New Project. Вместо одного огромного Project на весь репозиторий лучше разделять работу по результатам: отдельный Project для миграции схемы, отдельный — для функции из нескольких PR, ещё один — для регулярного обслуживания CI.
3. Выберите Workspace и модель координатора: в разделе Workspace укажите целевой репозиторий GitHub; если GitHub ещё не подключён, нажмите Connect GitHub. В поле Model выберите модель, которая будет работать координатором.
4. Нажмите Create Project: Cursor выделит для Project облачный компьютер и откроет чат один на один с агентом-координатором.

Если вы уже начали прорабатывать задачу в подходящем верхнеуровневом чате Cloud Agent, перетащите этот чат из сайдбара на строку Project либо откройте его меню и выберите Add to Project. Координатор получит предыдущую историю разговора. При добавлении локального чата Cursor сначала переведёт его в режим Remote Control.

Этап 2. Приглашаем коллег за 3 шага

Когда Project активирован и подключён к репозиторию, владелец или любой действующий участник может пригласить коллег следующим образом:

1. Откройте меню приглашений: нажмите Invite в верхней части Project. После первого приглашения этот элемент заменяется рядом аватаров.
2. Добавьте коллег или скопируйте ссылку: найдите человека по имени или email в разделе Invite teammates to this project и отправьте приглашение. Либо нажмите Copy link, чтобы отправить URL Project в Slack или Linear.
3. Коллега принимает приглашение и получает отдельный чат: приглашённый нажимает Accept Invite на карточке приглашения и получает свой чат Project, своего координатора и доступ на чтение и запись к общему контексту Project.

Управление участниками и ссылками

Границы доступа контролируются и на уровне команды Cursor, и на уровне Git-репозитория:

• Требования к команде и репозиторию: пользователи личных аккаунтов и разработчики из внешних Cursor Team присоединиться не могут. У приглашённого также должен быть собственный доступ к репозиторию Project.
• Отзыв утёкшей ссылки: скопировать ссылку-приглашение могут только действующие участники Project. Если ссылка разошлась слишком широко, владелец открывает меню приглашений и выбирает Reset Share Link — все предыдущие копии перестают работать.
• Выход и удаление участников: любой участник может выбрать Leave Project в меню сайдбара и позднее вернуться по действительному приглашению или ссылке. Владелец Project удаляет участника через пункт Remove в меню приглашений.

Общий контекст /cursor/stores/self и личное хранилище /cursor/stores/user

Как сказано в документации Cursor Projects о Context и Personal Store, Multiplayer Projects отделяет приватные настройки разработчика от знаний команды двумя путями файловой системы в окружении каждого агента: /cursor/stores/self содержит общий контекст Project, а /cursor/stores/user — персональное пользовательское хранилище. Когда коллега подключается к общему Project, его координатор может предложить перенести релевантные рабочие предпочтения из /cursor/stores/user в правила Project. Копируются только записи, которые пользователь явно одобрил.

Как координаторы общаются через недоверенные сайд-чаты

Если координатору нужна информация о работе коллеги, спецификация Cursor Projects Multiplayer позволяет напрямую написать координатору этого коллеги. Для этого из его обычного чата создаётся форкнутый сайд-чат с именем Chat with {name}'s agent. Cursor ограничивает доступные ему действия, чтобы входящий запрос не прерывал основную работу адресата и не позволял извлечь секреты.

В анонсе Multiplayer от 10 ноября 2026 года продакт-менеджер Aryaman Khandelwal описал два типовых случая координации между агентами:

• Пересечение UI и функциональности: инженер добавляет отзывы покупателей на страницу товара, а дизайнер одновременно переделывает эту же страницу. Координаторы заранее замечают пересечение и встраивают компонент отзывов в новый макет, а не занимаются рефакторингом позднее.
• Порядок изменений схемы и чтения данных: один разработчик меняет схему базы данных, а другой создаёт функцию, которая читает из этой базы. Их агенты заранее согласуют порядок действий, чтобы избежать конфликта при слиянии.

В разделе How coordinators message each other официальной документации Cursor Projects описаны четыре строгих правила такого обмена:

1. Исходящий запрос: координатор коллеги A выявляет зависимость от работы коллеги B и пишет напрямую его координатору.
2. Создание форкнутого сайд-чата: входящее сообщение создаёт форк обычного чата коллеги B под названием Chat with {Teammate A}'s agent.
3. Недоверенная обработка: входящее сообщение координатора помечается как агентский ввод, получателю показывают, агент какого коллеги его прислал. Принимающий агент обязан воспринимать текст как недоверенный материал для оценки, а не как прямую команду собственного пользователя.
4. Ответ на основе основного чата и уведомление в следующий ход: сайд-чат отвечает, используя знания из основного чата адресата, и возвращает результат отправившему координатору. Основной чат коллеги B немедленно не прерывается — заметка об обмене появится в нём на следующем ходу.

Документация Cursor Projects точно определяет права каждого форкнутого сайд-чата Chat with {name}'s agent:

Идеальный процесс и реальность беты: где ломаются общие решения

В официальных примерах Cursor показывает внутренние on-call-ротации: координатор нового инженера получает активные инциденты, доски Linear и треды Slack. Однако отзывы о соло-бете Projects выявили четыре сбоя на разных этапах жизненного цикла. В командной работе для них нужны отдельные предохранители:

Изменяемые Project Notes и проблема «общих ошибок»

В опубликованном на Cursor Community Forum трёхдневном соло-тесте беты Cursor Projects разработчик Lutz Leonhardt изучил синхронизированную папку контекста и транскрипты оркестратора. Тест охватил 5 сессий, примерно 14 часов, 20 агентов, 32 задачи, 49 ходов агентов и 5 pull request'ов, из которых 4 были смержены. Делегирование и доставка результата сработали: удалось исправить все 18 замечаний бота ревью Codex. Но слой проектной памяти показал два типа сбоев, которые становятся ещё опаснее в общем хранилище Multiplayer:

• 111 перезаписей заметок против 1 явного чтения: за 3 дня координатор 111 раз переписывал файл Project Notes целиком, но явно прочитал его лишь один раз. Milestone 1 исчез из заметок до начала архивирования на второй день, а явное одобрение LLM-анализа подкаста после двух перезаписей превратилось в "done". На следующий день координатор снова запросил то же одобрение.
• Неподтверждённые дефолты записываются как решения: после того как координатор перечислил 5 ключевых слов и 3 открытых вопроса, разработчик спросил об API key и о возможности начать Milestone 2. Координатор счёл неподтверждённые значения "accepted for the start" и запустил агента, реализовавшего постоянно работающий cron adapter, — хотя прежде советовал иначе. В другом разговоре координатор отрицал получение уже выполненной им передачи от воркера и записал эту ложную историю в папку контекста как правило процесса.

Отчёт Leonhardt посвящён соло-Projects, но в Multiplayer агенты всех коллег читают и записывают /cursor/stores/self. Поэтому загрязнённая заметка или непроверенное предположение агента способны повлиять на любого агента команды, который позже прочитает общее хранилище. После запуска Multiplayer разработчик @avisinghdotdev написал в X:

"Честно говоря, мне не нравится идея, что агент общается с агентом моего коллеги, особенно если у них разные наборы правил и навыков. Один некачественный результат может снизить общее качество." — @avisinghdotdev

Рекомендуемое правило для Multiplayer Projects: не позволяйте координаторам использовать один изменяемый Markdown-файл в /cursor/stores/self одновременно как черновик и журнал решений. В правилах Project разделите состояние на два файла:

1. Изменяемый plan.md для статуса задач и указателей на активные ветки.
2. Закоммиченный в репозиторий decisions.md с append-only правилом для агентов. Для строгого контроля его можно подкрепить проверкой Git diff или защитой ветки. Записывайте date, decided_by (human:@handle или agent:proposed), status (proposed, accepted, superseded), applies_to (glob пути файлов) и однострочный rationale.

Устаревшие checkout'ы, несовпадения Cloud MCP и передача в локальные worktree

Вторая группа проблем беты связана с облачной архитектурой Cursor по умолчанию. Проверенные отзывы пользователей в Day 7 Cursor Projects receipt и тредах r/cursor указывают на четыре ловушки для команд, внедряющих Projects:

1. Устаревшие Git checkout'ы в долгоживущих Projects: долгоживущий облачный Project не подтягивает автоматически изменения, смерженные в main (отчёт Day 7 R1). Сотрудники Cursor подтвердили, что это ожидаемое поведение, и посоветовали явно попросить координатора выполнить pull. В Multiplayer всегда указывайте координатору запускать git pull перед делегированием новых задач.
2. Загрузка MCP-серверов только из облака: координатор работает как Cloud Agent и читает только серверы Model Context Protocol (MCP), настроенные в cloud settings Cursor (отчёт Day 7 R6). MCP-серверы, добавленные лишь в локальном desktop-редакторе, координатор Project не загрузит.
3. Ловушка переключателя «No self-hosted workers available»: чтобы запускать локальные тесты из облачного Project, включите Remote Control — локальные self-hosted workers — в Settings > Agents, затем выполните agent login и agent worker start в корне репозитория. Но включение Remote Control может также включить Self-hosted Machines и параметр Require Self-hosted Machines and Personal Machines в панели команды. Он блокирует работу Cloud Agents и Projects в облаке Cursor. Администраторам команды следует отключить этот параметр Require, чтобы сохранить гибридный режим cloud/local.
4. Расход cloud-токенов: запуск 10–20 параллельных облачных субагентов быстро расходует лимиты тарифа. Как написал пользователь r/cursor u/Shirc на Reddit:

"У Projects есть потенциал, но сейчас это немного хаос, и они совершенно точно будут активно расходовать токены." — u/Shirc в r/cursor

Чтобы контролировать расход токенов, в том же треде r/cursor разработчик u/dryu12 рекомендует назначить Composer моделью координатора и явно прописать правила, каким моделям достаются те или иные делегированные задачи. Если команда также использует внешних ботов ревью CI или собственные агентские скрипты за пределами биллинга Cursor, можно проводить их API-вызовы через AIReiter. Так на одном pay-as-you-go балансе сочетаются недорогие модели наподобие DeepSeek V4.1 Flash и ревьюеры вроде Claude Opus 5.5.

Коллизии на ревью PR: почему у каждого pull request должен быть один владелец

Согласно документации Cursor Projects о подписках, после появления хотя бы 1 подписки — на канал Slack, активность PR, запуски CI в ветке или расписание вроде every day at 8:00 AM — над полем ввода чата появляется индикатор Listening.

В трёхдневном соло-тесте Leonhardt обработка ревью PR уже была неоднозначной: на события ревью могли реагировать координатор, исходный агент-исполнитель и новые агенты исправлений. В одном PR координатор дважды спрашивал автора об исправлениях, которые исходный агент уже вносил. В другом случае 3 агента переписали один файл статуса, оставив в нём неверного автора.

Если несколько коллег запускают координаторов в одном репозитории, подписка нескольких координаторов на широкие события PR по всему репозиторию увеличивает риск дублирующих коммитов с исправлениями и напрасно потраченных облачных ходов. Как отметил в X разработчик @LabubuNoBB:

"Сложность никогда не была в том, чтобы заставить агентов разговаривать. Сложность — решить, кому что принадлежит, когда двое хотят изменить один и тот же файл." — @LabubuNoBB

Рекомендуемое правило владения PR: назначайте на общем Task Board одного владельца-человека и одного выделенного агента на каждый PR, включая ответственность за все комментарии ревью в этой ветке. Подписки координатора каждого участника ограничивайте его собственными PR, а не wildcard-событиями всего репозитория.

Когда делить Project с командой, а когда оставить отдельные чаты

Перед переносом процесса команды в общий Cursor Project сопоставьте структуру задач с ограничениями, подтверждёнными в бете 3.26.13+: