История о том, как я запускал Cursor IDE внутри WSL, или Почему разработчики иногда живут с «одной почкой»

Пост боли, упорства и технического детектива. Если вы решили перейти на модный Cursor IDE (умный форк VS Code с прокачанным ИИ) и работаете на Windows + WSL (Debian/Ubuntu), этот лонгрид сэкономит вам пару дней жизни и пучок нервных клеток.

Симптомы: Бесконечный спиннер

Все начиналось банально. Запуск Cursor, попытка открыть проект в WSL, и… внизу экрана бесконечно крутится колесо сансары с надписью Opening Remote.... Панель проекта пустая, терминал лежит, ИИ молчит.

Акт 0. Безрезультатный бой с тенью

Note: Можете не читать эту часть, в ней я беспомощно делаю безрезультатные шаги. Хотите сэкономить время, переходите к следующей главе.

Сперва сделал пару бесполезных по сути действий. Закрыл Cursor, открыл powershell

wsl --shutdown

Открыл Cursor. Не помогло.

Закрыл Cursor. Открыл шелл Debian.

rm -rf ~/.cursor-server

Открыл Cursor – безрезультатно.

Из каких-то бесед с LLM вышел на то, что Cursor сохраняет состояния путей окон и путей. Если сессия зависла, он может бесконечно пытаться ее восстановить.

Закрыл Cursor.

Win + R

Открыл %APPDATA%\Cursor\User\workspaceStorage

Удалил все имеющиеся папки.

Запустил Cursor – безрезультатно.

Акт 1. Война клонов и баг обратной совместимости

Вслепую вопрос не решить, подумал я, нужны логи.

Вызвал комбинацию Ctrl+Shift+P и нашел Developer: Show Logs -> Remote - WSL. Началось расследование.

Первая строчка в логах кричала об ошибке ENOENT — Cursor не мог найти исполняемый файл по пути …\bin\code.

2026-06-23 11:19:09.844 [error] Failed to patch code.sh launcher: Error: ENOENT: no such file or directory, open 'c:\Users\iis\AppData\Local\Programs\cursor\resources\app\bin\code'

Причина: Cursor — это форк VS Code. При миграции он подтянул старые настройки, и его внутренний скрипт установки сервера пытался найти бинарник code (от оригинального VS Code). А в Cursor этот файл называется cursor! Скрипт падал, а IDE уходила в бесконечный цикл.

Решение: обманул систему, вручную создав пустой файл-пустышку с именем code в системной папке Cursor на Windows.

C:\Users\iis\AppData\Local\Programs\cursor\resources\app\bin\

Ошибка ушла, но спиннер продолжил крутиться.

Акт 2. Великий китайский файрвол и проклятие Cloudflare

Логи двинулись дальше. Теперь Cursor пытался установить серверную часть (cursor-server) внутрь самого Linux. Но процесс намертво засыпал на строке: your 131072×1 screen size is bogus. expect trouble

2026-06-23 11:23:41.317 [info] Resolving wsl remote authority 'wsl+debian' (attempt #1)2026-06-23 11:23:41.323 [info] Installing cursor-server with options: {"id":"4de876585b5ecfb7db14b9aa","commit":"e56ad3440df06d22ca7501e65fd518e905486ef0","line":"production","realCommit":"e56ad3440df06d22ca7501e65fd518e905486ef7","extensionIds":[],"serverApplicationName":"cursor-server","serverDataFolderName":".cursor-server","forceReinstall":true,"killRunningServers":false,"host":"127.0.0.1"}2026-06-23 11:23:41.400 [info] [wsl exec: installServerScript][stderr]: your 131072x1 screen size is bogus. expect trouble

Это древний баг терминала Windows, из-за которого скрипт не может определить размер экрана и не показывает прогресс-бар. Из-за этого автоматика Windows сдавалась и запускала «запасной сценарий» — скачивание архива силами самой Windows во временную папку %TEMP%. И тут мы упёрлись в глухую стену: скорость скачивания упала до нуля, а ide оптимистично прогнозировала время загрузки в 6 дней. Сервера обновлений Cursor защищены Cloudflare, которая нещадно режет или блокирует прямой трафик из РФ без VPN.

Акт 3. Магия хэшей

Решил установить сервер вручную, скачав его через браузер с VPN. И вот тут начался самый сок — квест с именами папок. Внутри WSL Cursor хранит свои бинарники в директории ~/.cursor-server/bin/. Но он не просто сваливает их туда, а ищет строго определенные папки. Почему они называются, например, e56ad3440df06d22ca7501e65fd518e905486ef0?

Идентификатор коммита (Commit ID): Каждая конкретная сборка Cursor жестко привязана к хэшу коммита в Git, на котором она была скомпилирована. Версия сервера Linux должна символ в символ совпадать с версией программы на Windows.
Игры регистров (Debian vs debian): Когда распаковывал сервер в папку одного коммита, Cursor при запуске из Windows внезапно сходил с ума. При открытии корня WSL он видел дистрибутив как wsl+Debian (с большой буквы), а при попытке открыть конкретный проект переключался на wsl+debian (с маленькой буквы).
Из-за разницы в одну букву Cursor считал, что это совершенно другая ОС, включал режим "forceReinstall": true и сносил всё, что мы сделали, пытаясь заново скачать файлы через заблокированную сеть!

Как мы это победили:
Я выяснил точные хэши версий из логов, скачал через браузер с VPN правильный архив cursor-reh-linux-x64.tar.gz, закинул его в Linux и распаковал сразу в две папки (под оба хэша, которые требовала ide), создав там маркеры успешной установки — пустые файлы с именем 0.

Хэппиэнд!

После включения системного VPN на ноутбуке и ручной раскладки бинарников по хэш-папкам Cursor наконец-то выплюнул в логи заветное:
Successfully connected to Cursor server at http://127.0.0...Флаг переустановки сменился на forceReinstall: false. Теперь проект стартует за полсекунды. Да, в логах всё ещё проскакивает косметическое предупреждение screen size is bogus [info]. Но, как говорится, увы, исправить это не удалось, но буду с этим жить — живут же люди с одной почкой! Главное, что код пишется, файлы на месте, а ИИ-ассистент работает на полную мощность. Если у кого-то завис Cursor на WSL — вы знаете, в какие папки идти и какие хэши проверять. Прорвемся! 🚀