Skip to Content
ユーザーガイド機能チャンネルGitHub

GitHub

このガイドでは、GitHub の通知を監視し、メンション・レビューリクエスト・アサイン・フォロー中スレッドのアクティビティに応答する Qwen Code チャネルの設定方法を説明します。

前提条件

  • 通知の読み取りとコメントの投稿に必要な権限で認証された GitHub アカウント
  • ローカルの gh 認証を使用する場合、Qwen Code を実行するホストに GitHub CLI  がインストールされていること

認証アカウントがチャネル自体も操作する場合は、専用のボットアカウントを使用してください。GitHub は自身のアカウントのアクティビティに対して利用可能な通知を生成せず、アダプターはループ応答を防ぐために自身のコメントを無視します。

認証

Qwen Code ホストで GitHub CLI のログインを再利用するには、gh を認証し、チャネル設定で useLocalGh: true を明示的に設定します。

gh auth login

ローカルの gh 認証はアカウント全体に適用され、その GitHub アカウントから見えるすべてのリポジトリの通知が公開される可能性があります。ワークスペースのオペレーターがそのアカウントの使用を信頼できる場合にのみ有効にしてください。それ以外の場合は、専用の PAT を設定してください。

GitHub Enterprise Server の場合は、baseUrl で使用するのと同じホストで認証してください。

gh auth login --hostname github.example.com

代わりにクラシックパーソナルアクセストークン（PAT）を設定することもできます。明示的な token はローカルの gh 認証より優先されます。PAT には以下のスコープが必要です。

  • notifications — 通知スレッドの読み取り
  • public_repo（プライベートリポジトリの場合は repo）— コメントの投稿

設定

チャネルを ~/.qwen/settings.json に追加します。

