Установка, авторизация, обновления и диагностика

1. Установка — это только полдела

Claude Code установлен. Дальше всё равно ломается: команда claude не находится, открывается не та среда, вход выполнен чужим аккаунтом, проект лежит в WSL, а CLI запущен из PowerShell. Установка ≠ готовность к работе.

Карта поверхностей у вас уже есть из прошлой лекции: маршрут идёт из проекта в терминале, IDE — для проверки результата. Теперь его надо завязать на вашу машину.

Хороший первый запуск скучный — значит, дальше вы займётесь кодом, а не раскопками в терминале. Критерий готовности — четыре ответа:

• видит ли система команду claude;
• запускается ли сессия;
• понимает ли Claude вашу среду через /doctor;
• под каким аккаунтом всё работает.

Точные команды установки меняются — инструмент развивается быстро. Поэтому я даю не вечную магическую строку, а логику: ставите CLI актуальным способом по официальной документации, потом проверяете готовность среды.

2. Поставить CLI на свою ОС

Сначала принципы, потом команды.

Способов несколько — это нормально. CLI ставится через пакетный менеджер ОС, npm или официальный скрипт. Все валидны, но дают разные пути обновления и места установки.

Берите способ, который уже живёт на вашей машине. Есть Homebrew — через него; работаете с Node.js — npm; нет ничего — официальный скрипт. Не ставьте пакетный менеджер ради одного инструмента.

Актуальная команда — в официальной документации. Строки ниже — примеры на момент написания, сверяйте с docs.

macOS

Три пути. Homebrew, если он уже стоит:

brew install --cask claude-code

npm, если установлен Node.js:

npm install -g @anthropic-ai/claude-code

Официальный скрипт, без предусловий:

curl -fsSL https://claude.ai/install.sh | bash

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

Про Apple Silicon (M1/M2/M3/M4): современные установщики сами выбирают сборку. Ошибки про архитектуру — сигнал, что Homebrew или Node работают через Rosetta, а CLI поставился под другую архитектуру. Лечится переустановкой Homebrew/Node под нативный arm64.

Linux

То же, минус Homebrew. Два пути — npm и официальный скрипт:

# через npm, если есть Node.js
npm install -g @anthropic-ai/claude-code

# или официальный скрипт-установщик
curl -fsSL https://claude.ai/install.sh | bash

Скрипт кладёт бинарь в ~/.local/bin или аналог в домашнем каталоге. Глобальный npm-пакет — туда, куда настроен npm prefix. Настроен на системные директории (/usr/local/lib/node_modules) — понадобится sudo, но это плохой признак: перенастройте prefix на домашний каталог и не ставьте глобальные пакеты под рут.

Контейнерные среды (Docker, dev container, CI runner): Claude Code ставится внутри контейнера, не на хост. Установка на ноутбуке контейнеру не помогает — файлы проекта живут в нём.

Windows

Вариантов сразу несколько, и они принципиально разные.

Native PowerShell — если проект и Git живут в обычной Windows-среде. Официальный скрипт:

irm https://claude.ai/install.ps1 | iex

Или npm, если есть Node.js:

npm install -g @anthropic-ai/claude-code

WSL (Windows Subsystem for Linux) — если проект лежит внутри WSL (веб-разработка, Docker, Linux-tooling). Ставьте там же, как на обычном Linux:

# внутри WSL
curl -fsSL https://claude.ai/install.sh | bash

Git Bash — частный случай: Claude Code, поставленный нативно в Windows, работает и в Git Bash. Отдельно ставить ничего не нужно.

Главная Windows-ловушка: поставить CLI в одной среде, запускать из другой. Поставили в WSL — запускайте из WSL. Поставили нативно — из PowerShell или Git Bash. Поставили нативно, а проект в WSL — Claude увидит файловую систему Windows, а не вашу папку внутри WSL. Это не поломка, разные миры. Вернётесь к таблице из следующего раздела: где проект и откуда запуск.

Что делать сразу после установки

Независимо от ОС, первое действие одно:

claude --version   # проверили, что система видит команду и видит правильную версию

Версия вывелась без ошибок — установка состоялась. Полную диагностику (/doctor, /status) гоняем внутри открытой сессии — про это в следующих разделах. Не торопитесь с задачей: сначала выберите правильную среду и откройте проект там, где он живёт.

