API キーを管理

このガイドでは、Control Center が使用する各認証情報がどこに保存されるか、そしてその変更方法を説明します。

入力しているマシンには何も保存されません。 すべての認証情報はサーバー上にあり、あるリクエストにどの認証情報が応答するかは、その背後に人間がいるかどうかによって決まります。

認証情報	保存場所	使用者
自分のコードホスト / チケットの認証情報	サーバーの 0600 シークレットファイル。自分のユーザー id をキーとする	自分が依頼したものすべて: PR 画面、自分のエージェント実行、自分のイメージ
サーバーのアプリ識別情報	同じファイル。シークレット以外は `server_settings`	人間が依頼していない作業: webhook、PR のポーリング、チケット同期
モデルプロバイダーのキーと OAuth トークン	サーバー自身の認証情報ストア	インストール上のすべてのワークスペースで使用される組み込みアダプター
Slack ボットトークン	サーバー上の `<dataDir>/<workspaceId>/chat_credentials/`	そのワークスペースのチャットブリッジ
外部 CLI の認証情報	その CLI が使用する任意の場所	サーバーホスト上の Claude Code

2 つの GitHub 認証情報と、それぞれが答える別々の問い

自分の認証情報。サインイン（デバイスフロー）またはトークンの貼り付けによって取得します。自分の代理で行われるすべてのリクエストがこれを使用するため、自分のために投稿されたコメントには自分の名前が付きます。他のメンバーはこれを読むことができず、各自が自分の認証情報を接続します
サーバーの認証情報。オペレーターが登録した GitHub App から取得します。呼び出し元のいないものすべてに応答するため、誰かが離脱したりトークンをローテーションしたりしてもコードホストへのアクセスが失われることはありません

自分の認証情報は、設定 → ワークスペース → プロフィールと識別情報のコードホスティングカードで設定します。サーバーの認証情報は、設定 → サーバー → シングルサインオンのプロバイダーアプリで設定します。詳しくは GitHub インテグレーションを設定と GitHub App を作成を参照してください。

モデルプロバイダーのキーを設定する

組み込みアダプターはプロバイダーの認証を自身で行い、それらの認証情報はサーバー上に保存されます。

設定 → サーバー → モデルプロバイダーに移動します
プロバイダーとモデルまでスクロールします
プロバイダーを接続します — OpenAI、Codex、Cursor、Kimi Code はブラウザー OAuth、Anthropic とその他は API キーです

完全なリストとカスタムエンドポイントの追加方法については、アダプターとモデルを管理を参照してください。

これらの認証情報はホスト全体で共通です。1 つのキーがインストール上のすべてのワークスペースで使われます。OAuth トークンは有効期限が切れる前に更新されます。

外部アダプター CLI は、サーバーホスト上の独自の設定の中に、独自の認証情報を保持します — Control Center はそれらを管理しません。Claude Code は、cc_server が実行されているマシン上で、そのドキュメントに記載されている方法で認証してください。

アダプターごとの環境変数ダイアログは、それらのいずれかのキーを入れる場所のように見えますが、そうではありません。これは自分のデバイスに書き込むのに対し、サーバーは自身のコピーを読み取り、両者をつなぐものはありません。詳しくはアダプターとモデルを管理を参照してください。

チケッティングベンダーを接続する

設定 → ワークスペース → 全般のチケット管理カードは、1 つの決定の両方の側面を扱います。チケットがどのベンダーにあるか、そしてそのための認証情報です。ローカルを選ぶと認証情報の行は非表示になります — ローカルのチケットはこのサーバー自身のデータベースにあり、認証する対象がないためです。

自分のキーは、コードホストのものと同様に、サーバー上で自分のユーザー id に紐づけて保存されます。サーバーは自身の Linear キーを別途（プロバイダーアプリに）保持しており、人間が依頼していないときにチケット同期が動作するのはこれによります。エージェントのサンドボックスにチケットのキーが注入されることはありません。エージェントは Control Center のツールでチケットを書き込み、それらのツールが外部トラッカーへの書き込みのルールに問い合わせます。詳しくは Linear インテグレーションを設定を参照してください。

ローテーションまたは失効

自分の GitHub 認証情報: 切断を押してから、もう一度サインインするか新しいトークンを貼り付けます。古いトークンは GitHub 側で失効させます
サーバーのアプリ: アプリの GitHub ページで新しい秘密鍵またはクライアントシークレットを生成し、プロバイダーアプリに貼り付けてテストを押します
モデルプロバイダー: その行でサインアウトする（OAuth）かキーを削除してから、もう一度接続します
Slack: 接続ダイアログでトークンを貼り直します。詳しくは Slack インテグレーションを設定を参照してください

トラブルシューティング

PR 一覧が空なのに、トークンは `curl` では機能する

コードホスティングの行のサブタイトルを確認します。そこに別のソース（「このサーバーのアプリ経由」「環境変数から」）が示されている場合、テストしている認証情報は応答しているものではありません — 自分の認証情報は保存されていません。

トークンは受け入れられるのに、後続のリクエストが失敗する

トークンは保存された状態のまま検証されるため、その行には背後にあるアカウント名が表示されます — ただしアカウントのみで、スコープは表示されません。スコープが足りないトークンは接続には成功しますが、個々のリクエストで失敗します。スコープと有効期限を確認してください:

curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/user