{
  "channels": {
    "my-github": {
      "type": "github",
      "useLocalGh": true,
      "pollInterval": 60000,
      "reasonFilter": ["mention", "review_requested", "assign"],
      "senderPolicy": "allowlist",
      "allowedUsers": ["operator-github-username"],
      "sessionScope": "chat_thread",
      "cwd": "/path/to/your/project",
      "blockStreaming": "off",
      "groupPolicy": "open",
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}

ローカルの gh 認証を PAT でオーバーライドするには、チャネルに "token": "$GITHUB_TOKEN" を追加し、Qwen Code を起動する前に環境変数を設定します。

export GITHUB_TOKEN="ghp_your_token_here"

認証アカウントは自身のチャネルをトリガーできません。そのアカウントでチャネルを操作する必要がある場合は、別のボットアカウントを認証し、allowedUsers にはオペレーターアカウントのみを設定してください。起動時に、認証アカウントのみの許可リストは拒否され、他のオペレーターと一緒に含まれている場合は警告が表示されます。

GitHub Enterprise

GitHub Enterprise Server の場合は、baseUrl を設定します。

{
  "baseUrl": "https://github.example.com/api/v3"
}

ローカルの gh 認証には HTTPS の baseUrl が必要です。これにより、デーモンホストの認証情報が平文 HTTP で送信されることを防ぎます。

設定オプション

オプションデフォルト説明
token未設定notifications スコープ付きのオプションのクラシック PAT。ローカルの gh 認証より優先される
useLocalGhfalseデーモンホストのアカウント全体の GitHub CLI 認証を明示的に再利用する
pollInterval60000ポーリング間隔（ミリ秒）
baseUrlhttps://api.github.comAPI ベース URL（GHE 用）
groupPolicy"disabled"通知を流すには "open" が必要
senderPolicy"allowlist"ボットをトリガーできるユーザー
groups.*.requireMentiontrue通常のコメントに @メンションを要求する。通知理由が直接指定されている場合は引き続き実行される
blockStreaming"off"常に "off" に固定される。中間モデルチャンクは公開されない。"on" はサポートされない
reasonFilter未設定処理する GitHub 通知理由のオプションの許可リスト

reasonFilter を使用して、ci_activity や state_change などのノイズの多い通知クラスを除外します。groups.*.requireMention の代わりに reasonFilter: ["mention"] を使用しないでください。GitHub の mention 理由はスレッドレベルで保持されるため、実際の新しい @メンションが後から comment、subscribed、author、またはその他の理由で届くことがあり、それらはスキップされてしまいます。

有効な reasonFilter の値は mention、review_requested、assign、author、comment、ci_activity、manual、state_change、subscribed、team_mention、security_alert、approval_requested、invitation、member_feature_requested、security_advisory_credit です。

フィルタリングされた通知は、ポーリングウィンドウ内のすべての受け入れ済みワークが完了した後にのみ既読としてマークされます。後でフィルターを削除しても、チャネルがすでにスキップした通知が再処理されることはありません。

⚠️ セキュリティ

パブリックリポジトリで senderPolicy: "open" を設定すると、サポートされている通知理由をトリガーする 任意の GitHub ユーザーが、cwd でエージェントを操作するプロンプトを送信できるようになります。これにはコードの読み取り、トークンの消費、コメントの投稿、および（権限ポリシーに応じて）ツールの実行が含まれます。

パブリックリポジトリでは、常に senderPolicy: "allowlist" を明示的な allowedUsers とともに使用してください。

許可リストとペアリングのエントリは、不変のアカウント ID ではなくユーザー名に従います。許可されたユーザーが GitHub アカウント名を変更した場合、古いエントリを削除してください。GitHub は古いユーザー名を誰でも取得できるようにリリースするため、新しい保持者が許可リスト/ペアリングの認証を継承してしまいます。

メンション検出

アダプターは、コメントテキストと初回コンタクトの issue または PR 本文をスキャンし、大文字小文字を区別しない正規表現で @bot-username を検出することでメンションを検出します。reason: "mention" の値はスレッドレベルで保持されるため、それ単体を信頼しません。その他の理由は、レビュー、トリアージ、フォロー中スレッド、またはフォールバックのプロンプトを選択します。

仕組み

アダプターは GitHub の Notifications API をウェイクアップシグナルとして使用します。

  1. ポーリング: GET /notifications で未読スレッドを取得
  2. 列挙: カーソルベースのタイムウィンドウ内で listComments によりコメントを列挙
  3. 受け入れ済みワークの永続化: ディスパッチ前に、ソースエンベロープと重複排除キーを含めて保存
  4. ディスパッチ: 通知理由別に実行。厳密なメンションマッチング、プルリクエストレビュー、issue トリアージ、フォロー中スレッドのコメント集約、またはコメントごとのフォールバック
  5. ポーリングウィンドウのコミット: 受け入れ済みワークが完了した後でのみ、通知を既読にしてカーソルを進める
  6. 初回コンタクトのフォールバック: コメントがディスパッチされていない場合、真新しい未読 issue/PR 本文を処理できる。メンション通知は引き続き本文での実際のメンションを必要とする

コメントウィンドウは (previousCursor, currentMaxUpdatedAt] です。受け入れ済み、実行中、失敗したタスクは ~/.qwen/channels/<workspace-scope>/ にプライベートファイル権限で保存されます。再起動時、チャネルは GitHub を再度ポーリングする前にそれらのタスクを復旧します。失敗したタスクは最大 3 回再試行され、その後終端状態になります。キャンセルされたタスクは終端であり、再実行されません。最終返信がすでに投稿、抑制、または確定的な書き込みなしリトライのためにキューに入れられたタスクは再実行されません。

復旧可能なタスクが残っている間、または受信タスク状態の読み取り・書き込みができない間は、通知カーソルは進みません。これにより、クラッシュやエージェントの失敗によって受け入れ済みのコメントが失われるのを防ぎ、通知フィードからの 2 回目のディスパッチを避けるために必要な重複排除キーが保持されます。

コメント以外のアクティビティ（プッシュ、ラベル変更）は通知の updated_at を更新しますが、ウィンドウ内に新しいコメントを生成しないため、再取得されたスレッドはエージェントをトリガーせずにスキップされます。

レスポンスフィードバック

受け入れられた issue またはプルリクエストのコメントに対して、チャネルはエージェントが作業中に GitHub の 👀 リアクションを追加し、実行が完了、失敗、またはキャンセルされたときに削除します。どちらの操作もベストエフォートです。リアクション API または権限の失敗はログに記録され、最終レスポンスを妨げることはありません。

最終出力のみ

GitHub チャネルは常に最終出力のみの配信を強制します。アダプターは blockStreaming を "off" に設定するため、中間モデルチャンクは別のコメントとして公開されず、blockStreaming: "on" はサポートされません。

{
  "blockStreaming": "off"
}

GitHub がレートリミットレスポンスなどの確定的な書き込み失敗を返した場合、チャネルは最終返信を ~/.qwen/channels/<workspace-scope>/<channel>-<name-hash>-github-pending-deliveries.json にプライベートファイル権限で保存し、次回のチャネル起動時に再試行します。対応する受信タスクは、その配信が成功するか確定的な終端失敗に達するまで reply_pending 状態のままです。あいまいな配信失敗は自動的に再試行されません。GitHub がコメントを作成した可能性があるためです。

既知の制限

  • 初回起動時に既存の未読通知をスキップします。 カーソルは初回起動時に「現在」に初期化されます。ボット開始前に作成された通知は、その後スレッドに新しいアクティビティがない限り処理されません。
  • ユーザーがボットのポーリングサイクルより前に github.com で通知を既読にした場合、ボットはそれを処理しません。
  • ボットは現在のポーリングウィンドウより前のコメントを読み取りません。author および comment 通知はそのウィンドウから最大 20 件のコメントを集約する場合があります。
  • インライン PR レビューコメントとレビューサマリー本文は列挙されません。issue/PR コメントのみが処理されます。
  • 選択された認証情報が Notifications API をサポートしている必要があります。Fine-grained PAT はサポートしていません。ローカルの gh 認証または notifications スコープ付きのクラシック PAT を使用してください。

チャネルの起動

qwen channel start my-github
Last updated on
Feishu (Lark)GitLab