Рубрика: linux

История о том, как я запускал 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 — вы знаете, в какие папки идти и какие хэши проверять. Прорвемся! 🚀

Mongod через systemd на Debian (wsl)

Решил я как-то перевести свой MongoDB под локальным wsl на нормальные рельсы — чтобы управлялся через service, статус показывал, логи в journald писал, и вообще как у людей. До этого я его запускал вручную: 

mongod --config /etc/mongod.conf --fork --logpath /var/log/mongodb/mongod.log

Работало, но статус непонятно какой, и каждый раз при старте системы нужно было не забыть запустить. Неудобно.

Думаю: сейчас сделаю sudo systemctl enable mongod, потом sudo systemctl start mongod, и живи спокойно. Ага, щас.

Первая попытка — фиаско с логами

Запускаю 

sudo systemctl start mongod

Смотрю статус — failed. 

sudo systemctl status mongod

Вижу какую-то кракозябру: code=exited, status=1/FAILURE. Непонятно, лезу в полный лог сервиса: 

sudo journalctl -u mongod -n 30

А там чётко написано:

Failed to open /var/log/mongodb/mongod.log

Ну, думаю, классика. Раньше я запускал mongod от своего пользователя, и файл лога создался с правами seligoroff:seligoroff. А сервис пытается работать от пользователя mongodb. Он туда просто не может писать.

Исправляю:

sudo chown -R mongodb:mongodb /var/log/mongodb

Отлично, думаю, теперь-то всё поедет.

Снова 

sudo systemctl start mongod

Смотрю статус — опять failed, но теперь ошибка status=14. И в journalctl — пусто, даже фатальной строки нет. Странно.

Вторая попытка — ошибка стала загадочной

status=14— что за зверь? Гуглю, нахожу что-то про проблемы с доступом к данным или сокетам. Проверяю /var/lib/mongodb — права все на mongodb, lock-файла нет. 

sudo netstat -tulpn | grep 27018

Порт 27018 свободен. Ничего не горит.

Тогда решаю пойти старым дедовским способом — запустить mongod вручную, но от того же пользователя, от которого работает сервис, и без –fork, чтобы все ошибки вывалились в консоль.

Пишу:

sudo -u mongodb mongod --config /etc/mongod.conf

И… тишина. Просто возвращает управление. Процесса нет. Что за чертовщина?

Тогда добавляю –fork и временный лог-файл:

sudo -u mongodb mongod --config /etc/mongod.conf --fork --logpath /tmp/mongod_manual.log

Вижу сообщение: child process failed, exited with 1. И совет — запустить без –fork. Понял, ловлю ошибку в логе:

sudo cat /tmp/mongod_manual.log

И тут — бинго! Среди обычных строк вижу:

Failed to unlink socket file /tmp/mongodb-27018.sock: Operation not permitted

Вот оно что! Оказывается, когда я раньше запускал mongod от своего пользователя, он создал в /tmp сокет-файл mongodb-27018.sock. А теперь сервис от пользователя mongodb пытается его удалить при старте, но у него прав нет. И тихо падает.

Решение — пять секунд

Удаляю этот бедный сокет ручками:

sudo rm -f /tmp/mongodb-27018.sock

Запускаю сервис:

sudo systemctl start mongod

Смотрю статус:

● mongod.service - active (running)

Ура! Заработало.

Что я вынес из этого

  • Если сервис падает с непонятным кодом — запускай процесс вручную от того же пользователя, под которым работает сервис, и без демонизации (–fork). Увидишь всю подноготную.
  • Не забывай про временные файлы. Сокеты в /tmp — тоже часть состояния, и они могут оставаться от прошлых запусков от другого юзера.
  • Права на логи — это только полбеды. Проверяй всё: и данные, и сокеты, и lock-файлы.

Теперь мой MongoDB стартует через systemd, логи пишет куда надо, и я наконец-то могу делать sudo systemctl status mongod и видеть, что всё ок. Спокойствие, только спокойствие.

Копия файла с расширением txt

Для работы с анализаторами кода мне понадобилось часто копировать файлы с кодом в файлы с расширением txt, так как какие-то расширение анализатор не принимал. Чтоб не делать ручную работу в несколько этапов добавил алиас cptxt

echo "alias cptxt='f(){ local src=\"\$1\"; local dest=\"\$2\"; local fname=\$(basename \"\$src\"); cp -v \"\$src\" \"\$dest/\${fname}.txt\"; }; f'" >> ~/.bashrc

source ~/.bashrc

Поднимаем 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

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