3. Запускайте Claude там, где живёт проект

Одна команда ведёт себя по-разному в зависимости от того, где вы её запускаете. На Windows особенно: проект в WSL, Git в Git Bash, IDE открывает PowerShell. Формально один ноутбук, фактически — несколько рабочих миров.

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

На Windows оба пути нормальны. «Правильный» — тот, где уже живут проект, Git и инструменты. Проект в WSL — туда же Claude; полностью Windows-native — PowerShell.

Терминал внутри IDE не отдельная вселенная — встроенный терминал на выбранном shell. Но именно здесь всплывает эффект: в обычном окне WSL, а в IDE внезапно PowerShell. Снаружи «один проект», по факту — разная диагностика. Первую проверку запускайте в том терминале, которым будете пользоваться каждый день.

Сомневаетесь в папке — ориентируйтесь на корень проекта: там лежат README, build.gradle, package.json, docker-compose.yml. Для сквозного примера это каталог с Commerce OS, а не рабочий стол и не домашняя директория.

4. Первый запуск: версия, сессия, диагностика

Правильная среда выбрана — марафон команд не нужен. Достаточно короткой цепочки: всё готово или где затык.

flowchart TD
    A[Установили Claude Code] --> B[Открыли терминал в нужной среде]
    B --> C[Перешли в каталог проекта]
    C --> D[Проверили claude --version]
    D --> E[Запустили claude]
    E --> F["/doctor"]
    F --> G["/status"]
    G --> H{Всё в порядке?}
    H -- Да --> I[Сохранили лог первого запуска]
    H -- Нет --> J[Исправили shell / PATH / auth / каталог и повторили]

На практике:

cd ~/projects/commerce-os      # переходим в каталог проекта
claude --version               # например: 2.1.x
claude                         # открываем интерактивную сессию

Команды вида /... работают внутри открытой сессии, а не в обычном shell. Сначала claude, потом диагностика внутри сессии:

/doctor                        # проверка установки, shell, авторизации и окружения
/status                        # текущее состояние сессии

Названия команд или формат вывода в вашей версии чуть иные — не катастрофа. Источник правды: встроенное /help, claude --version и актуальная справка, а не скриншот из чужого блога.

Что дают эти шаги:

claude --version отвечает на главный вопрос: видит ли ОС Claude Code как исполняемую команду. Вместо версии видите:

claude: command not found
# или
'claude' не является внутренней или внешней командой

— проблема не в инструменте: shell его не находит. Обычно PATH, другая среда или неперезапущенный терминал.

claude запускайте из директории проекта. Откроете из случайной папки — Claude не поможет с тем проектом, что был в голове.

/doctor — встроенная диагностика: подсвечивает состояние установки, авторизации и окружения, не «ставит оценку». Не каждое предупреждение — конец света. «Вижу не тот shell» — повод сопоставить факты, а не переустанавливать всё: где проект, из какого терминала вход, совпадает ли это с рабочей средой.

/status — краткая карточка: активна ли сессия, виден ли проект, в порядке ли авторизация. claude --version работает, сессия открылась, /doctor без критики, /status спокоен — старт хороший.

5. Авторизация и обновления

Вход и обновление пугают не сложностью, а тем, что у разных людей выглядят по-разному. У одного всё прошло через браузер за минуту, у вас путь иной — и сразу мысль «всё сломалось, я особенный». Так бывает: у вас просто другой сценарий доступа — тип подписки, рабочий аккаунт, командный доступ, способ оплаты, корпоративная настройка.

Разбираться в каждом варианте не нужно. Важен не вид окна входа, а результат: Claude Code авторизован, и вы знаете, под каким аккаунтом. Поэтому после входа снова смотрите /status. Вход выполнен не тем аккаунтом — завершите сеанс способом из вашей актуальной версии и войдите заново. Привычка важнее команды: увидели сомнение — проверили статус, поправили учётку, прогнали диагностику.

С обновлениями правило то же: обновляйте тем же способом, которым ставили. Пакетным менеджером — через него. Отдельным установщиком — тем же каналом. Смешаете способы — получите две версии на машине, и shell подхватит не ту.

