На момент апреля 2026 года установка и настройка Claude Code на Windows требует внимательного подхода — особенно в профессиональной среде. В команде из девяти человек, работающих с AWS и 150+ аккаунтами, двое используют Windows, включая автора. Опыт эксплуатации Claude Code за год позволил выработать устойчивые практики, актуальные для последних версий (2.1.105+).

Зачем Windows-опыт важен

Несмотря на доминирование Linux в команде, Windows-экспертиза остаётся критичной: отладка Lambda-парсеров для Windows Events, написание и поддержка сложных PowerShell-скриптов, SSM-документов и работа с корпоративными инструментами Azure. Поэтому Claude Code должен работать на Windows стабильно и производительно, даже если основная работа ведётся с Linux-ориентированными окружениями.

Нативная установка на Windows

Установка напрямую в Windows — правильный выбор, если:

• Нужно быстро протестировать Claude Code без сложной настройки
• Работа ведётся с .NET, WPF, WinForms — технологиями, привязанными к Windows API, WMI или реестру
• Основной стек — PowerShell, DSC-конфигурации или SSM-документы с PowerShell
• Используются Azure или другие корпоративные Windows-инструменты
• Требуется воспроизвести баг, специфичный для Windows

Для установки необходимо наличие Git Bash — он используется Claude Code для выполнения команд. Если winget отсутствует, Git можно скачать с официального сайта. При установке достаточно оставить все настройки по умолчанию: Git Bash, интеграция с проводником, добавление в PATH.

PowerShell: 5.1 vs 7+

В Windows по умолчанию установлен powershell.exe — это PowerShell 5.1 на .NET Framework, развитие которого прекращено. Рекомендуется использовать pwsh — PowerShell 7+, кроссплатформенный и активно развиваемый Microsoft. Он устанавливается отдельно, не требует перезагрузки и сосуществует с 5.1 без конфликтов.

Все дальнейшие команды рассчитаны на pwsh. Для удобства рекомендуется Windows Terminal — он позволяет запускать параллельно PowerShell и Linux-сессии в соседних вкладках.

Установка Claude Code

Установщик автоматически скачает бинарник, добавит его в PATH и настроит автообновление. Node.js и npm не требуются. Альтернатива — установка через WinGet:

winget install Anthropic.ClaudeCode

Однако при этом обновления придётся выполнять вручную командой winget upgrade.

Если команда claude не распознаётся, возможно, установщик не прописал PATH или консоль не перезапущена. В этом случае путь можно добавить вручную.

Аутентификация и доступ

Бесплатный план Claude не включает Claude Code. Требуется один из вариантов:

• Claude Pro или Max — личная подписка на claude.ai
• Claude for Teams или Enterprise — корпоративный аккаунт
• Claude Console — аккаунт разработчика с биллингом через API
• Интеграция через облачные платформы: Amazon Bedrock, Google Vertex AI, Microsoft Foundry
• В России в 2026 году официальный доступ отсутствует, но существуют обходные пути

Для большинства пользователей достаточно запустить claude — откроется браузер для входа через claude.ai. Если браузер не открывается, можно нажать c — URL скопируется в буфер, его нужно вставить вручную, войти и вернуть код в терминал.

API-ключ требуется только при использовании Console (биллинг через API). Он задаётся через файл ~/.claude/config или переменную окружения ANTHROPIC_API_KEY.

Важно: если ANTHROPIC_API_KEY задан, он имеет приоритет над подпиской. При устаревании или отзыве ключа аутентификация сломается. Проверить текущий метод можно командой status внутри Claude Code.

Работа с PowerShell в Claude Code

По умолчанию Claude Code использует Git Bash, что вызывает проблемы в PowerShell-проектах: переменные $_, $?, конвейеры — всё ломается из-за предварительной интерпретации в bash.

Начиная с версии 2.1.84, доступно решение — настройка в файле %USERPROFILE%\.claude\settings.json:

• CLAUDE_CODE_USE_POWERSHELL_TOOL=1 — регистрирует PowerShell как отдельный инструмент. Claude Code автоматически определит pwsh.exe (7+) или powershell.exe (5.1).
• "defaultShell": "powershell" — направляет интерактивные команды через PowerShell. Работает только при включённой первой опции.

Git Bash остаётся обязательным — он используется для запуска самого Claude Code. Если Git установлен не в Program Files, путь указывается в CLAUDE_CODE_GIT_BASH_PATH.

