Справочник CLI

CLI opencodex — это ocx. Он диспетчеризует по первому имени команды, при этом документированные alias вроде setup/init, restore/eject и models/model приводят к одной и той же операции. Неизвестные команды и некорректные формы вызова считаются ошибками.

Запускайте ocx help (или ocx --help / ocx -h) для верхнеуровневой справки. Для команды, зарегистрированной в таблице help, используйте ocx help <command>, ocx <command> --help или ocx <command> -h. Команды help и version — read-only: они не запускают, не останавливают, не устанавливают, не удаляют и не переписывают состояние Codex или opencodex.

Семейства команд

• Lifecycle — настройка, жизненный цикл прокси и службы, health, диагностика, синхронизация каталога, дашборд и обновления.
• Providers, accounts, and models — конфигурация провайдеров, аутентификация, credential pool’ы, квоты, custom model’и, видимость, selected model’и и context cap’ы.
• Agents, routing, and integrations — multi-agent controls, Budug, observability, admission key, client integration’ы, runtime setting’и и валидированная конфигурация, а также read-only инспекция обновления Codex CLI.

Поведение в headless-режиме

Management-команды делают round-trip через management API живого прокси, используя записанный runtime port и проверку identity, а не поддерживая второй путь конфигурации. Остановленный или недоступный прокси представляется как HTTP 503 и приводит к ненулевому коду выхода CLI. Команды, явно документированные как offline-операции с конфигурацией, вместо этого могут валидировать и редактировать файл конфигурации без живого прокси.

ocx system codex-cli-update check не требует работающего прокси и не обращается к реестру пакетов. Команда в строго ограниченном объёме проверяет метаданные происхождения настроенного кандидата, включая замаскированный путь к исполняемому файлу и подтверждения его принадлежности. Доверенный контекст опубликованного средства запуска подтверждает только подлинность снимка данных о кандидате, но не факт успешного запуска Codex. Поскольку команда выполняет только такую проверку и никогда не запускает Codex, кандидаты из окружения и сохранённых данных отображаются только в отчёте (managed: false, обычно selection_unattested). В выводе JSON присутствуют candidateAvailable, candidateVersion, candidateSource и selectionAttested, причём значение selectionAttested всегда равно false. Для проверки настроенного кандидата нужен доверенный контекст опубликованного средства запуска. При прямом запуске через Bun или из исходного кода такого подтверждения нет; в этом случае команда игнорирует кандидатов из окружения и сохранённых данных и может вернуть candidate_unavailable в POSIX или windows_inspection_deferred в Windows. В Windows этот первый этап вообще не выполняет файловый ввод-вывод по путям кандидата или конфигурации. Только абсолютный кандидат из окружения, зафиксированный доверенным средством запуска, может получить лексическую метку комплекта приложения или менеджера версий; все остальные кандидаты Windows отклоняются по принципу fail-closed. Команда не устанавливает и не восстанавливает ПО, не запускает Codex или npm, не управляет работающими процессами и ничего не записывает в конфигурацию или кеш.

Для наблюдения установки Windows x64 см. attest. Без явных путей команда наблюдает выбранного кандидата, определённого привязанным к доказательству снимком средства запуска; полномочия на обновление и выбор runtime не подтверждаются.

Там, где это недвусмысленно, list или status являются действием по умолчанию. Для структурированных снимков используйте --json, а для потокового лога запросов — ocx observe logs --follow --jsonl. Theme, language, navigation и прочее чисто визуальное browser-state CLI не покрывает; настройка Cloudflare Tunnel тоже вне этого набора команд.

Переопределение потолка проб доступности

ocx health, ocx status, ocx account *, ocx login codex и ocx ready находят запущенный прокси короткой пробой доступности: по умолчанию 750 мс на попытку и 1500 мс с повторами для решений об остановке и запуске. Если слой безопасности (контент-фильтр или сетевое расширение класса EDR) добавляет фиксированную задержку к каждому loopback-соединению, эти потолки могут истечь раньше, чем ответит исправный прокси.

На таких хостах задайте OCX_PROBE_TIMEOUT_MS, например OCX_PROBE_TIMEOUT_MS=5000 ocx status. Значение — целое число миллисекунд от 1 до 30000. Переопределение только повышает потолки: 750 мс по умолчанию и 1500 мс для остановки и запуска сохраняют нижнюю границу, поэтому 1000 удлиняет только пробу по умолчанию. Пустые, дробные, отрицательные, нулевые и большие значения игнорируются.

Коды выхода и подтверждение

Успешные команды завершаются с кодом 0. Некорректное использование, неизвестные команды или ресурсы, неудачные API-операции и недоступность обязательных служб приводят к ненулевому коду. Команда ocx health специально возвращает 0 только когда прокси здоров, и 1 во всех остальных случаях, поэтому её можно использовать как service probe. Сценарии должны проверять код выхода, а не разбирать человекочитаемый вывод.

Разрушающие операции удаления, импорта, расходования кредитов и обновления, которые документируют подтверждение, в неинтерактивном использовании требуют --yes. Этот флаг — явное согласие; отсутствие флага не должно молча подтверждать действие.

Version и внутренние dispatch-target’ы

ocx --version, ocx -v и ocx version печатают одну строку с версией, пригодную для сценариев, и завершаются.

Две точки диспетчеризации намеренно исключены из обычной справки: __refresh-version [preview] обновляет кэш уведомлений об обновлении в отдельном процессе, а __gui-update-worker <job-id> [latest|preview] [restart] исполняет update job дашборда. Это внутренние детали реализации, а не стабильные пользовательские команды. Дашборд записывает PID worker’а, умеет восстанавливать активную job, если её worker умер, считает старые активные записи без PID устаревшими через десять минут и защищает живой worker от конкурентных обновлений.