claude --version               # например: 2.1.x
# обновите Claude Code тем же способом, которым ставили его изначально
claude --version               # например: 2.1.y

После обновления откройте Claude и прогоните /doctor — дешёвая проверка. Попросили снова залогиниться — повторный вход после обновления бывает, это не поломка. И не гонитесь за номером версии из чужого видео: чуть новее или старее — не проблема. Цель первого дня — рабочая и предсказуемая среда, а не коллекция номерков.

6. Не работает с первого раза: читайте сигналы

Аккуратный запуск иногда упирается в техническую прозу: shell не видит команду, терминал в IDE в другой среде, проект открыт не там, авторизация крутится по кругу. Это полезно: здесь вы ведёте себя как инженер — симптом, гипотеза, починка.

Самая частая история первого дня — это PATH. Если говорить совсем по-человечески, PATH — это список мест, где ОС ищет команды. Представьте список адресов, по которым shell бегает в поисках двери с надписью claude. Если дверь существует, но адреса нет в списке, shell честно говорит: «Извините, не знаю такого человека». Поэтому сообщение command not found далеко не всегда означает, что Claude Code «не установился». Очень часто это означает, что текущий shell просто не знает, где его искать.

Не менее частая история — разные среды под одной крышей. Например, вы поставили Claude Code и проверили его в одном окне терминала, а потом открыли IDE, внутри которой терминал настроен по-другому. Там уже другая жизнь: другой shell, другой PATH, иногда вообще другая файловая система. Отсюда и магические эффекты вроде «час назад всё работало». На самом деле не магия. Просто вы вошли через другую дверь.

Отдельно запомните важное правило для удалённых и контейнерных сред. Если проект реально живёт по SSH или внутри контейнера, локальная установка Claude Code на вашем ноутбуке не делает его автоматически доступным там. Это частая ошибка новичка: команда прекрасно работает локально, но при переходе в удалённую среду её как будто никогда не существовало. И это нормально. Просто CLI должен быть установлен и запущен там, где исполняются команды проекта.

В этот момент очень хочется начать переустанавливать всё подряд по кругу. Обычно это плохая стратегия. Гораздо полезнее задать себе четыре спокойных вопроса. Вижу ли я команду claude? В той ли я среде, где живёт проект? Тем ли аккаунтом выполнен вход? Что именно показывает /doctor? Обычно уже на одном из этих шагов проблема становится заметной без шаманства.

7. Лог первого запуска: артефакт, спасающий время

Когда первая диагностика прошла успешно, рука так и тянется закрыть терминал и радостно идти дальше. Но очень полезно сделать одну маленькую вещь: сохранить короткий лог первого запуска. Это не официальный отчёт и не бюрократия ради бюрократии. Это ваша контрольная фотография рабочего состояния.

Такой лог может выглядеть очень просто:

# Лог первого запуска Claude Code

Дата: 2026-05-24
Проект: AI Commerce Growth OS
Каталог: ~/projects/commerce-os
ОС: macOS / Windows / Linux
Shell: zsh / bash / PowerShell / WSL
Claude CLI: 2.1.x
Авторизация: ok
/doctor: без критических ошибок
/status: сессия активна, проект открыт

Заметки:
- Claude запускаю из WSL, не из PowerShell
- терминал в IDE должен использовать ту же среду

Почему это полезно? Потому что через несколько дней или после первого обновления у вас появляется очень приземлённая точка сравнения. Если что-то вдруг перестало работать, вы не вспоминаете ситуацию по памяти в духе «вроде было нормально». Вы открываете свой же лог и смотрите: из какой среды вы запускали Claude, какая версия была, под каким shell всё работало и что было записано в заметках.

Особенно хорошо это работает в сквозном проекте. Вы открываете Commerce OS, запускаете Claude Code из знакомой директории, прогоняете /doctor, видите спокойное состояние — и знаете, что старт действительно был корректным. Не потому что вам так кажется, а потому что у вас есть маленький, но очень понятный след.

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

8. Доступ к Claude Code на этом курсе