Ограничения нативной Windows-установки

Claude Code изначально разработан для POSIX-окружений. На Windows многие механизмы работают с оговорками или не работают вовсе:

• Git Bash не поддерживает extglob — расширенные паттерны имён файлов (например, rm !(*.js)).
• Переменные $_, $?, $! ведут себя иначе, чем в настоящем bash.
• Отсутствуют systemd, cron, inotify.
• Нет поддержки POSIX-сигналов: kill -HUP, SIGUSR1 и другие не работают, так как Windows не поддерживает их на уровне ядра.

Например, при выполнении PowerShell-команд через Git Bash переменные перехватываются и интерполируются ещё до передачи в PowerShell, что приводит к ошибкам. Раньше Claude Code не распознавал такие сбои и зацикливался. С версии 2.1.84 эта проблема решена опциональной поддержкой PowerShell.

Shell integration и переменные окружения

Функция shell integration, позволяющая Claude Code видеть текущую директорию и код возврата команд в реальном времени, на Windows недоступна. Каждый вызов инструмента — это отдельный процесс. Переменные окружения, заданные в одной команде, не сохраняются в следующей.

Для постоянных переменных используйте SetEnvironmentVariable или settings.json.

Файловая система и пути

Claude Code ожидает Windows-пути с обратными слешами. Unix-пути вроде /c/Users/... или ~/projects не распознаются.

NTFS нечувствителен к регистру, в отличие от ext4. Это может привести к проблемам: Claude Code может создать файл с путём в неправильном регистре, NTFS примет его как тот же файл, а затем удаление «дубликата» приведёт к удалению оригинала.

Переносы строк

Windows использует CRLF (\r\n), Linux — LF (\n). Bash-скрипты, созданные в Windows, могут содержать \r, что ломает выполнение в Linux-окружениях, например, в AWS.

Проблема не в самих переносах, а в том, что Claude Code не применяет правила из CLAUDE.md последовательно между вызовами. Частичные исправления появились в версиях 2.1.88–2.1.89, но проблема до конца не решена. Приходится вручную подменять переносы строк.

MCP и IPC

MCP использует Unix domain sockets для межпроцессного взаимодействия. На Windows их аналог — Named Pipes, но API отличается. Функция getSocketPaths() возвращает только Unix-пути вроде /tmp/... и не пытается использовать Named Pipes. В результате соединение не устанавливается без явной ошибки.

Если MCP-сервер использует /home/user или os.tmpdir() без учёта Windows, он может упасть при попытке создать файл. На Windows os.tmpdir() возвращает C:\Users\...\AppData\Local\Temp.

Частичное решение — обёртка команд в cmd /c, что позволяет запускать npx и другие Node-инструменты. Однако это не помогает, если в коде MCP-сервера зашиты Unix-пути.

Пути в JSON-конфигах могут быть указаны как C:\\Projects, так и C:/Projects. Одиночный обратный слеш ломает парсер. MCP-серверы с жёстко прописанными Unix-путями (/tmp, /home) на Windows не запустятся.

Sandboxing

На macOS используется Seatbelt (sandbox-exec), на Linux — bubblewrap. На Windows изоляция на уровне ядра пока не поддерживается, хотя запланирована.

Без sandboxing Claude Code работает с правами текущего пользователя, что создаёт риск изменения или удаления файлов вне разрешённой папки.

Альтернатива: Claude Code в WSL2

Windows Subsystem for Linux 2 (WSL2) — это не эмуляция, а полноценное Linux-ядро в лёгкой виртуальной машине. Он решает все ключевые проблемы нативной установки.

Преимущества WSL2:

• Реальный bash вместо Git Bash — работает shell integration, переменные не перехватываются
• Доступны Unix domain sockets — все MCP-серверы подключаются штатно
• Поддержка bubblewrap — включается sandboxing (требует установки bubblewrap и socat)
• Файловая система Linux (например, ~/projects/) значительно быстрее NTFS при npm install и ripgrep
• Работают POSIX-права, символические ссылки, inotify

PowerShell остаётся доступным — как из WSL, так и отдельно в Windows Terminal.

Установка WSL2

Из PowerShell с правами администратора:

wsl --install -d Ubuntu-24.04

После установки — перезагрузка. При первом запуске Ubuntu запросит создание пользователя и пароля.

