Куда устанавливать расширения VS Code при работе с WSL

Почему расширения делятся на Local и WSL

При WSL-подключении VS Code запускает серверную часть в Linux. Расширение, которое анализирует код через Linux-интерпретатор, компилятор или утилиту, должно видеть их именно там. В то же время темы, часть интерфейсных дополнений и некоторые клиентские функции работают локально. VS Code сам маркирует место установки и для подходящих расширений предлагает действие вроде «Install in WSL».

Совет: Проверяйте место установки прямо в WSL-окне VS Code: это надёжнее, чем ориентироваться на общий список расширений из обычного окна.

Как решить, где ставить конкретное расширение

1. Откройте проект через WSL и убедитесь, что окно действительно подключено к Linux-среде.
2. Перейдите в Extensions и найдите нужное дополнение; посмотрите, где оно уже установлено — Local или текущий WSL-дистрибутив.
3. Если расширение использует `python`, `node`, `gcc`, `git` или другой Linux-бинарник проекта, установите его также в WSL, когда VS Code предлагает такую кнопку.
4. Перезагрузите окно редактора после установки и откройте Output или журнал расширения, если оно не активировалось.
5. Проверьте выбранный интерпретатор/SDK и выполните его версию во встроенном WSL-терминале, чтобы исключить смешение окружений.

Предупреждение: Не добавляйте Windows-пути к Linux-инструментам только ради запуска расширения — сначала установите нужный runtime в WSL.

Быстрая проверка места установки

• В панели Extensions видно, в каком окружении находится дополнение.
• Расширение находит тот же runtime, который доступен из WSL-терминала.
• Путь к проекту и путь к инструментам относятся к одному окружению.
• Нет бессмысленной установки всех расширений сразу и в Windows, и в WSL.

Важно: Критерий результата: Расширение активно в нужном extension host, видит Linux-зависимости проекта и не сообщает об отсутствующем runtime из-за смешения Windows и WSL.

Почему не нужно ставить всё дважды

Универсального правила «всё ставить дважды» нет. Место зависит от архитектуры конкретного расширения. Если расширение работает с удалённой файловой системой, его серверная часть обычно должна находиться в WSL; если оно меняет только внешний вид клиента, Linux-копия может быть не нужна. При сомнении используйте подсказку самого VS Code в удалённом окне. Проверяйте не название расширения, а место выполнения его кода. Если расширение должно запускать `python`, `node`, `git`, компилятор или читать Linux-сокет, установите серверную часть в WSL и убедитесь, что она видит бинарник через встроенный терминал. Если дополнение отвечает только за тему, иконки или интерфейс редактора, отдельная WSL-копия обычно не требуется. Это помогает избежать двух расходящихся наборов настроек.

Как найти ошибку размещения расширения

Откройте Extensions и проверьте, где числится проблемное дополнение: Local или ваш WSL-дистрибутив. Затем выполните его основную функцию — например, выберите Linux-интерпретатор или запустите линтер из проекта. Если расширение видит только Windows-пути, переустановите его в WSL через предложенную VS Code кнопку, а не копируйте файлы вручную.

Что учитывать

При WSL-подключении VS Code запускает серверную часть в Linux. Расширение, которое анализирует код через Linux-интерпретатор, компилятор или утилиту, должно видеть их именно там. В то же время темы, часть интерфейсных дополнений и некоторые клиентские функции работают локально. VS Code сам маркирует место установки и для подходящих расширений предлагает действие вроде «Install in WSL».

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Get started using VS Code with WSL). Пример и формулировки — редакция N1RO на 2026-09-22.

• Get started using VS Code with WSL