CLI

shunt import opencodex

互換性のある認証情報をオフラインで読み、新しい非公開スナップショットに保存します。既存の設定、認証情報ファイル、OpenCodex の状態は上書きしません。まずプレビューしてください。非対話型のエクスポートには --yes が必要です。

shunt import opencodex --dry-run
shunt import opencodex --provider cursor
shunt import opencodex --from /path/to/copied-opencodex --yes

anthropic、openai-chat、openai-responses の有効な API キーと、Cursor または Command Code の選択中のサブスクリプションアクセストークンを取り込みます（旧形式・複数アカウント形式）。期限切れ、不正、未対応の項目はスキップします。更新トークンと Codex アカウントプールはコピーしません。他のサブスクリプションは個別にログインしてください。

--from で読み取り元を指定します（既定: OPENCODEX_HOME、次に ~/.opencodex）。--provider は複数指定でき、省略すると互換性のある選択中の認証情報をすべて対象にします。--output-dir は保存先の親ディレクトリです（既定: ~/.shunt/imports）。毎回、一意のディレクトリ（0700）と credentials.env（0600）を作成し、過去のスナップショットを保持します。エクスポートは macOS/Linux のみ対応します。

表示されたファイルをシェルで source してから Shunt を起動します。Cursor は SHUNT_CURSOR_AUTH_TOKEN を使います。API キーおよび Command Code アクセストークンは OPENAI_API_KEY、XAI_API_KEY、SHUNT_COMMANDCODE_API_KEY、または SHUNT_IMPORTED_<PROVIDER>_API_KEY（大文字、ハイフンはアンダースコア）です。既存の api_key_env を合わせてください。設定やルーティングは生成しません。自動更新されないため期限切れ時に再インポートしてください。キーのインポートで OpenCode Go などの未対応プロバイダーが有効になることはありません。

shunt run

ゲートウェイを起動します。run はデフォルトのサブコマンドなので、素の shunt でも動作します。

shunt run
shunt run --config /path/to/shunt.toml

起動時に、バインドされたアドレス（デフォルト 127.0.0.1:3001）と共に shunt listening をログに記録します。ログの詳細度は RUST_LOG で設定します。例 RUST_LOG=shunt=debug shunt run。

--config なしの場合、shunt は ./shunt.toml → ~/.config/shunt/shunt.toml → $HOMEBREW_PREFIX/etc/shunt.toml を検索します。--config ありの場合、ファイルが存在しないとエラーになります。Configuration を参照してください。

Homebrew でインストールした場合は、バックグラウンドサービスとして実行することもできます: brew services start shunt。詳細は Installation を参照してください。

shunt check

解決された設定を検証して終了します（shunt --check でも動作します）。

shunt check
# -> config ok

具体的なエラーを報告します: 不正なバインドアドレス、ルート内の未知のプロバイダー、api_key_env の欠落、不正な base_url、誤ったアダプター/認証の組み合わせ。

shunt run の起動時と同じ、ルーティング済み Antigravity 資格情報ガードも実行します: ネイティブ antigravity アップストリームへルーティングしていて資格情報が保存されていない設定は、config ok を出力してから起動時に失敗するのではなく、このチェックで失敗し shunt login antigravity を案内します。このガードはオフラインです — ルートを読み、資格情報の有無（シングルトンファイルまたは名前付きプール候補）を確認するだけで、トークンの更新もバックエンドへの接続も行いません。組み込みの antigravity プロバイダーを宣言しているだけでルーティングしていない設定は影響を受けず、kind = "antigravity_cli" のルーティングも同様です。

[store] がある場合、チェックは完全なオフラインではなくなります。config ok の後にストアを読み取り専用で開き（SQLite ファイルを読むか、PostgreSQL に接続します）、もう 1 行出力します。マイグレーションの実行、データベースの変更、存在しない SQLite ファイルの作成は行いません。ただし、WAL モードのデータベースを検査している間に、SQLite が -wal / -shm の補助ファイルを作成または削除することがあります。

shunt check
# -> config ok
# -> store ok: sqlite sqlite:/var/lib/shunt/shunt.db, schema v1 (binary supports v1)

<target> は sqlite:<path> または postgres://host:port/db で、認証情報は出力されません。検査は最大 15 秒で打ち切られます。検証に失敗する [store]（例: sslmode=verify-full のないリモートの PostgreSQL ホスト）は、それより前に config check failed で失敗します。

shunt init

既存のディレクトリに starter shunt.toml を作成します。このコマンドはそのファイルだけを書き込み、インストールやネットワークアクセスは行いません。

shunt init
shunt init --upstream codex --upstream kimi
shunt init --root /path/to/project
shunt init --force

Upstream を指定しない場合、starter はすべてコメントで構成され、shunt のデフォルト passthrough 設定として読み込まれます。--upstream を繰り返すと、failover 順に preset エントリを追加できます。指定できる名前は anthropic、codex、openai、xai、grok、kimi、cursor、kimi-code、zhipu、minimax-cn、opencode です。Starter は server.default_provider を設定しないため、マッピングされていないトラフィックはデフォルトの Anthropic passthrough のままです。preset を指定すると、生成されたファイルが shunt check を通過しつつこの fallback を維持できるよう、末尾に anthropic passthrough upstream が自動的に追加されます（自分で anthropic を指定した場合を除く）。

Root のデフォルトは現在のディレクトリで、あらかじめ存在している必要があります。そこに shunt.toml、shunt.yaml、shunt.yml のいずれかがある場合、--force なしでは何も書き込まず停止します。強制 init が上書きするのは shunt.toml だけです。YAML variant はそのまま残り、config discovery では新しい TOML ファイルが優先されます。

shunt add

コーディングエージェント向けの組み込み Markdown blueprint を取得します。Blueprint はインストーラーではなく実装ガイドです。このコマンドはファイルの編集、インストール、ネットワークアクセスを行いません。

shunt add                                      # 両方の blueprint kind を一覧表示
shunt add upstream                             # 名前付き upstream ガイドを一覧表示
shunt add upstream kimi --print                # ガイドを 1 つ出力
shunt add upstream https://example.com/docs    # 互換 endpoint を調査
shunt add provider https://example.com/docs    # ソースコード統合を調査

Kind は upstream（提供済み preset または互換 endpoint の設定）と provider（新しい provider protocol サポートへの貢献）です。既知の upstream slug または alias を指定すると名前付きガイドを取得します。空白や認証情報を含まず正しく解析できる絶対 http:// または https:// URL は、その kind の汎用 research ガイドに挿入されます。相対パスや不正な URL は拒否されます。

Blueprint Markdown はエージェントへ直接パイプできるよう、常に stdout へ出力されます。--print はその意図を明示して対話的な stderr hint を抑制しますが、stdout の内容は変えません。

shunt add upstream kimi --print | claude

shunt token

Claude サブスクリプションの OAuth トークンを stdout に出力します（ログは stderr へ）。Claude Code の apiKeyHelper に組み込むよう設計されています。2 つのモード:

• 静的 — SHUNT_GATEWAY_TOKEN または CLAUDE_CODE_OAUTH_TOKEN が設定されている場合、その値を変更せずに出力します。claude setup-token の値を指定すれば、何もリフレッシュされません。
• 自動リフレッシュ — それ以外の場合、~/.claude/.credentials.json（パスは CLAUDE_CREDENTIALS でオーバーライド）を読み込み、claudeAiOauth のアクセストークンを返し、expiresAt の 5 分前以内になったとき platform.claude.com/v1/oauth/token（Claude Code が使うのと同じグラント）に対してリフレッシュし、新しいトークンを他のすべてのフィールドを保ったまま 0600 でアトミックに書き戻します。リフレッシュは、エンドポイントのレート制限を尊重するため、実際の期限切れ時にのみ発生します。

// ~/.claude/settings.json
{
  "apiKeyHelper": "/path/to/shunt token"
}

これが必要になる場面については Connect Claude Code を参照してください。

shunt gateway login

[server.gateway] を有効にした shunt デプロイに、このマシンをサインインさせます。Claude Code の /login が使うものと同じ OAuth device flow です。これはゲートウェイのクライアント側であり、shunt login <provider> と shunt token は変更されておらず、引き続き shunt 自身をアップストリームに対して認証します。

shunt gateway login https://gateway.example.com
shunt gateway login https://gateway.example.com --manual   # ブラウザを開かず URL のみ表示

shunt はデプロイの /.well-known/oauth-authorization-server ドキュメントを読み、そこで告知されたエンドポイントを使います。確認用 URL と短いユーザーコードを表示してブラウザを開き、ゲートウェイの /device ページで承認されるまでポーリングします。discovery が 404 を返す場合、そのデプロイに [server.gateway] セクションが無いことがほとんどです。discovery と device code 要求にはそれぞれ上限があり、接続だけ受け付けて応答しないデプロイはターミナルを無期限に待たせる代わりにタイムアウトとして報告されます。その後の承認ポーリングは待つことが役目なので、同じようには制限しません。ループバック以外の平文 http:// URL も受け付けますが警告が出ます — device code と refresh token が暗号化されずに流れるためで、しかもこのログイン時だけではありません。以降のトークン更新もすべて同じ経路を通り、shunt gateway token は実際に更新を行うたびに同じ警告を再度表示します（ネットワーク呼び出しの無いキャッシュトークン返却時には表示しません）。そしてそのログインは最後まで完了します。平文 http のゲートウェイは平文のエンドポイントを告知できますが、自分自身の origin に限られます — スキーム・ホスト・ポートのすべてが入力した URL と一致していなければなりません。それ以外の origin の平文エンドポイントは拒否されます — ただし、https で接続しているゲートウェイも含め、すべてのゲートウェイに当てはまる例外が 1 つあります。マシンの外に出ないループバックのエンドポイントは常に受け入れられます。ゲートウェイが発行したアクセストークンは、セッションが保存される前に、下の shunt gateway token が適用するのと同じ apiKeyHelper のゲートを通ります。適合するトークンを発行できないデプロイは、成功したと報告しながら決して使えないセッションを残す代わりに、ログインの時点で失敗します。

デプロイが返してくる内容には 2 つの下限が適用されます。shunt が device code と refresh token を POST するのは、discovery ドキュメントが https で、ループバックアドレスに対して http で、または — 入力したゲートウェイ URL 自体が平文 http の場合に — そのゲートウェイ自身の origin に対して http で告知したエンドポイントだけです。それ以外のエンドポイントは資格情報を受け取る代わりに、名前を挙げて discovery が失敗します。この最後の許容範囲は discovery ドキュメントではなく利用者が入力した URL から算出されるため、悪意のある、あるいは中間者に改ざんされた discovery ドキュメントが第三者の平文ホストを指定して refresh token をそこへ POST させることはできません。また確認用 URL を自動的に開くのは http か https のときだけです — その文字列を選ぶのは shunt ではなくゲートウェイなので、他のスキームなら開かなかった理由とともに表示し、たどるかどうかは利用者が判断します。

セッションは ~/.shunt/gateway/session.json に保存され（SHUNT_GATEWAY_SESSION_FILE で上書き可能）、所有者専用で書き込まれます: 0700 のディレクトリ内に 0600 のファイル。

shunt gateway token

ゲートウェイのアクセストークンを stdout にのみ出力します — メッセージや警告、ヒントはすべて stderr に出ます — そのため Claude Code の apiKeyHelper にそのまま接続できます:

// ~/.claude/settings.json
{
  "apiKeyHelper": "/path/to/shunt gateway token"
}

これはアップストリームの Claude サブスクリプショントークンを出力する shunt token とは別のヘルパーです。互いのストレージを読むことはなく、名前の似た SHUNT_GATEWAY_TOKEN 変数はこのコマンドではなく shunt token のものです。

保存済みトークンは有効期限の 5 分前まではそのまま使われ、それ以降にリフレッシュされます。ゲートウェイの refresh token はローテーションする使い捨てなので、リフレッシュは排他ファイルロックの下で実行され、ロック取得後にセッションを読み直します: 複数の Claude Code セッションが同時にヘルパーを呼んでもリフレッシュは 1 回だけで、ローテーションファミリー全体を失効させる再送は起きません。shunt gateway login と shunt gateway logout も同じロックを取得し、自分の書き込みが終わるまで保持します。そのため、進行中のリフレッシュの書き戻しが後から着地して、その結果を取り消してしまうことはありません。

ロックもリフレッシュも無期限には待ちません。ゲートウェイとの各ラウンドトリップにも、ロック取得の待機にも上限があります — 接続だけ受け付けて応答しないデプロイがロックを握ったままだと、そのマシン上の他のすべての apiKeyHelper が何の説明もなく止まってしまうからです。上限を超えるとコマンドは失敗し、ロックファイルのパスを示します。

5 分のバッファに入ったことは、リフレッシュが必要な時期であることを意味し、必須という意味ではありません。キャッシュされたトークンがまだ実際に有効なうちにリフレッシュが失敗した場合、短いネットワーク障害を認証エラーに変える代わりに、stderr に警告を出したうえでそのトークンを返します。実際に期限が切れた後はコマンドが失敗します。このフォールバックには何もローテーションされていないという裏付けが必要なので、refresh token を提示していないことが確実な 2 つの失敗 — discovery の失敗と、接続すら開けなかったトークン要求 — にのみ適用されます。要求が送信された時点から先は、ゲートウェイが既にトークンをローテーションしている可能性があるため、タイムアウト、読めない・解析できない応答、ゲートウェイが名指しするエラーはいずれもコマンドの失敗になります。そこでキャッシュされたトークンを返すと、使い切った refresh token がディスクに残り、次の実行で再送されてしまうからです。Claude Code のヘルパー検証器が拒否するトークン — 空白を含まない印字可能 ASCII 1〜16384 文字以外 — は、何の説明もなく認証を失敗させるために出力される代わりに、ゲートウェイを名指しする診断とともにここで拒否されます。shunt gateway logout はセッションを削除しますが、空の兄弟 .lock ファイルは意図的に残します。logout・login・リフレッシュが直列化する拠り所はその inode であり、削除してしまうと、進行中の保持者は古い inode のロックを持ち続け、次のプロセスは新しく作られた inode をロックすることになって、互いに排他できなくなるからです。

shunt gateway claude

設定ファイルを編集せずに、Claude Code をゲートウェイに接続して起動します:

shunt gateway claude
shunt gateway claude -p 'summarize this repo' --model opus

保存されたセッションのゲートウェイを ANTHROPIC_BASE_URL に設定し、apiKeyHelper をこのバイナリの絶対パス + gateway token に設定したインラインの --settings ドキュメントを付けて claude を実行します。このドキュメントはそのプロセス 1 つだけに適用されます: ~/.claude/settings.json は一切変更されず、シェルで既に export 済みの ANTHROPIC_BASE_URL よりも優先されます（Claude Code 2.1.234 で実測）。

起動されるプロセスの環境からは、資格情報とプロバイダーモードに関する 34 個の変数も取り除かれます: Anthropic・AWS・Foundry の資格情報変数、CLAUDE_CODE_USE_* のプロバイダー選択子とそのリージョン／プロジェクトの兄弟変数、CLAUDE_CODE_SKIP_*_AUTH の修飾子、ホスト管理の間接参照変数、ANTHROPIC_CUSTOM_HEADERS、そして 2 つの *_FILE_DESCRIPTOR リーダー — さらに、起動時に解決して CLAUDE_CODE_HOST_AUTH_ENV_VAR が指す変数も取り除きます。この変数は任意の名前を保持するため、固定のリストでは表現できないからです。これこそが apiKeyHelper を実際に到達可能にしている部分です。settings の env ブロックは継承した環境の上に重ねて適用されるため、そのままでは export 済みの ANTHROPIC_AUTH_TOKEN がヘルパーを完全に上回り（ヘルパーはその変数が無いときにだけ参照されます）、CLAUDE_CODE_USE_GATEWAY はセッションをゲートウェイのプロバイダーモードへ切り替えて、ヘルパーを一切参照しない経路に載せてしまいます。ANTHROPIC_BASE_URL は意図的に残されます — settings ドキュメントが注入する値だからです。

これで閉じられるのはアンビエント環境の経路だけです。資格情報は依然として、settings ファイルの env ブロック（Claude Code が起動後に再適用します）、利用者が自分で設定済みの apiKeyHelper、資格情報ストアに残っている既存のログイン、あるいは 2 つの file-descriptor リーダーが変数無しでも参照する well-known パスのフォールバックを通じて、起動されたクライアントに届きえます。これ自体がセッションのファーストパーティモードを保証するものではありません。

claude 以降の引数はすべてそのまま転送されます。引数リストの先頭に来た場合のみ 2 つの例外があります: --help は shunt のヘルプを表示し、--config は shunt のグローバルオプションに黙って消費される代わりにエラーで拒否されます。どちらも claude に渡すには -- の後ろに置いてください:

shunt gateway claude -- --config /path/to/claude/config

認証情報が apiKeyHelper 経由で渡されるため、セッションはサインイン済みのゲートウェイセッションにはならず、Claude Code の通常のファーストパーティモードのままです — トークンがどの認証情報スロットに届くかがモードを決めます。何を手放すことになるかはゲートウェイログインを参照してください。

shunt gateway logout

保存済みのセッションを破棄します。冪等です — すでに存在しないセッションを削除しても成功します。

shunt gateway logout

shunt login claude

次の 3 つのモードのいずれかで、shunt 管理の Anthropic プールアカウントを作成します。

# Full OAuth: shunt が新しいリフレッシュ可能なログインを取得して保存します（推奨）。
shunt login claude --name primary --mode oauth

# 現在のリフレッシュ可能な Claude Code ログインをインポートします。
shunt login claude --name imported --mode import

# Claude の 1 年間・推論専用 setup-token フローを実行します。
shunt login claude --name ci --mode setup-token

TTY で --mode を省略すると、shunt は oauth、import、setup-token の選択を求め、OAuth をデフォルトの推奨値にします。非対話入力では従来の import デフォルトを維持します。--long-lived は --mode setup-token の deprecated alias として残ります。

--mode oauth は shunt の full-scope PKCE 認可フローを実行し、access token と refresh token の両方を保存します。デフォルトでは、shunt は 127.0.0.1 に一時リスナーをバインドして認可 URL を開き、ブラウザーが http://127.0.0.1:<port>/callback に戻ると完了します。ブラウザーを開けない、リスナーを開始できない、または 5 分以内に callback が届かない場合は、非表示入力の手動貼り付けフローへフォールバックします。SSH や headless 環境では --manual ですぐに手動フローを使えます。

shunt login claude --name remote --mode oauth --manual

--mode import は ~/.claude/.credentials.json（または CLAUDE_CREDENTIALS）を ~/.shunt/accounts/claude/<name>.json へコピーします。refresh token を保持し、Claude Code のグローバル設定にある現在のアカウント UUID と関連付けます。shunt は Claude Code の元ファイルを変更せず、このプライベートコピーをリフレッシュします。

--mode setup-token は claude setup-token と同じ 1 年間・推論専用の PKCE フローを実行します。ブラウザーで承認後、表示された認可コードを shunt の非表示入力プロンプトへ貼り付けます。shunt はコードを直接交換し、opaque token と発行元アカウント UUID の両方を、トークンを表示せずに保存します。

ファイルは Unix で 0700 ディレクトリ内に 0600 でアトミックに書き込まれます。SHUNT_CLAUDE_ACCOUNTS_DIR でストアディレクトリを上書きでき、同じ名前を再利用するとファイルを置き換えます。既存の外部 setup token を参照するには token_env を使います。uuid は必須ではなく、リクエストに埋め込まれたアカウント UUID を書き換えたい場合にのみ指定します — 発行後にアカウント UUID を復元する手段がないため、書き換えが必要なときは明示的に渡してください。

結果は名前だけのプールエントリーで参照するか、provider のアカウントリストを空にしてすべてのストアファイルをスキャンできます。

[[providers.anthropic.accounts]]
name = "primary"

shunt login xai

xAI の device-code OAuth フローを実行し、リフレッシュ可能な credential を保存します。

shunt login xai
shunt login xai --name <account-name>

