Codex на Windows: установка без лишних обходов и проверка рабочего окружения

Старые инструкции по Codex на Windows часто начинаются с обязательной установки WSL. Сейчас это не единственный путь. Приложение ChatGPT для Windows умеет запускать Codex нативно через PowerShell и Windows sandbox. WSL2 остается полезным вариантом для проектов, которые зависят от Linux, но начинать с него нужно не всем.

В этом гайде установим Codex на Windows, откроем конкретный проект, проверим Git и выполним одну безопасную задачу.

Нативный режим подходит, если проект уже запускается в Windows, команда использует PowerShell, а зависимости не требуют Linux. Это самый короткий путь: приложение, папка проекта и установленный Git.

WSL2 выбирайте, если разработка уже ведется внутри Linux-дистрибутива, используются Linux-скрипты, Docker-настройки или зависимости с другим поведением в Windows. В этом случае храните проект в файловой системе WSL и запускайте команды там, а не смешивайте пути двух сред без необходимости.

Не существует универсально лучшего режима. Важнее, чтобы редактор, терминал, Git и зависимости смотрели на один и тот же экземпляр проекта.

Официальный путь ведет в Microsoft Store. Можно открыть страницу приложения вручную или выполнить в PowerShell:

После установки запустите ChatGPT и войдите в доступную учетную запись. Откройте настройки Codex и убедитесь, что выбран нужный режим выполнения: нативный PowerShell или WSL2.

Не скачивайте установщики с сайтов с похожими названиями. Команды и идентификаторы пакетов со временем меняются, поэтому перед передачей гайда коллегам сверяйте их с официальной страницей Windows.

Для первой проверки используйте отдельный небольшой репозиторий без секретов. Если проект уже есть, откройте PowerShell и перейдите в его каталог:

Команды по порядку: cd C:\Users\you\Projects\my-app, Get-Location и Get-ChildItem.

В выводе должны быть знакомые файлы проекта. Не выбирайте весь пользовательский каталог C:\Users\you и тем более корень диска. Граница рабочей папки защищает документы от случайного чтения и изменения.

Проверьте Git:

Команды по порядку: git --version и git status.

Если первая команда не найдена, установите Git for Windows из официального источника и откройте новый PowerShell. Если git status сообщает, что папка не является репозиторием, сначала уточните, действительно ли это проект. Не выполняйте git init автоматически в случайном каталоге.

Если status показывает незавершенные изменения, остановитесь. Codex не сможет отличить их от правок текущей задачи без дополнительного контекста. Сделайте осознанный коммит, stash или отдельную копию только после просмотра файлов.

В приложении выберите создание задачи и укажите конкретную папку проекта. Перед первым сообщением посмотрите режим доступа под полем ввода.

Для знакомства оставьте запрос подтверждения. Нативный Windows sandbox ограничивает процесс, но настройки полного доступа могут вывести агента за пределы проекта. Не включайте Full access ради того, чтобы не читать запросы разрешений.

Попросите Codex начать только с чтения:

Сверьте ответ с README, package.json, файлом решения или другой конфигурацией проекта. Если агент назвал команду, которой нет в репозитории, попросите показать точную строку.

Даже установленный Codex не гарантирует, что сам проект готов к запуску. Сначала вручную выполните штатную команду проекта. Для разных стеков она отличается: это может быть npm test, dotnet test, python -m pytest или команда из README.

Зафиксируйте четыре вещи:

• рабочий каталог;

• версия среды выполнения;

• исходный git status;

• результат теста или сборки до изменений.

Если исходная проверка уже падает, не просите агента «починить все». Сохраните вывод и решите, относится ли ошибка к окружению или к коду. Иначе после правки будет непонятно, что именно сломалось.

Для проекта без коммитов сначала проверьте .gitignore. В него обычно должны попасть секреты, зависимости, временные файлы и сборочные каталоги. Добавляйте в первый коммит только ожидаемые исходники, просматривая список и staged diff.

Хорошая первая задача имеет видимый результат и не требует новых зависимостей. Например:

Если план затрагивает пять файлов ради одной строки, не подтверждайте его автоматически. Попросите объяснить необходимость каждого изменения или сократить объем.

Когда Codex просит разрешить команду, прочитайте саму команду, каталог и ожидаемый эффект. Чтение файла и запуск теста отличаются от установки пакета, сетевого запроса или удаления. Каждому типу действия нужен свой уровень доверия.

После сообщения «готово» вернитесь в PowerShell:

Команды по порядку: git status и git diff.

Проверьте:

• изменены только согласованные файлы;

• новый текст находится в нужном месте;

• нет случайного форматирования соседнего файла;

• не появились .env, логи и артефакты;

• кодировка русскоязычного текста не испорчена.

Откройте приложение и воспроизведите пользовательский сценарий. Затем повторите тест или сборку. Ревью агента полезно как дополнительный взгляд, но не заменяет diff и ручную проверку.