Если WSL уже установлен, обновите его:

wsl --update

Проверьте версию WSL для дистрибутива:

wsl -l -v

Если версия 1 — обновите:

wsl --set-version <имя_дистрибутива> 2

После изменений перезапустите WSL:

wsl --shutdown

Настройка производительности

Файл C:\Users\<имя_пользователя>\.wslconfig (создаётся вручную):

Важно: пробелы вокруг = ломают парсинг. Пишите 16GB, а не 16 GB.

Файл /etc/wsl.conf — настройки дистрибутива (редактируется внутри Ubuntu):

После изменений — перезапуск WSL2.

Настройка Ubuntu

Внутри Ubuntu обновите систему и установите пакеты:

sudo apt update && sudo apt upgrade -y
sudo apt install -y build-essential ripgrep direnv bubblewrap socat

Пояснение:

• build-essential — для компиляции нативных модулей Node.js
• ripgrep — используется Claude Code для поиска (лучше использовать системный)
• direnv — управление переменными окружения на уровне проекта
• bubblewrap и socat — зависимости для sandboxing

direnv автоматически загружает .envrc при входе в директорию. Подключите его к bash:

Пример .envrc в корне проекта:

Первый раз в директории разрешите выполнение:

direnv allow

Установка Node.js и NVM

Устанавливать Node.js через apt не рекомендуется — старые версии, проблемы с правами. Используйте NVM:

Актуальную версию NVM смотрите на nvm-sh/nvm. На момент написания — v0.40.4.

Установка Claude Code в WSL2

Установка стандартная — установщик не требует Node.js и поддерживает автообновление. Установка через npm install -g @anthropic-ai/claude-code официально устарела.

Дополнительные инструменты

Claude Code обучен использовать:

• bun — альтернатива node/npm, в 4–25 раз быстрее
• fd — замена find, быстрый поиск по имени
• sd — замена sed, удобный синтаксис регулярных выражений
• gh — GitHub CLI

ripgrep и jq уже установлены через apt.

Чтобы переключить Claude Code на системный ripgrep, добавьте в ~/.claude/settings.json:

Глобальные настройки и CLAUDE.md

Файл ~/.claude/CLAUDE.md — идеальное место для описания окружения и личных предпочтений. Он применяется ко всем проектам.

Для нового проекта CLAUDE.md можно сгенерировать автоматически:

Claude проанализирует код и создаст .claude/CLAUDE.md с командами сборки, тестирования и конвенциями. Лимит — 200 строк на файл.

Оптимизация производительности в WSL2

Стандартные лимиты Ubuntu могут не хватать для больших репозиториев. Claude Code и файловые вотчеры (Vite, webpack, TypeScript) упираются в inotify. Увеличьте лимиты:

Изменения sysctl применяются сразу. Лимиты nofile — после перезапуска WSL2.

Работа с файлами

Правило: проекты и репозитории должны находиться в Linux-файловой системе, а не в /mnt/c/.

Windows видит Linux-файлы через 9P — виртуальную сетевую шару. Чтение из проводника нормально, но активное редактирование — медленно. Оптимально использовать VSCode с WSL-расширением: интерфейс на Windows, файлы в Linux.

Адрес в проводнике: \\wsl.localhost\<имя_дистрибутива>

net use не работает — это SMB-клиент, а 9P не поддерживается SMB.

Однако WSL2 можно замаппить на диск (например, W:):

На типичном проекте (10k+ файлов, активный git) разница в производительности между нативным Windows и WSL2 очевидна:

• git status — в разы быстрее
• npm install — значительно быстрее
• ripgrep по 50K файлов — в разы быстрее

Причины: NTFS накладывает накладные расходы, антивирус сканирует каждый файл, а мелкие файлы в node_modules и .git — узкое место.

Итог

У автора установлены и активно используются оба варианта: Claude Code в Windows и в WSL2 с Ubuntu. В терминале доступны оба. Успешные настройки, скилы и MCP-серверы часто переносятся из одного окружения в другое. Холивары бесполезны — лучше выбирать инструмент под задачу.

Версия Claude Code на момент написания: 2.1.105+

У нас в команде AWS 9 человек: решения в AWS, 150+ аккаунтов в AWS Organizations. Один из нас работает на macOS, шестеро на Linux, двое на Windows (включая меня).

За год работы с Claude Code выработались правила: как поставить и что настроить. Правила менялись по мере выхода новых версий: появлялись новые возможности, отваливались старые костыли. Этот документ отражает актуальное состояние на апрель 2026.

На Linux не пересаживаюсь намеренно. Мои Windows-компетенции в команде востребованы: я единственный, кто имеет солидный опыт с Microsoft, кто отладит Lambda-парсер для обработки Windows Events, кто напишет и будет поддерживать большой PowerShell скрипт или SSM-документ с ним.

Claude Code у меня под Windows должен работать без ошибок и с максимально возможной производительностью, несмотря на то, что большую часть времени я работаю на linux-специфичное окружение.

Обычная установка

Установка прямо в Windows — правильный выбор в случаях, когда:

• Нужно просто попробовать Code на Windows, без сложной настройки окружения
• Задача на .NET, WPF, WinForms — всё завязано на Windows API, WMI, реестр
• Работа только с PowerShell скриптами, DSC-конфигурациями или SSM-документами с PowerShell
• Azure, различные корпоративные Windows-инструменты
• Либо нужно поймать баг, который воспроизводится только на Windows платформе

У чистой Windows установки есть ограничения — они разобраны в конце этого раздела.

Claude Code использует Git Bash для запуска команд в терминале — без него установщик откажет (но обычно git уже установлен):

Если дажеwingetотсутствует — надо скачать Git сhttps://git-scm.com/install/windows. При установке — все галочки по умолчанию: Git Bash, интеграция с Explorer, добавление в PATH.

В Windows уже идет сpowershell.exe— это Windows PowerShell 5.1, построенный на .NET Framework. Последний релиз был в 2017 году; развитие остановлено.pwsh— это PowerShell 7+: open-source, кросс-платформенный, на .NET Core. Именно его Microsoft развивает и рекомендует для новых проектов. Устанавливается отдельно, перезагрузки после установки не требует, сосуществует с 5.1 без конфликтов:

Для PowerShell 7+ надо запускатьpwsh, а неpowershell. Все дальнейшие команды рассчитаны наpwsh. Очень рекомендуюWindows Terminal(но это дело вкуса) — в соседних табах работают и powershell и linux.

Установка Claude Code:

Установщик скачает бинарник, пропишет PATH, настроит автообновление. Node.js и npm не нужны. Альтернативный способ — через WinGet:winget install Anthropic.ClaudeCode(но тогда надо будет обновлять Claude Code вручную, черезwinget upgrade).

При необходимости можно указать версию:

Еслиclaudeне находится — установщик не прописал PATH или консоль не перезапущена. Исправляется вручную:

Бесплатный план Claude не включает Claude Code. Нужен один из:

• Claude Pro или Max — личная подписка наclaude.ai
• Claude for Teams или Enterprise — корпоративный аккаунт
• Claude Console — аккаунт разработчика с API-биллингом
• Amazon Bedrock, Google Vertex AI, Microsoft Foundry — через инфраструктуру облачного провайдера
• В России в 2026 официально недоступен, но есть варианты

Большинству пользователей API-ключ не нужен. Запуститьclaude— откроется браузер, войти с аккаунтомclaude.ai. Если браузер не открывается — в терминале нажатьc, URL скопируется в буфер обмена. Вставить в браузер, войти, скопировать полученный код обратно в терминал.

API-ключ нужен только при работе через Console (API-биллинг вместо подписки). Задаётся через/configили переменной окружения:

Важно: еслиANTHROPIC_API_KEYзадан, он имеет приоритет над подпиской. Если ключ устарел или отозван — аутентификация сломается. Проверить активный метод аутентификации: команда/statusвнутри Claude Code.

По умолчанию Claude Code выполняет команды через Git Bash. Для PowerShell-проектов это неудобно: переменные$_,$?, конвейеры — всё ломается. Начиная с версии 2.1.84 есть решение — добавить настройки в файл%USERPROFILE%\.claude\settings.json:

Две разных настройки делают разные вещи:

• CLAUDE_CODE_USE_POWERSHELL_TOOL=1регистрирует PowerShell как отдельный инструмент наряду с Bash. Claude Code автоматически определитpwsh.exe(7+); при его отсутствии — проверит наличиеpowershell.exe(5.1).
• "defaultShell": "powershell"направляет интерактивные!команды Claude Code через PowerShell. Работает только при настройках выше.

Git Bash при этом остаётся обязательным — Claude Code использует его для собственного запуска. Если Git установлен не вProgram Files, надо указать реальный путь вCLAUDE_CODE_GIT_BASH_PATH.

Для глобальных инструкций надо записать в%USERPROFILE%\.claude\CLAUDE.mdпримерно такое:

Claude Code написан под POSIX-окружение. Пути к файлам, shell-команды, IPC между процессами, хуки — всё это по умолчанию предполагает Unix. На нативном Windows часть этого работает через прослойки и эмуляцию, часть не работает совсем.

По умолчанию Claude Code выполняет команды через Git Bash — даже если запущен из PowerShell или CMD. Git Bash. Это MinGW-порт bash, адаптация под Windows, у которой:

• нет полной поддержкиextglob(расширенный синтаксис паттернов для сопоставления имён файлов в bash. Включается командойshopt -s extglob. Стандартный glob знает только*,?,[abc].extglobдобавляет+,@,!. Например, удалить всё кроме.jsфайлов:rm !(*.js).
• переменные$_,$?,$!ведут себя иначе, чем в настоящем bash (подробнее ниже)
• нетsystemd,cron,inotify
• нет управления процессами и приложениями Windows. В Linuxkill -HUPзаставляет nginx перечитать конфиг без перезапуска: мастер-процесс проверяет синтаксис, поднимает новые воркеры и плавно завершает старые. Для ротации логов nginx использует другой сигнал —SIGUSR1(закрыть и переоткрыть дескрипторы файлов).SIGUSR1с этой целью применяют также MongoDB, MySQL и ряд других демонов — это устойчивое соглашение в Unix-экосистеме, хотя и не формальный стандарт POSIX: некоторые программы для тех же целей используютSIGHUP. В Git Bash сигналы до Windows процессов не доходят, потому, что Windows не имеет поддержки POSIX-сигналов на уровне ядра.

Насчет переменных типа$_: когда Claude Code пытается выполнить PowerShell-команды через Git Bash, bash перехватывает и раскрывает переменные до того, как PowerShell их получает:

Claude Code не распознавал эту ошибку как признак неправильного окружения и повторял тот же сломанный запрос по кругу. В версии 2.1.84 (наконец!) добавили opt-in PowerShell-инструмент — он включён вsettings.jsonвыше.

Shell integration, хуки для bash и zsh, которые дают возможность Claude Code видеть текущую директорию и exit code команд в реальном времени, на Windows недоступна. Переменные окружения, заданные в одной команде, не переживают следующую: каждый вызов инструмента, это новый процесс. Для постоянных переменных надо определитьSetEnvironmentVariableилиsettings.json.

Claude Code на Windows ожидает Windows-пути с обратными слэшами. Инструменты Read, Edit, Write не понимают Unix-пути вида/c/Users/...или~/projects:

С файловой системой — своя история:

Характеристика

NTFS (Windows)

ext4 (Linux)

Регистр имён файлов

нечувствителен

чувствителен

Символические ссылки

требуют Developer Mode или прав администратора

работают без ограничений

Права доступа

POSIX chmod/chown

Производительность с множеством мелких файлов

Нечувствительность к регистру — это, мягко говоря, неудобство. Claude Code создаёт путь в неправильном регистре, NTFS молча принимает его как тот же файл, затем Claude Code удаляет «дубликат», и вместе с ним оригинал.

C переносами строк в Windows отдельный головняк. Windows используетCRLF(\r\n), Linux —LF(\n). Bash-скрипт, созданный Claude Code в Windows, может оказаться с\r(если не используется специальный редактор) в конце каждой строки:

Суть проблемы не в самих окончаниях строк, а в том, что Claude Code не применяет правила изCLAUDE.mdпоследовательно между вызовами инструментов. Частичные фиксы выходили в v2.1.88-89, проблема до конца не решена. Под Windows мне приходится подменять переносы строк функцией на лету, иначе AWS не выполняет.shфайл с\r\nпереносами строк.

MCP использует Unix domain sockets для IPC. На Windows их эквивалент — Named Pipes, но это другой API с другой логикой обнаружения.getSocketPaths()возвращает только Unix-пути вида/tmp/...и никогда не включает путь Named Pipe. Клиент пробует найти сокет, не находит, и не пытается переключиться на Named Pipes. Соединение не устанавливается без каких-либо явных ошибок.

Отдельная проблема возникает, если MCP-сервер внутри использует/home/userилиos.tmpdir()и не учитывает Windows. Такой MCP-сервер крашнется при попытке создать файл. На Unixos.tmpdir()возвращает/tmp, на Windows —C:\Users\...\AppData\Local\Temp, и многие MCP-серверы это не обрабатывают.

Решение — заворачивать команды вcmd /c. Это позволяет запуститьnpxи другие Node-инструменты, но не решает проблему MCP серверов с Unix-путями в их коде:

C:/Projects- не ошибка. Пути в JSON-конфиге работают иC:\\Projects(двойной обратный слэш), иC:/Projects(прямой слеш). Одиночный обратный слеш (\) сломает JSON-парсер. MCP серверы с прошитыми Unix-путями (/tmp,/home), на Windows не запустятся.

Sandboxing — это изоляция Claude Code на уровне ядра ОС: ограничивает доступ к файлам и сети для всех дочерних процессов, включаяterraform,kubectl,npm.

Sandboxing

через Seatbelt (sandbox-exec)

через bubblewrap

еще не поддерживается, но поддержка запланирована

На Windows Claude Code работает с полными правами текущего пользователя и есть риск изменения или удаления файлов вне разрешённой папки.

Если эти ограничения критичны — в следующем разделе дальше разобран альтернативный подход.

Claude Code в WSL2

WSL2, Windows Subsystem for Linux 2 — встроенный в Windows 10/11 слой совместимости, который запускает настоящее Linux-ядро внутри лёгкой виртуальной машины. Не эмуляцию, и не прослойку типа Git Bash, а именно Linux-ядро, то же самое, что работает на серверах и в Docker-контейнерах.

Для разработчика это означает, что рядом с Windows появляется полноценная Linux-среда: bash, apt, systemd, inotify, Unix-сокеты и всё остальное. Два окружения сосуществуют — файлы открываются из проводника Windows, код выполняется в Linux.

Для Claude Code WSL2 решает все проблемы нативной установки, описанные выше:

• Git Bash заменяется реальным bash — shell integration работает, переменные не перехватываются
• Unix-сокеты доступны — все MCP-серверы подключаются штатно
• bubblewrap доступен — sandboxing включается (нужна установкаbubblewrapиsocat)
• файловая система Linux (~/projects/) на порядок быстрее NTFS дляnpm install,ripgrep
• POSIX-права, симлинки, inotify — всё работает без обходных путей

Я использую WSL2 для всего, что связано с Linux-инфраструктурой. PowerShell при этом никуда не девается — он доступен и из WSL, и отдельным окном в Windows Terminal.

Установка из PowerShell с правами администратора:

Команда устанавливает WSL2 и дистрибутив Ubuntu 24.04.wsl --installставит Ubuntu по умолчанию, но лучше указать версию явно. После установки — перезагрузка. При первом запуске Ubuntu попросит создать суперпользователя и пароль.

Если WSL уже был установлен, на всякий случай обновляем:

Проверка — какая версия WSL у дистрибутива:

В столбцеVERSIONдолжна стоять именно2. Если стоит1— обновить:

После изменений надо перезапустить WSL:

Настройки производительности WSL2 пишутся в файлC:\Users\<имя_пользователя>\.wslconfig(создаётся вручную):

.wslconfigчувствителен к пробелам — здесь пробелы вокруг=ломают парсинг. Число и единица пишутся слитно:16GB, не16 GB.

/etc/wsl.conf— настройки дистрибутива, читаются при каждом старте WSL2. Редактировать надо внутри уже Ubuntu:

Многие предпочитают редактор vi или vim, но мой выбор — nano; что-то вроде терминального notepad. Дело вкуса и привычки — я работаю в Windows всю свою карьеру.

После изменения — перезапустить WSL2:

Внутри Ubuntu — надо сразу обновить систему и поставить необходимые пакеты:

build-essentialнужен для компиляции нативных модулей Node.js.ripgrepClaude Code использует для поиска по файлам — лучше иметь системный, не полагаясь на встроенный.direnv— для переменных окружения на уровне проекта.bubblewrapиsocat— зависимости sandboxing: без них Claude Code на Linux и WSL2 работает без изоляции файловой системы и сети.

Как работаетdirenv: при входе в директорию он автоматически загружает.envrc. Удобно для заданияANTHROPIC_API_KEY,AWS_ACCOUNT, различных токенов и других переменных под конкретный проект и приложение. Его надо подключить к bash, чтобы запускался при смене директории:

Пример.envrcв корне проекта:

Первый раз в директории — разрешить:

Node.js черезaptлучше не ставить — там старые версии и проблемы с правамиnpm. NVM позволяет держать несколько версий и переключаться между ними без sudo. Актуальную версию NVM смотреть наnvm-sh/nvm: Node Version Manager. На момент написания —v0.40.4:

Установка Claude Code — установщик не требует Node.js и автообновляется в фоне:

Установка черезnpm install -g @anthropic-ai/claude-codeофициально устарела — это объявила Anthropic.

Claude Code уже обучен в bash использовать некоторые команды при работе с файлами и процессами. Например:

• bun— замена node/npm: запуск JS/TS, управление пакетами, быстрее npm в 4-25x
• fd— замена find: поиск файлов по имени
• sd— замена sed: замена текста с нормальным синтаксисом регулярок
• gh— GitHub CLI

ripgrepиjqуже установлены выше, черезapt install

По умолчанию Claude Code использует встроенную копиюripgrep. Переключить на системный через~/.claude/settings.json:

~/.claude/CLAUDE.md— правильное место для описания окружения и личных предпочтений. Один раз, для всех проектов:

Кстати, для нового проектаCLAUDE.mdможно сгенерировать автоматически. Запустить в репозитории:

Claude проанализирует кодовую базу и создаст.claude/CLAUDE.mdс командами сборки, тестирования и найденными конвенциями. Лимит: 200 строк на файл: если файл большой, некоторые правила могут игнорироваться.

Стандартные лимиты Ubuntu слишком малы для больших репозитариев с тысячами файлов. Claude Code и файловые вотчеры (Vite, webpack, TypeScript) упираются вinotifyпри большом дереве. Определяем большие лимиты:

Измененияsysctlприменяются сразу. Лимитыnofile— после перезапуска WSL2 (wsl --shutdownиз PowerShell).

Правило одно: проекты и репы держать в Linux-файловой системе, не в/mnt/c/.

Windows видит Linux-файлы через протокол 9P — это виртуальная сетевая шара, которую WSL2 монтирует автоматически. Читать из Windows Explorer нормально, активно редактировать — медленно. Для разработки оптимальный вариант — VSCode с WSL extension: файлы в Linux, интерфейс на Windows.

Из адресной строки Windows Explorer:

net useне работает!

9P (Plan 9 Filesystem Protocol) — протокол доступа к файловой системе из Bell Labs. Разработан для ОС Plan 9, где все ресурсы системы (файлы, устройства, сеть) представлены единым файловым деревом. WSL2 использует его в обе стороны: Linux видит Windows-диски через/mnt/c/— это 9P-сервер на стороне Windows; Windows видит Linux-файлы через\\wsl.localhost\— 9P-сервер на стороне Linux.

Почему не SMB? SMB проектировался для корпоративных сетей — там есть аутентификация (NTLM, Kerberos) и шифрование. Всё это не нужно для локального IPC внутри одной машины. 9P — протокол без лишних слоёв, идеально подходит для локальной среды.net use— это SMB-клиент; он не поддерживает 9P, поэтому и не работает с WSL-шарами.

Но пространство WSL2 замаппить на диск (например, W:) все-таки можно:

На типичном проекте (10k+ файлов, активный git) разница между нативным Windows и WSL2 ощутима. Цифры ниже приблизительные, не бенчмарки: значения зависят от железа и проекта.

~/projects/

git status

npm install

ripgrepна 50K файлов

WSL2 с файлами в~/projects/в разы быстрее Windows. Причины: NTFS накладывает расходы на антивирусное сканирование каждой операции, Windows Defender сканирует каждый новый файл приnpm install, а мелкие файлы (node_modules,.git) — узкое место NTFS.

У меня оба варианта, Claude Code в Windows и в WSL2 с Ubuntu, установлены и настроены (и используются постоянно). В терминале доступны оба одновременно. Часто приходится удачные находки или обновления в скилах и MCP, перебрасывать из одного окружения в другое. Заниматься холиварами контрпродуктивно, лучше выбирать инструмент, подходящий для конкретной задачи.