Cursor построен на основе VS Code, поэтому умеет импортировать настройки, расширения, темы и сочетания клавиш. Возможность приятная, и именно поэтому опасная: вместе с полезным она переносит несовместимые расширения, устаревшие ключи настроек, машинно-специфичные пути и корпоративные ограничения, о которых вы давно забыли. Импорт одним нажатием превращает чистую установку в копию накопленного за годы состояния - со всеми компромиссами, которые вы когда-то принимали по конкретному поводу и давно не пересматривали.
Наивный ход - нажать импорт и радоваться, что всё на месте. Он работает ровно до первой странности: тормозит редактор, конфликтует сочетание клавиш, расширение перехватывает действие, которое вы ждали от Cursor. Дальше начинается неприятное - вы не знаете, что именно перенеслось, и не можете отделить свойство нового инструмента от наследства старого. Диагностика в такой среде дороже, чем аккуратная миграция с самого начала: у вас нет ни одного состояния, про которое вы точно знаете, что оно чистое.
Правильная форма - переносить слоями и проверять после каждого. Сначала тема и сочетания клавиш: это визуальная среда и мышечная память, они почти не несут риска, но сразу делают работу привычной. Здесь же проверяют конфликты - собственные сочетания Cursor и системные могут перехватывать то, к чему вы привыкли. Затем настройки, но только те, смысл которых вы понимаете: редактор, языки, форматирование. Устаревшие ключи и абсолютные пути с чужой машины оставляют позади.
Следующий слой - расширения, и он самый чувствительный. Переносить стоит минимальный рабочий набор, а не весь список: у каждого расширения есть издатель, права и доступ к данным, и в новой среде оно получает те же возможности. Расширение, которое вы поставили когда-то ради одной задачи, продолжает работать и в новом редакторе, а теперь рядом с ним ещё и агент. Список расширений - это часть поверхности доверия, а не деталь оформления.
Полезно один раз увидеть эти слои таблицей: что переносить первым и что проверить на каждом шаге. К этой карте возвращаются при переезде на новую машину: она превращает миграцию из одного нажатия в четыре понятных шага, каждый из которых можно откатить, не разбирая остальные.
| Слой | Что переносить первым |
|---|
| Что проверить |
|---|
| Тема и сочетания клавиш | Визуальная среда и мышечная память | Конфликты с сочетаниями Cursor и системы |
|---|---|---|
| Настройки | Только понятные настройки редактора и языков | Устаревшие ключи, машинно-специфичные пути |
| Расширения | Минимальный рабочий набор | Издатель, подпись, доступ к сети и данным |
| Файлы рабочей области | После открытия реального проекта | Workspace Trust и политика самого репозитория |
Про устаревшие ключи и чужие пути стоит сказать точнее, потому что они вредят молча. Ключ, который в новой версии переименован или больше не поддерживается, не вызывает ошибки - он просто не действует, и вы продолжаете считать, что настройка включена. Абсолютный путь со старой машины ведёт в каталог, которого здесь нет, и функция, привязанная к этому пути, отказывает без внятного сообщения. Признак того, что вы притащили такой мусор, узнаваем: настройка выглядит выставленной, а поведение ей не соответствует. Поэтому переносят понятые ключи поштучно, а не файл настроек целиком.
Файлы рабочего пространства - последний слой, и переносят их только после того, как реальный проект открыт. Причина в том, что workspace-конфигурация задаёт поведение среды в конкретном репозитории и подпадает под доверие рабочего пространства и правила самого репозитория. Пока проект не открыт, вы переносите настройки вслепую, не видя, с чем они складываются. Открытый проект показывает, какие из них вообще нужны: часть окажется наследством давно закрытой задачи, и правильное действие для неё - не переносить.
Для JetBrains путь другой: у Cursor есть отдельная инструкция по переходу, а сама интеграция идёт через протокол общения с агентом: Cursor добавляется провайдером агента в штатный плагин JetBrains, собственного плагина у него нет. Важно не считать эту интеграцию полной копией desktop-приложения - документация обещает многие из тех же возможностей агента, а не все, и набор проверяют на странице интеграции, а не выводят по аналогии с редактором. Ожидание паритета функций между разными клиентами - частый источник разочарования и потерянного времени, а в командной работе ещё и источник несогласованных ожиданий: половина команды считает возможность общей, хотя она есть только у одного клиента.
Инженерный вывод простой: импортируйте не всё как было, а минимальную воспроизводимую среду. Такая среда полезна вдвойне. Она быстрее и предсказуемее, и в ней сразу видно источник проблемы: если странность появилась после включения очередной группы расширений, вы уже знаете, где искать. Восстановить недостающее по мере надобности дешевле, чем вычищать лишнее из работающей среды.
Типичные провалы миграции предсказуемы. Перенести всё разом и потом гадать, что именно мешает. Притащить настройки с абсолютными путями чужой машины. Считать интеграцию с JetBrains полным аналогом desktop-приложения. И оставить в списке расширения, о правах и издателе которых вы ничего не помните.