Рубрика: wsl

История о том, как я запускал 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?

  1. Идентификатор коммита (Commit ID): Каждая конкретная сборка Cursor жестко привязана к хэшу коммита в Git, на котором она была скомпилирована. Версия сервера Linux должна символ в символ совпадать с версией программы на Windows.
  2. Игры регистров (Debian vs debian): Когда распаковывал сервер в папку одного коммита, Cursor при запуске из Windows внезапно сходил с ума. При открытии корня WSL он видел дистрибутив как wsl+Debian (с большой буквы), а при попытке открыть конкретный проект переключался на wsl+debian (с маленькой буквы).
  3. Из-за разницы в одну букву 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 — вы знаете, в какие папки идти и какие хэши проверять. Прорвемся! 🚀

Поднимаем PHP/Nginx под WSL(Ubuntu)

Устанавливаем nginx

sudo apt install nginx

По умолчанию создается конфигурация с пользователем www-data. Меняем его на текущего пользователя. 

sudo sed -i 's/www\-data/seligoroff/g' /etc/nginx/nginx.conf

Устанавливаю php

sudo apt install php7.4
sudo apt install php7.4-dev
sudo apt install php7.4-mysql
sudo apt install php7.4-zip
sudo apt install php7.4-fpm

По умолчанию php-fpm тоже сконфигурирован для пользователя www-data. 

seligoroff@NB-SELIVANOV:~$ grep www-data /etc/php/7.4/fpm/pool.d/www.conf
user = www-data
group = www-data
listen.owner = www-data
listen.group = www-data

Заменяем на текущего пользователя.

sudo sed -i 's/www\-data/seligoroff/g' /etc/php/7.4/fpm/pool.d/www.conf

Запускаем сервисы 

sudo service php7.4-fpm start
sudo service nginx start

Создаю laravel-проект.

composer create-project laravel/laravel mylaravel

Генерируем ключ приложения

cd mylaravel/
php artisan key:generate

Создаем конфигурационный файл /etc/nginx/sites-available/test.conf

server {
    listen 80;
    root /home/seligoroff/mylaravel/public;
    index index.php index.html index.htm index.nginx-debian.html;
    server_name test.test;

    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Content-Type-Options "nosniff";

    index index.php;

    charset utf-8;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_buffering off;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

Добавляем конфиг в используемые и рестартуем nginx:

sudo ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled/
sudo service nginx restart

На windows добавляем в файле hosts 

127.0.0.1 test.test

Заходим в браузере под указанным доменом: