Files
knowledge-base/claude-memory/cliproxy_code_server.md

4.6 KiB
Raw Blame History

name, description, type
name description type
CLIProxy на code-server (10.0.0.179) Claude Code использует CLIProxy OAuth — процедура обновления токена при протухании project

Claude Code на code-server (LXC 132, IP 10.0.0.179) работает через локальный CLIProxy (порт 8317, cliproxy.service).

Проблема: OAuth токен (batlaew@gmail.com) протухает каждые ~8 часов. CLIProxy может не обновить refresh_token автоматически → клиент переходит в suspended → Claude Code перестаёт работать.

Why: CLIProxy использует OAuth через claude.ai, а не прямой API. Это бесплатно (подписка Pro), но требует периодического обновления токена.

Процедура обновления токена

  1. Остановить сервис: systemctl stop cliproxy.service
  2. Запустить логин: /usr/local/bin/cli-proxy-api -config /root/.cli-proxy-api/config.yaml -claude-login -no-browser
  3. CLIProxy покажет URL для SSH-туннеля и ссылку авторизации
  4. На локальной машине сделать SSH-туннель: ssh -L 54545:127.0.0.1:54545 root@202.71.12.186
  5. Открыть ссылку авторизации в браузере, залогиниться batlaew@gmail.com
  6. После callback — токен обновится в /root/.cli-proxy-api/claude-batlaew@gmail.com.json
  7. Запустить сервис: systemctl start cliproxy.service

Конфигурация

  • settings.json: apiBaseUrl: http://localhost:8317, apiKey: sk-cliproxyapi-local
  • Env: ANTHROPIC_BASE_URL=http://localhost:8317
  • Токен файл: /root/.cli-proxy-api/claude-batlaew@gmail.com.json
  • API keys в config.yaml: sk-clawdbot-proxy, sk-f4ab6903a58a4cb4b2b453ae2bbf2c6e

Альтернатива (fallback)

Прямой API: ключ ANTHROPIC_API_KEY=sk-ant-api03-vMW... доступен в env. Для переключения: в settings.json поменять apiBaseUrl на https://api.anthropic.com и apiKey на прямой ключ. Но это платно.

TODO

  • Выяснить, почему auto-refresh не срабатывает (проверить после следующего протухания)
  • Рассмотреть cron для принудительного рефреша до истечения токена

Update 2026-05-06 — два разных CLIProxy-механизма

После audit'а (см. ../decisions/2026-05-06-openclaw-opus-4-7-via-max-cliproxy) выяснилось:

  1. Standalone cliproxy.service на порту 8317 — описан выше, OAuth batlaew@gmail.com (Pro), auto-refresh ломается. Сейчас используется только legacy ботами (NIIKN 133, Знам 134), которым ещё не выдан прямой API ключ. Когда мигрируют — service выключить.

  2. Встроенный CLIProxy-модуль OmniRoute (через cc/* модели) — другой mechanism. Использует Max-подписку Олега, OAuth flow через claude-cli/1.0.83 user-agent. У OmniRoute есть HealthCheck loop (/root/.npm/_npx/cb5891f90ae65d14/node_modules/omniroute/app) который проактивно refresh'ит токены до их истечения — видно в journalctl -u omniroute:

    [HealthCheck] Refreshing gemini-cli/... (token expiring soon)
    [HealthCheck] [TOKEN_REFRESH] Successfully refreshed Google token
    [HealthCheck] Refreshing antigravity/... (token expiring soon)
    [HealthCheck] [TOKEN_REFRESH] Successfully refreshed Google token
    [HealthCheck] Refreshing kiro/... (token expiring soon)
    [HealthCheck] [TOKEN_REFRESH] Successfully refreshed Kiro AWS token
    

    То есть проблема старого CLIProxy (8h cycle + ломаный refresh) в OmniRoute не повторяется — refresh работает по событию expiring soon.

Где живёт state OAuth: /root/.omniroute/storage.sqlite → таблица provider_connections (поля access_token, refresh_token, expires_at). 11 провайдеров активно (claude:1, antigravity:5, codex:7, kiro:5, и т.д.).

Мониторинг здоровья cc/ для openclaw* — см. ../snippets/omniroute-models-audit (smoke test шаблоны и интерпретация ошибок).