--name を省略すると、credential は ~/.shunt/xai-auth.json に保存されます（SHUNT_XAI_AUTH_FILE で上書き）。--name を指定すると、代わりに ~/.shunt/accounts/xai/<account-name>.json に保存されます（0600。shunt が作成するストアディレクトリは 0700 になりますが、既存のディレクトリは元の権限のままです。ストアは SHUNT_XAI_ACCOUNTS_DIR で上書き）。そのため名前付きログインが単一アカウントのファイルを上書きすることはありません。同じ名前を再利用するとファイルは置き換えられます。xAI の OAuth トークンは常にリフレッシュ可能なため --mode と --long-lived は拒否され、--manual は claude 専用です。

[[providers.grok.accounts]] エントリー、または auth = { mode = "xai_oauth", accounts = [...] } で名前付きアカウントを参照するか、何も設定せずストア全体をスキャンさせます。設定されたアカウントがなく、ストアも空の場合、provider は単一アカウントのファイルへフォールバックします。名前付きアカウントが 1 つでも存在すると、そのファイルは読まれなくなります。両方のファイルは同じ形式なので、shunt を停止した状態で、まずストアディレクトリを所有者専用で作成してから移すと、既存のログインをプールへ移せます: install -d -m 700 ~/.shunt/accounts/xai && mv ~/.shunt/xai-auth.json ~/.shunt/accounts/xai/<account-name>.json。単一アカウント構成から移行する場合、このディレクトリはまだ存在しません。

xAI はリフレッシュのたびにリフレッシュトークンをローテーションするため、上記の「リフレッシュ可能なログインごとに所有者は 1 つ」というルールが適用されます。1 つの credential ファイルを 2 か所にコピーしたり、2 つの実行中の shunt プロセスで共有したりしないでください。

shunt login kimi

Kimi Code の device-authorization（RFC 8628）OAuth フローを実行し、リフレッシュ可能な credential を保存します。

shunt login kimi --name <account-name>

--name は必須です。省略すると `shunt login kimi` requires --name <account-name> で失敗します。Kimi Code OAuth トークンは常にリフレッシュ可能なため --mode と --long-lived は拒否されます。--manual は claude 専用です。

ログイン時にそのアカウントの X-Msh-Device-Id が一度だけ生成され、以降のリフレッシュのたびに再利用されるため、アカウントは Kimi に対して安定したデバイス識別子を提示します。安定した upstream アカウント識別子を含む Kimi ログインレスポンスはこれまで観測されていないため、スキャンされたエントリーのプール識別子はそのファイル名自体になります。

ファイルは Unix で 0600 でアトミックに書き込まれます。shunt が作成するストアディレクトリは 0700 になります。SHUNT_KIMI_ACCOUNTS_DIR でストアディレクトリを上書きでき、同じ名前を再利用するとファイルを置き換えます。

結果は auth = "kimi_oauth" を使う provider で利用され、これは kind = "anthropic" かつ kimi.com の base URL の場合にのみ有効です。名前だけのプールエントリーで参照します。

[[providers.kimi-code.accounts]]
name = "primary"

config は provider を [[upstreams]] か [providers.*] のどちらか一方で宣言し、両方は使えません。[[upstreams]] の config では、代わりに auth マップでアカウントを指定します: auth = { mode = "kimi_oauth", accounts = ["primary"] }。

Kimi はリフレッシュのたびに refresh token をローテーションし、発行される access token の寿命も約 15 分と短いため、リフレッシュは頻繁に発生します。したがって上記の「リフレッシュ可能なログインは 1 プロセスのみ」の原則がそのまま強く当てはまります。1 つの Kimi アカウントファイルを複数の shunt プロセスで共有すると、最初のリフレッシュで互いを無効化します。

完全な upstream 設定は Kimi を参照してください。

Anthropic アカウントプール認証

auth = "claude_oauth" の Anthropic provider では、アカウントに名前だけのストアエントリー、credentials = "~/.claude/.credentials.json"、または token_env = "YOUR_ENV_NAME" を使えます。ストアエントリーは、上記の Full OAuth、Claude Code ログインのインポート、setup-token フローのいずれかで作成できます。完全な設定と failover ルールは Anthropic マルチアカウント を参照してください。

環境変数