Если правка неверна, дайте обратную связь по симптому: «Текст появился, но под полем email. Перенеси только его под поле name и не меняй остальное». Не разрешайте широкую переработку ради локального дефекта.

Переход имеет смысл, когда проблема связана именно с различием сред. Например, репозиторий использует bash-скрипты, права Linux, символические ссылки или контейнерный workflow, который команда уже запускает в WSL2.

Установите и настройте WSL по официальной инструкции Microsoft, затем в приложении выберите среду WSL. Проверьте путь проекта внутри Linux:

Команды по порядку: pwd и git status.

Не открывайте один репозиторий попеременно нативным Git и Git внутри WSL без понимания последствий. Различия окончаний строк, прав и путей могут создать шумный diff.

Если проект находится на диске Windows, а команды постоянно работают через /mnt/c, производительность файловых операций может отличаться. Для постоянной Linux-разработки удобнее хранить репозиторий внутри файловой системы WSL и открывать именно его.

Sandbox уменьшает область возможного вреда, но не проверяет смысл команды за вас. Агент может добросовестно выполнить неверный план внутри разрешенной папки.

Отдельно подтверждайте:

• запись в файлы;

• установку зависимостей;

• сетевой доступ;

• запуск неизвестных скриптов;

• удаление и перемещение;

• публикацию, push и работу с внешними системами.

Не храните ключи в исходниках и не вставляйте их в чат. Если проекту нужны секреты, используйте локальное окружение и секреты платформы. Проверьте, что файлы с ними исключены из Git.

Если приложение не видит папку, проверьте права Windows и попробуйте каталог внутри вашего профиля, а не защищенную системную директорию.

Если команда работает в обычном PowerShell, но не находится в задаче Codex, сравните PATH и перезапустите приложение после установки инструмента.

Если тест падает только у агента, попросите показать рабочий каталог, версию runtime и полный текст команды. Не устанавливайте вторую копию среды, пока не сравнили окружения.

Если diff состоит почти полностью из замен окончаний строк, остановите правку. Проверьте настройки Git и редактора, восстановите чистую точку и только затем повторите узкое изменение.

Если Codex открыл не тот репозиторий, создайте новую задачу с правильной папкой. Исправлять рабочую границу текстовой инструкцией ненадежно.

В Windows одна и та же инструкция может выглядеть по-разному в PowerShell, Command Prompt и bash внутри WSL. Не копируйте команду с export, если работаете в PowerShell, и не используйте путь C:\... внутри Linux без преобразования.

Попросите Codex назвать оболочку перед предложением диагностической команды. Для PowerShell штатны Get-Location, Get-ChildItem и $env:NAME; для WSL используются pwd, ls и $NAME. Смешение синтаксиса часто выглядит как проблема агента, хотя команда просто запущена не там.

Пути с пробелами заключайте в кавычки. Не разрешайте агенту сокращать абсолютный путь до предположения. Перед удалением или перемещением он должен показать разрешенный target внутри проекта.

Проверьте окончания строк через небольшой diff. Если репозиторий команды использует .gitattributes, соблюдайте его. Массовая замена CRLF и LF маскирует полезное изменение и усложняет ревью.

Если Codex будут использовать несколько сотрудников, подготовьте короткую приемку вместо длинного скринкаста. Каждый участник должен открыть тестовый репозиторий, увидеть чистый status, выполнить read-only анализ и одну малую правку.

Зафиксируйте версии Git и необходимого runtime, выбранный режим Windows или WSL, команду исходного теста и правила разрешений. Не храните персональные пути и токены в общей инструкции.

Для корпоративных компьютеров учтите централизованную установку приложения, политики PowerShell, прокси и антивирус. Не советуйте отключать защиту, если бинарный файл или команда блокируются. Передайте точный журнал администратору и согласуйте исключение только для проверенного компонента.

Приложение, sandbox и зависимости проекта обновляются независимо. После крупного обновления повторите короткую приемку: доступ к папке, исходный тест, запрос разрешения, diff и сетевой доступ.

Если поведение изменилось, сначала сравните настройки режима и рабочую директорию. Не переключайтесь на полный доступ как универсальное лечение. Сужение причины сохраняет защиту и дает воспроизводимый отчет.

Сделайте отдельный коммит с понятным сообщением. Запишите в проекте фактические команды запуска, теста и сборки. Для следующей задачи снова начинайте с чистого git status.

Если нужен более полный маршрут от локальной разработки до базы, Docker и публикации, на курсе «Вайбкодинг на максималках» Codex используется внутри всего цикла проекта, а не как отдельный чат.

Codex на Windows готов к работе, когда совпали четыре условия: выбрана одна среда, открыт конкретный репозиторий, исходная версия проверена и каждое изменение видно в Git. Нативный режим дает самый короткий старт. WSL2 стоит добавлять тогда, когда его требует проект, а не потому, что так было написано в старой инструкции.