Диагностика CLI и частые проблемы
Практический разбор сбоев в Istok Code CLI: как проверять доступ, логин, лимиты, модели, verify, project context и что делать, если вывод ушёл вверх или прошлую сессию нужно поднять заново.
- CLI установлен, но поведение всё ещё непредсказуемо
- Модель не видна, verify не запускается или login выглядит сломанным
- Нужно быстро локализовать проблему до обращения в поддержку
- Короткий и повторяемый порядок проверки CLI-контура
- Понимание, что именно относится к авторизации, что к квоте, а что к локальной конфигурации
- Меньше ложных выводов вроде "CLI не работает", когда сломан только один из контуров
С чего начинать диагностику
Если в CLI что-то пошло не так, первый полезный шаг это istok-code --check. Команда быстро показывает доступность сервиса, состояние авторизации, видимую модель и квоту. Это лучший старт, чем сразу переустанавливать пакет или перепроходить весь login flow.
Польза --check в том, что он сразу отделяет сетевой или auth-контур от проблем конкретной сессии. Если check уже не проходит, не тратьте время на verify, symbols и resume. Сначала верните базовую доступность и авторизацию.
Как отличать проблемы входа от обычной необходимости перелогина
Если браузерный вход неудобен или разнесён по разным машинам, используйте istok-code login --device. Если нужен токеновый сценарий, используйте --token-stdin или ISTOK_TOKEN. Эти пути не являются обходом продукта. Это штатные способы входа под разные рабочие условия.
Если обычный login открывает браузер, а у пользователя нет активной веб-сессии, сначала проходит логин в кабинет, а потом браузер возвращается к авторизации CLI. Это нормальный сценарий. Проблемой его стоит считать только если возврат в authorise-flow действительно не происходит после успешного входа.
Почему модель или лимит выглядят "сломанными"
Не каждая проблема с ответом означает, что сломан сам CLI. Если нужная модель не видна, сначала проверяйте план и набор доступных моделей для аккаунта. Если модель была доступна раньше, а потом пропала, снова начинайте с usage и billing, а не с переустановки пакета.
С квотами логика такая же. Можно быть корректно авторизованным, но упереться в лимиты запросов или токенов. В этом случае CLI как приложение работает нормально, а отказ приходит от продуктового ограничения. Поэтому usage и billing это часть диагностики, а не второстепенные команды.
Что делать, если verify, symbols или project дают слабый результат
Если /project не видит корень проекта или не показывает проверки, verify не сможет нормально работать поверх пустого контекста. В таком случае сначала запускайте CLI из нужной директории репозитория. После этого повторно проверьте /project и только потом используйте verify.
Если symbols даёт мало результатов, уточняйте имя символа и сужайте область через --path. Это практичный проектный поиск, а не полноценный IDE resolver. Поэтому слабый результат по очень общему имени не всегда означает баг. Часто это сигнал, что запрос слишком широкий.
Если потеряли старый вывод или хотите поднять прежнюю задачу
Не перезапускайте сессию только потому, что старый вывод ушёл вверх. Используйте PgUp и PgDn для листания, Home для перехода к началу и End для возврата вниз. Это нормальный способ смотреть старые tool calls и verify-логи без потери текущей работы.
Если нужно не просто увидеть старый вывод, а реально вернуться к задаче, поднимайте локальную историю через --sessions и --resume <id|latest>. Это полезнее, чем пытаться вручную восстановить длинный контекст из памяти.
Если последний запрос упал из-за сети или ошибки сервера
Если ход завершился сетевой или серверной ошибкой, не набирайте запрос заново вручную. Используйте slash-команду /retry прямо в интерактивной сессии. Она повторяет именно последний упавший ход с тем же текстом и передаёт агенту актуальный контекст без дополнительных действий с вашей стороны.
/retry работает только тогда, когда последний ход завершился ошибкой, допускающей повтор. Если ход завершился нормально или был отменён пользователем, /retry выдаст информационное сообщение и не отправит новый запрос.