Синхронизация Codex и Cursor: как работать в одном проекте без потери кода

Короткий ответ на 6 сентября 2026 года: Codex и Cursor можно связать через общий Git-репозиторий, AGENTS.md, совместимые skills и одинаковые MCP-серверы, но у них нет единого двустороннего live-чата, общего аккаунта или универсального файла настроек. MCP (Model Context Protocol) — протокол подключения модели к внешним инструментам и данным. Для последовательной работы достаточно одного checkout, то есть рабочей копии репозитория, и правила «в каждый момент пишет один агент». Для параллельной работы создайте отдельную ветку и Git worktree каждому агенту, а результат передавайте через commit, branch, pull request или проверенный patch.

У Codex есть официальный импорт поддерживаемых настроек и недавних чатов из Cursor. В desktop app можно включить автоматическое обновление импортированной копии. Это полезно при переходе или первичной настройке, но не превращает два продукта в общий сеанс: обратная синхронизация в Cursor, единый контекстный буфер и совместное продолжение одного активного диалога не заявлены.

Что может означать синхронизация

Словом «синхронизация» называют несколько разных задач. Если их смешать, легко ожидать, что перенос ветки автоматически перенесет чат, токен MCP и локальную базу данных. Git управляет кодом и историей. Агентские инструкции, авторизации и runtime-state живут в других слоях.