Осталось закрыть последний практический вопрос: под каким аккаунтом вы будете запускать Claude Code на этом курсе. В разделе про авторизацию мы говорили, что путь входа у всех может выглядеть по-разному — личная подписка, рабочий аккаунт, командный доступ. Для учёбы мы выбрали отдельный путь, который не требует от вас личной подписки и одинаково работает у всех студентов: доступ через сервер JavaRush.

Идея простая. Вместо того чтобы каждый студент подключал собственный платёжный аккаунт, мы выдаём вам индивидуальный доступ к нашему шлюзу. Claude Code думает, что обращается к обычному API, но на самом деле его запросы идут через наш Gateway, который уже знает, какую модель отдать и как учесть расход. Для вас это означает ровно одно: меньше возни с настройкой доступа и единые условия для всей группы.

Технически это настраивается через переменные окружения в конфигурационном файле Claude Code. Всё просто и красиво: CLI читает настройки и понимает, по какому адресу обращаться и с каким токеном.

Два файла настроек: глобальный и проектный

Мы дадим вам два файла настроек, и важно сразу понять, чем они отличаются и кто из них главнее. Claude Code читает настройки из нескольких мест и накладывает их по приоритету — более «узкий» файл перебивает более «широкий».

~/.claude/settings.json

.claude/settings.local.json

Приоритет такой: проектный settings.local.json перебивает глобальный settings.json. Логика как с одеждой: глобальный файл — это базовый слой, который надет всегда, а проектный local — это то, что вы накидываете сверху для конкретной ситуации.

Зачем именно два файла, а не один? Затем, что это даёт вам гибкость без риска сломать базу. Глобальный файл с доступом к Gateway вы настроили один раз — и он молча работает во всех учебных проектах. А проектный settings.local.json — это ваша песочница: здесь можно отрабатывать более сложные сценарии конфигурирования, переопределять отдельные параметры под конкретный проект и экспериментировать, точно зная, что базовый доступ при этом останется целым. Если эксперимент в local-файле что-то сломал — вы просто убираете оверрайд, и глобальная настройка снова в силе.

Как выглядит глобальный файл доступа

Доступ к Gateway мы кладём именно в глобальный ~/.claude/settings.json — чтобы он работал в любом проекте курса, а не только в одном. Содержимое выглядит так (ключ здесь — заведомо ненастоящий, свой индивидуальный вы получите отдельно):

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm.javarush.com",
    "ANTHROPIC_AUTH_TOKEN": "PASTE_YOUR_COURSE_KEY_HERE",
    "ANTHROPIC_MODEL": "claude-course-fast",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-course-fast",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-course-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-course-max"
  }
}

Разберём три строки по существу:

• ANTHROPIC_BASE_URL — адрес, по которому CLI шлёт запросы. Вместо стандартного API он смотрит на наш Gateway, а мы уже дальше пересылаем ваши запросы на сервер.
• ANTHROPIC_AUTH_TOKEN — ваш индивидуальный ключ доступа к Gateway. Именно по нему наш шлюз понимает, что запрос ваш, и ведёт учёт расхода токенов. Этот ключ — личный, его не нужно никому показывать и тем более коммитить в репозиторий.
• CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY — флаг, который переключает Claude Code CLI на сервер JavaRush.

Важный момент, который мы закрепляем сразу: ключ доступа находится в глобальном файле в домашнем каталоге, а не в проекте. Поэтому его физически невозможно случайно закоммитить вместе с кодом. А проектный settings.local.json, в котором вы экспериментируете, и так не попадает в Git. Так устроено не случайно — это та самая инженерная гигиена, о которой курс будет напоминать постоянно: секреты не уезжают в репозиторий.

Проверка, что доступ работает

Проверяется всё тем же способом, что и обычная авторизация из раздела 5. Источник правды — /status: открываете сессию и смотрите, что Claude Code видит доступ и готов к работе.

claude                 # открываем сессию

/status                # убеждаемся, что доступ через Gateway активен

Если /status выглядит спокойно — поздравляю, технический старт на курсе у вас полностью собран: базовая среда (Git, Node.js), сам Claude Code, остальной стек проекта и рабочий доступ через Gateway. Дальше начинается самое интересное — реальная работа над проектом. И, в отличие от установки, вот её-то заучивать наизусть не придётся: вы будете учиться думать, а не запоминать команды.