Что нужно синхронизировать	Рабочий способ	Что произойдет автоматически	Чего ожидать нельзя
Отслеживаемый код	Один Git repository, branches, commits, pull requests	Оба инструмента увидят состояние открытого checkout	Git не объединит конфликтующие правки по смыслу
Незакоммиченные tracked-файлы	Один checkout последовательно; между worktrees — commit или patch	В одном каталоге изменения видны сразу	Между разными worktrees черновик сам не появится
Untracked и ignored-файлы	Явный список, отдельная безопасная копия, setup script	Ничего, если файл не отслеживает Git	.env, SQLite, uploads и build cache не входят в обычный commit
Проектные инструкции	Корневой и вложенные AGENTS.md	Codex и Cursor могут прочитать их из repo	Cursor-метаданные .mdc не становятся правилами Codex
Cursor Rules	.cursor/rules/*.mdc	Работают в Cursor по globs, description и режиму применения	Codex не обязан читать эту папку
Skills	Репозиторные .codex/skills/<name>/SKILL.md	Cursor поддерживает чтение Codex skill directories	Поведение всех полей и скриптов нужно проверить в обоих клиентах
MCP-серверы	Два конфигурационных представления одного сервера	Один remote endpoint может обслуживать оба клиента	OAuth, токены, approvals и tool allowlists не становятся общими
Plugins	Отдельная установка совместимого plugin package	Portable-компоненты могут переиспользоваться	Установка в Cursor не устанавливает plugin в Codex и наоборот
Terminal и CLI	Одинаковый runtime на конкретном checkout	Команды работают с теми же файлами	PATH в GUI, PowerShell, WSL и container может отличаться
Чаты и задачи	Codex import from Cursor или handoff-summary	Codex импортирует поддерживаемые recent chats	Нет общего активного thread и обратной live-записи в Cursor
Модель, аккаунт, подписка	Вход и выбор модели в каждом продукте отдельно	Ничего между поставщиками	OpenAI-модель в Cursor не связывает Cursor plan с ChatGPT/Codex
Cloud agents	Remote branch/commit/PR	Cloud agent получит отправленное состояние Git	Он не видит локальный .env, uncommitted diff и localhost без настройки

Эта матрица дает полезное правило: для каждой сущности нужен свой канал. Код передается Git, договоренности — текстовыми файлами, внешние инструменты — MCP-конфигурацией, секреты — менеджером секретов, а контекст задачи — чатом, issue или кратким handoff.

Какую схему выбрать

Ситуация	Схема	Почему она подходит
Вы один, задачи короткие и идут по очереди	Codex extension внутри Cursor и один checkout	Минимум переключений, один diff и один dev server
Codex и Cursor должны писать параллельно	Два worktrees и две ветки	Файлы, index и HEAD физически разделены
Один агент локальный, другой облачный	Branch + commit + push + PR	Облако получает воспроизводимый снимок, review остается в Git
Нельзя создавать промежуточный commit	Binary patch с предварительной проверкой	Можно передать tracked-черновик без изменения истории
Нужно перенести прежние правила и чаты Cursor в Codex	Встроенный import Codex	Поддерживаемые элементы преобразуются и проверяются в одном flow
Нужно постоянно держать два продукта одинаковыми	Git для переносимых файлов плюс явная карта локальных настроек	Исключает ложное ожидание «магической» синхронизации всего состояния

Самая надежная схема для большинства разработчиков проста: общие правила и scripts хранятся в репозитории, активная работа идет в отдельных ветках, секреты остаются вне Git, а каждый merge проходит review и тесты.

Один checkout: простой режим для последовательной работы

Codex IDE extension можно использовать прямо в Cursor как в совместимом редакторе. На одном экране будут код, diff, Cursor Agent и панель Codex. При этом агенты остаются независимыми: у них разные диалоги, модели, permissions и внутренний контекст. Читать полный обзор сервиса Cursor

Главное ограничение — в один момент времени должен писать только один агент. Если Codex и Cursor одновременно меняют один файл, один процесс может перечитать устаревшую версию и затереть часть нового текста. Git покажет конечный diff, но не восстановит автоматически промежуточное состояние, которое ни разу не было сохранено.

Проверьте рабочую точку

Перед передачей управления выполните в терминале проекта:

git rev-parse --show-toplevel
git branch --show-current
git status --short --branch
git diff --stat
git diff --cached --stat
git ls-files --others --exclude-standard

Команды отвечают на разные вопросы: тот ли открыт repository root, на какой вы ветке, что изменено, что уже staged и какие новые файлы еще не попали в Git. Окно Cursor, панель Codex и терминал должны указывать на один и тот же корень.

Передавайте задачу явным сообщением

Второму агенту нужен короткий контракт:

Цель: исправить валидацию формы регистрации.
Уже изменено: src/auth/schema.ts и тест schema.test.ts.
Не трогать: миграции и package-lock.json.
Проверено: unit-тесты auth проходят.
Осталось: обработать пустой phone и запустить lint.

Такой handoff полезнее полного журнала рассуждений. Он фиксирует текущее состояние, границы и проверку. Для долгой задачи храните его в issue, pull request или task description. Временный файл внутри repo имеет смысл только тогда, когда команда действительно хочет версионировать этот документ.

Зафиксируйте результат перед переключением

После каждого агента:

1. Остановите его run и дождитесь завершения записи файлов.
2. Просмотрите git status, обычный и staged diff.
3. Запустите целевые тесты и formatter, указанные в AGENTS.md.
4. Создайте небольшой осмысленный commit или сохраните patch.
5. Только после этого отдавайте checkout второму агенту.

Один checkout удобен для быстрых правок. Для параллельной разработки, обновления зависимостей, генерации кода или миграций он слишком хрупок.

Отдельные worktrees: безопасная база для параллельных агентов

Git worktree создает еще один checkout того же repository. Worktrees делят object database и refs, но имеют собственные файлы, index и HEAD. Codex и Cursor могут работать в разных каталогах и не перезаписывать один физический файл.

Worktree устраняет столкновение на уровне файлов. Два агента все еще способны по-разному изменить одну функцию, создать несовместимые миграции или обновить один lockfile. Эти конфликты проявятся при cherry-pick, rebase или merge.

Создайте по ветке на агента

Пример для PowerShell, если основной checkout находится в каталоге project:

git status --short --branch
git fetch --all --prune
git worktree add -b ai/codex "..\project-codex" main
git worktree add -b ai/cursor "..\project-cursor" main
git worktree list

Перед fetch и созданием worktrees убедитесь, что текущие изменения уже сохранены. Вместо main укажите точную общую базу. Не используйте -B и --force для обхода ошибки: они могут сбросить существующую ветку или отключить защиту Git.

Одна локальная ветка не может быть checked out сразу в двух worktrees. Сообщение fatal: '<branch>' is already used by worktree означает, что нужно создать другую ветку, перейти в существующий checkout или отсоединить HEAD. Принудительный checkout не является исправлением.

Если долгоживущий worktree расположен на съемном диске или временно недоступном пути, Git позволяет защитить его от автоматического prune и перемещения:

git worktree lock "..\project-codex" --reason "active Codex task"

Эта блокировка защищает запись Git о worktree, но не запрещает агентам менять его файлы и не координирует dev servers, базы или редакторы. Автоматическая очистка managed worktrees в Codex или Cursor тоже не должна быть единственной системой хранения: важный результат сначала зафиксируйте в commit, branch или patch.

Разделите не только исходники

У каждого worktree должны быть собственные изменяемые runtime-ресурсы:

Ресурс	Codex worktree	Cursor worktree	Зачем разделять
Ветка	ai/codex	ai/cursor	Понятное авторство и merge
Порт frontend	3101	3102	Два dev servers не спорят за socket
Порт backend	4101	4102	Логи и health-check относятся к нужной ветке
Database	app_codex_dev	app_cursor_dev	Миграция одного агента не ломает среду второго
Docker Compose project	app-codex	app-cursor	Имена containers, networks и volumes не совпадают
Temp/cache	Каталог внутри первого worktree	Каталог внутри второго worktree	Build cache и PID-файлы не перезаписываются
.env.local	Своя локальная копия	Своя локальная копия	Можно задать разные ports и database URL

node_modules, virtualenv, .next, dist и другие ignored-каталоги обычно придется создать отдельно. Символическая ссылка на одну изменяемую папку уничтожает значительную часть изоляции. Общий read-only cache допустим, если package manager официально поддерживает конкурентный доступ.

Назначьте владельцев конфликтных областей

До старта разделите зоны работы. Например, Codex меняет API и тесты, Cursor — интерфейс. Если обе задачи требуют package.json, lockfile, ORM schema или сгенерированного клиента, назначьте одного владельца этих файлов. Второй агент применяет результат после первого merge и заново запускает генератор.

Для database migrations безопаснее:

• выдать каждому worktree отдельную development database или schema;
• не запускать destructive migration на общей базе;
• просмотреть SQL до применения;
• договориться, кто создает окончательную migration sequence;
• после merge поднять чистую тестовую базу и прогнать миграции с нуля.

Возвращайте изменения через Git

Когда агент закончил:

git status --short
git diff --check
git add -p
git commit -m "fix: validate registration phone"

В integration checkout обновите базу и примените commit:

git switch integration
git cherry-pick <commit-sha>

Для большой серии изменений удобнее merge или pull request. После первого merge перебазируйте вторую ветку на свежую базу и снова выполните тесты. Не считайте отсутствие текстовых conflict markers доказательством совместимости: два корректно применившихся патча могут менять одну бизнес-логику противоположными способами.

Передача через commit, branch или patch

Commit и branch как основной контракт

Commit переносит tracked-файлы, информацию о базовом состоянии и понятный набор изменений. Он легко просматривается, применяется, отменяется и восстанавливается через reflog. Временный commit на выделенной branch безопаснее безымянного stash, если команда не требует идеально чистой истории на каждом промежуточном шаге.

Рабочая последовательность:

1. Проверьте diff и уберите случайные файлы.
2. Добавьте только относящиеся к задаче hunks и новые файлы.
3. Запустите проверки.
4. Создайте commit с описанием результата и известных ограничений.
5. Передайте branch name и commit SHA второму агенту.
6. Примените commit в чистом checkout и повторите проверки.

Если задача уходит в Codex Cloud или Cursor Cloud Agent, commit и push становятся обязательной границей. Облачная среда клонирует remote repository и не получает ваш локальный uncommitted diff.

Patch для незакоммиченного черновика

Patch нужен, когда создавать commit пока нельзя. Сначала пометьте нужные новые файлы как intent-to-add, чтобы они попали в diff:

git add -N path\to\new-file.ts
git diff HEAD --binary --no-ext-diff > "..\codex-cursor-handoff.patch"

Перейдите в чистый целевой checkout, затем изучите и проверьте применимость patch без записи:

git apply --stat "..\codex-cursor-handoff.patch"
git apply --check "..\codex-cursor-handoff.patch"

Только после успешного --check применяйте patch в целевом checkout:

git apply --3way "..\codex-cursor-handoff.patch"
git status --short

--binary сохраняет binary diffs, а --3way использует сведения о базовых blobs, если они доступны. Patch не переносит ignored-файлы, права внешних сервисов, процессы, database state и содержимое terminal session. Храните файл patch вне repository и удаляйте только после проверки результата и создания commit.

Почему stash хуже для передачи между агентами

Stash полезен для короткой локальной паузы, но список stash общий для repository. Несколько worktrees могут создать записи, которые легко перепутать. git stash push -u добавляет untracked-файлы, а ignored-файлы появляются только с более широким -a, что повышает риск захватить .env, локальную базу или тяжелый cache.

Если stash неизбежен, дайте ему уникальное имя, сначала используйте apply, проверьте результат и только затем удаляйте запись. Автоматический pop совмещает применение и удаление, поэтому хуже подходит для критического handoff.

Общие инструкции без дублирования правил

Cursor поддерживает корневые и вложенные AGENTS.md, а Codex строит из них цепочку инструкций от repository root к текущему каталогу. Поэтому AGENTS.md — лучший общий формат для правил, которые должны видеть оба агента.

Хороший общий файл содержит только устойчивые сведения:

## Repository map

- Web app: apps/web
- API: apps/api
- Database migrations: packages/db/migrations

## Commands

- Install: pnpm install --frozen-lockfile
- Unit tests: pnpm test
- Lint: pnpm lint

## Safety

- Do not edit production secrets.
- Do not run destructive migrations against shared databases.
- Do not regenerate the lockfile unless the task changes dependencies.
- Before handoff, report changed files, tests, ports and migrations.

Вложенный AGENTS.md нужен, когда у package или service свои команды. Не копируйте туда весь корневой файл: зафиксируйте только уточнения. После изменения инструкций начните новый run/chat, потому что агент может загрузить guidance один раз при старте сессии.

Где оставить специфические настройки

Файл или поверхность	Что хранить	Кто использует
AGENTS.md	Архитектура, команды, границы, проверки, ownership	Codex и Cursor
.codex/skills/<skill>/SKILL.md	Переносимый пошаговый workflow и references	Codex; Cursor поддерживает этот skill location
.cursor/rules/*.mdc	Cursor-only globs, manual/always apply, descriptions	Cursor
.cursor/worktrees.json	Setup commands для Cursor worktrees	Cursor
.codex/config.toml	Project-scoped Codex defaults и MCP для trusted repo	Codex
CI configuration	Форматирование, тесты, schema checks, policy enforcement	Оба агента и люди

Не заставляйте текстовые инструкции выполнять работу CI. Если формат, generated schema или migration order можно проверить программой, добавьте проверку в pipeline. Оба агента должны получать одинаковый pass/fail, даже если интерпретируют prose по-разному.

Skills, plugins и MCP: переносимость с оговорками

Skills

Cursor умеет находить skills в .codex/skills, поэтому repository skill с SKILL.md, scripts и references можно использовать как общий источник. Проверьте три вещи:

• одинаково ли оба агента распознают trigger description;
• доступны ли упомянутые binaries и paths в их runtime;
• не содержит ли workflow действий, разрешенных в одном продукте и запрещенных approvals другого.

Личные skills из home directory и skills cloud-agent могут синхронизироваться внутри своего продукта, но это не межпродуктовый канал. Для команды храните переносимую часть в Git или публикуйте версионируемый package, а локальные секретные дополнения оставляйте вне repo.

Plugins

Cursor и Codex развивают plugin-системы и поддерживают переносимые компоненты, но установка остается отдельной. Cursor plugin может включать Cursor Rules, subagents и hooks, для которых в Codex нет точного аналога. Codex plugin может содержать connectors или UI, недоступные в IDE extension. Даже совместимый package нужно установить, включить и проверить на каждой поверхности.

Plugin не является способом копировать credentials. После установки внешняя connection может снова потребовать OAuth, admin approval или выбор workspace. Не переносите credential cache и не коммитьте локальные plugin state directories.

MCP configuration mapping

Один MCP-сервер можно подключить к обоим агентам, но конфиги имеют разный синтаксис.

Понятие	Cursor	Codex
Project config	.cursor/mcp.json	.codex/config.toml в trusted project
User config	Cursor user MCP settings	~/.codex/config.toml
Local process	command, args, env	command, args, env/env_vars
Remote server	url	url
Token из environment	${env:SERVICE_TOKEN}	bearer_token_env_var = "SERVICE_TOKEN" или env header mapping
OAuth	Авторизация внутри Cursor	Отдельная авторизация внутри Codex
Ограничение tools	Cursor policy/permissions	Codex enabled/disabled tools и approval modes

Безопасный remote-пример для Cursor:

{
  "mcpServers": {
    "internal-docs": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SERVICE_TOKEN}"
      }
    }
  }
}

Эквивалентная идея для Codex:

[mcp_servers.internal-docs]
url = "https://mcp.example.com/mcp"
bearer_token_env_var = "SERVICE_TOKEN"

В Git можно хранить server name, URL, command, безопасные args и имена переменных. Значения токенов остаются в OS credential store, secret manager, shell profile или настройках cloud environment. После изменения конфигурации перезапустите MCP connection или новую agent session и проверьте список доступных tools чтением, прежде чем разрешать write-операции.

История чатов, аккаунты и настройки

Официальный импорт из другого агента переносит из Cursor в Codex поддерживаемые инструкции, settings, skills, plugins, project folders, recent chats, MCP, hooks, slash commands и subagents. В Codex CLI команда /import может взять до 50 чатов за последние 30 дней; desktop app позволяет включить automatic updates импортированного состояния.

Эта функция решает миграцию и повторное чтение источника. У нее есть границы:

• импорт идет из Cursor в Codex, обратное направление официально не описано;
• активный чат не превращается в один совместный thread двух приложений;
• selected files, временный terminal output, process state и скрытый model context могут не переноситься;
• MCP auth, custom headers, hooks и path placeholders требуют проверки;
• imported configuration может сохранить смысл не полностью, если Cursor rule использовал globs или специфический hook.

Для надежного продолжения задачи передавайте summary, branch, commit SHA, команды проверки и открытые вопросы. Импортированный чат полезен как справка, но текущий Git state остается источником истины для кода.

Аккаунты также разделены. Codex использует вход ChatGPT или OpenAI API key, а Cursor — собственный account и billing. Выбор OpenAI-модели в Cursor означает, что Cursor направляет запрос выбранной модели в рамках своей конфигурации. Он не дает автоматически доступ к Codex Cloud, не переносит ChatGPT plan credits и не объединяет историю.

Настройки делятся на три группы:

• repository settings, которые можно версионировать: AGENTS.md, skills, безопасные MCP endpoints, setup scripts;
• user/editor settings: shortcuts, theme, Cursor behavior, Codex chatgpt.*, локальный config.toml;
• managed/cloud settings: team policies, model access, network, secrets, OAuth и spend limits.

Синхронизируйте первую группу через Git. Вторую документируйте или экспортируйте только при необходимости. Третью настраивайте в каждой административной плоскости отдельно.

Env, secrets и gitignored state

В одном checkout оба локальных агента видят один файл .env, если их процессы имеют доступ к этому пути. Значения environment variables могут различаться: приложение, открытое из меню Windows, не обязано наследовать переменные позднее запущенного PowerShell; WSL имеет другой environment; container получает только явно переданные значения.

Безопасная схема состоит из четырех слоев:

1. .env.example в Git содержит только имена переменных и безопасные примеры.
2. Настоящие значения хранятся в password manager, OS credential store или secret manager.
3. Локальный setup создает .env.local вне Git для конкретного worktree.
4. Codex Cloud и Cursor Cloud Agent получают отдельные least-privilege secrets через свои панели.

Codex managed worktrees поддерживают .worktreeinclude для явного копирования ignored-файлов. Эта возможность удобна для локального .env.local, но создает еще одну копию секрета на диске и не работает как универсальный механизм для manual или remote worktrees. Не добавляйте широкие шаблоны вроде .env*, если среди файлов есть production credentials.

Перед handoff составьте список локального состояния:

git ls-files --others --exclude-standard
git status --ignored --short
git check-ignore -v .env .env.local data\dev.db

Ignored SQLite database, uploads, local certificates и generated artifacts нужно либо воспроизвести setup-скриптом, либо скопировать отдельно после проверки содержимого. Не включайте их в patch автоматически.

Конфликты, которые worktree не предотвращает

Проблема	Почему возникает	Профилактика	Диагностика и восстановление
Оба агента меняют одну функцию	Отдельные файлы сходятся при merge	Развести ownership и базовые commits	Сравнить три версии, решить конфликт вручную, повторить тесты
Одна branch открыта в двух worktrees	Git защищает один mutable ref от гонки	Одна ветка на checkout	git worktree list, перейти на другую branch
Lockfile конфликтует	Два package-manager run меняют общий граф	Один владелец dependency changes	Принять один lockfile и регенерировать штатной командой
Generated files расходятся	Генераторы или версии runtime различаются	Pin versions и один generation owner	Удалить только воспроизводимый output, запустить generator после merge
Весь файл отмечен измененным	CRLF/LF, formatter или encoding	Репозиторный .gitattributes и единый formatter	Проверить git diff --ignore-space-at-eol только для диагноза, затем исправить EOL policy
Появился вложенный client/client	Редактор открыт в subfolder и неверно разрешил root	Открывать Git root	git rev-parse --show-toplevel, переместить только после review
Пропал .env или local DB	Файл ignored и не вошел в worktree/branch	Setup script и явный secret injection	git check-ignore -v, восстановить из secret manager/backup
Две миграции имеют один порядок	Агенты создают их от одной базы	Один migration owner или уникальные IDs	Rebase, пересоздание migration, прогон на чистой БД
Dev server не запускается	Порт или PID занят другим worktree	Отдельные ports и process names	Найти процесс, проверить cwd, остановить только точный PID
Docker containers смешались	Одинаковый Compose project и volume	Уникальный project name и database volume	Сверить labels/mounts; не удалять общий volume наугад
MCP есть в одном агенте	Разные config, PATH, OAuth или policy	Карта config и отдельный auth check	Перезапустить connection, проверить executable и tool list
Worktree checkout ломается на LFS	В runtime нет git-lfs или filter	Проверять LFS и clean/smudge filters заранее	git lfs version, git lfs status, установить tool в нужной среде
Submodule находится в странном состоянии	Worktree support и submodule checkout сложнее	Явный init/update и отдельная проверка	Сверить recorded commit и dirty state каждого submodule

Line endings на Windows и WSL

Установите policy в .gitattributes, а не только в личном core.autocrlf. Пример:

* text=auto
*.sh text eol=lf
*.ps1 text eol=crlf
*.bat text eol=crlf

После изменения policy не смешивайте нормализацию EOL с функциональным commit. Отдельный commit проще проверить и при необходимости отменить. Если один агент работает в Windows, а второй в WSL, открывайте каждый worktree только из выбранной среды и запускайте formatter там же, где работает проект.

Windows paths, WSL и containers

На Windows заключайте пути с пробелами в кавычки и помните, что backslash внутри JSON нужно экранировать. Проверяйте реальный root командами Get-Location и git rev-parse --show-toplevel. Не зашивайте C:\Users\... в общие scripts, если проект запускается у других разработчиков.

Для WSL выберите одну модель:

• repository и toolchain живут внутри Linux home, оба агента работают через WSL;
• repository живет в Windows, оба агента используют native Windows tools.

Смешанный доступ к одному checkout через C:\... и /mnt/c/... повышает риск проблем с performance, symlinks, permissions, file watchers и EOL. Если нужен и Windows, и Linux runtime, выделите отдельные worktrees и договоритесь о .gitattributes.

В container workflow один Git worktree должен соответствовать одному bind mount и одному Compose project. Не делите изменяемый database volume между агентами. Проверяйте, кому принадлежат созданные файлы: Linux container может оставить UID/GID или permissions, неудобные для Windows/WSL toolchain.

Approvals и облачные агенты

Permissions Codex и Cursor задаются независимо. Разрешение terminal command в Cursor не становится разрешением Codex. MCP tool, одобренный в одном чате, может снова запросить approval в другом клиенте. Team policy способна запретить действие, даже если локальный config его разрешает.

Не пытайтесь «синхронизировать» approvals копированием внутренних state-файлов. Так можно перенести tokens, расширить доверие к незнакомому project или обойти ожидаемый review. Вместо этого храните в AGENTS.md правила безопасности, а technical permissions настраивайте в каждой системе по принципу минимальных прав.

Cloud Agents начинают с remote Git state. Для передачи задачи:

1. Создайте отдельную branch.
2. Зафиксируйте только нужные файлы.
3. Push branch в разрешенный remote.
4. Настройте cloud environment, dependencies, secrets и network access отдельно.
5. Попросите агента вернуть commit или pull request с логами проверок.
6. Просмотрите diff локально и прогоните тесты в доверенной среде.

localhost облачного агента находится внутри его VM или container. Он не указывает на dev server вашего ноутбука. Для закрытого API нужен разрешенный tunnel/private network или test double; для базы — отдельная test instance. Не открывайте production network только ради удобства агента.

Backup и восстановление перед синхронизацией

Сделайте инвентаризацию

git status --short --branch
git diff --stat
git diff --cached --stat
git ls-files --others --exclude-standard
git status --ignored --short
git worktree list

Просмотрите содержимое каждого чувствительного файла до копирования. Наличие .env в ignored-списке подтверждает только то, что Git его не отслеживает; это не backup.

Создайте checkpoint

Лучший checkpoint — отдельная branch и небольшой commit. Добавляйте новые файлы точными path, а tracked hunks — через git add -p. Перед commit обязательно прочитайте staged diff:

git diff --cached
git commit -m "chore: checkpoint before agent handoff"

Если commit запрещен, создайте binary patch и отдельный manifest untracked/ignored state. Секреты копируйте в защищенное хранилище, а локальную базу — штатным dump/backup-инструментом при остановленных writers.

Не удаляйте worktree вслепую

Перед очисткой:

git -C "..\project-codex" status --short
git branch --contains <commit-sha>
git worktree prune -n

prune -n только показывает кандидатов. Удаляйте worktree после того, как изменения находятся в commit, branch или проверенном patch. Не применяйте --force, пока не понятны dirty files и место их резервной копии.

Восстановите потерянный commit

Если branch перемещена или commit больше не виден:

git reflog --date=local
git show <lost-sha>
git branch recovery/<name> <lost-sha>

Сначала создайте recovery branch, затем продолжайте историю. Codex managed worktree может предложить восстановление snapshot после автоматического удаления, но этот механизм относится к Codex и не заменяет Git backup. Для Cursor worktree или ручного каталога рассчитывайте на commit, branch, patch и собственную резервную копию.

Troubleshooting: почему «синхронизация» не работает

Симптом	Что проверить	Безопасное действие
Второй агент не видит изменения	show-toplevel, branch, worktree path, git status	Открыть правильный checkout; передать commit/patch
Git пишет, что branch already used	git worktree list	Работать в указанном worktree или создать новую branch
После apply появился дублированный путь	Открыт ли repository root, не workspace subfolder	Отменить только ошибочный apply после review, открыть root и повторить
Patch не применяется	Совпадает ли base, есть ли staged/local changes	git apply --check; обновить базу или разрешить conflict вручную
New file отсутствует в patch	Он untracked и не был intent-to-add	git add -N <path>, пересоздать и снова проверить patch
.env отсутствует	.gitignore, .worktreeinclude, setup script	Восстановить из secret manager, не из чужого chat log
MCP server не появляется	Config location, JSON/TOML, PATH, transport, OAuth, policy	Проверить tool list и logs; повторно авторизовать exact server
Агент игнорирует новый AGENTS.md	Сессия стартовала до изменения, другой cwd, override	Начать новый run и запросить список загруженных instructions
Cloud agent видит старый код	Branch не pushed или выбрана не та revision	Push exact commit, передать SHA, перезапустить task с нужной base
Огромный diff без смысловых правок	EOL, encoding, formatter version	Проверить attributes и runtime; выделить normalization в отдельный commit
Тесты проходят только у одного агента	Разные env, dependency version, DB, port	Сравнить versions и setup; проверить на чистом environment
Dev server занят	Один port используют два worktrees	Назначить разные ports, остановить только процесс нужного cwd
Миграции расходятся	Общая база или одинаковый sequence	Слить schema changes вручную, пересоздать migration и прогнать с нуля

Вывод

Синхронизация Codex и Cursor надежна, когда у каждого слоя есть понятный источник истины. Git отвечает за tracked-код и историю. AGENTS.md, repository skills и CI задают общие правила. MCP подключается к одному серверу через два проверенных client config. Secrets, approvals, аккаунты и cloud environments остаются раздельными.

Для одного разработчика начните с Codex extension внутри Cursor и последовательной работы в одном checkout. Для параллельных задач выделите по worktree, branch, port и database каждому агенту. Передавайте результат через небольшие commits или проверенный binary patch, а чат сводите к короткому handoff. Встроенный импорт Cursor → Codex ускоряет миграцию настроек и recent work, но не отменяет Git discipline и не создает двусторонний общий контекст.