Claude Media
Claude DesktopでGitLabのMRが紐付かない — Unknown GitHub hostの原因と回避策
Claude CodeTips

Claude DesktopでGitLabのMRが紐付かない — Unknown GitHub hostの原因と回避策

DesktopのCodeタブで自己ホストGitLabのMRが紐付かない、紐付いてもCI checksが「Unknown GitHub host」で読めない。2件の報告から症状を切り分け、今できる回避策をまとめます。

読了目安 約10分

Claude DesktopのCodeタブで自己ホストGitLabを使っていて、MRがセッションに紐付かない、あるいは紐付いてもCIの状態が読めないなら、同じ時期に出た2つの不具合報告が当てはまる可能性があります。症状は別々です。

  • 紐付かない: 10月上旬のアプリ更新以降、新しいセッションにMRが自動で紐付かなくなった
  • 紐付くがCIが読めない: 紐付いたMRのchecksがUnknown GitHub hostで取得できず、パイプラインの完了を誰も見張らない

どちらもGitHubのissueでopenのままで、修正版の案内はありません。この記事では、報告された内容を症状ごとに並べ、手元で試せる切り分けと回避策を書きます。

症状は2種類ある

同じ「GitLab連携が効かない」でも、起きている場所が違います。先に表で見分けます。

症状A: 自動で紐付かない症状B: 紐付くがchecksが読めない
報告症状A: 自動で紐付かない#100417症状B: 紐付くがchecksが読めない#100158
見えること症状A: 自動で紐付かないサイドバーにMRバッジが出ない症状B: 紐付くがchecksが読めないMRは出るがchecks.availableがfalse
エラー文症状A: 自動で紐付かないなし(prsフィールド自体が無い)症状B: 紐付くがchecksが読めないUnknown GitHub host "<ホスト名>"
手動のbind_pr症状A: 自動で紐付かない動く(macOSの追加報告)症状B: 紐付くがchecksが読めない紐付けは通るが、状態更新が止まるという追加報告あり
報告された環境症状A: 自動で紐付かないWindows 11、macOS(自己ホストGitLab)症状B: 紐付くがchecksが読めないmacOS(自己ホストGitLab)

AとBは別のissueですが、Bに付いたコメントは「Aと同じ10月上旬の更新から始まった」と書いています。同じ原因かどうかは、issueのやり取りからは分かりません。

症状A: 2.19675.1からMRが自動で紐付かない

#100417は、Windows版Desktopの利用者が10月8日に立てた報告です。Codeタブのローカルセッションは、以前はGitLabのMRを自動で紐付け、サイドバーに状態バッジを出していました。アプリを2.19675.1に更新した10月6日以降、新しいセッションには1件も紐付かなくなったとあります。

報告者がセッションのデータファイルから数えた結果は次のとおりです。

アプリのバージョンセッション数MRが紐付いた数
2.7032.0〜2.16120.0セッション数27MRが紐付いた数15
2.19675.0セッション数15MRが紐付いた数13
2.19675.1セッション数14MRが紐付いた数0
2.26454.0 / 2.26454.2セッション数43MRが紐付いた数0

紐付いたセッションのデータには、prsというフィールドがあり、providerがgitlab、host、MRのURL、stateが入っています。2.19675.1以降のセッションにはこのフィールドがありません。報告者はbind_prを手で呼んだ覚えがなく、自動検出が壊れたと見ています。

glabはログイン済みで、自己ホストのGitLabへのAPI呼び出しも通る状態で再現しています。期限切れだったgitlab.comのトークンを入れ直しても、GitLab MCPコネクタを認可し直しても変わりませんでした。

追加のコメントでは、macOS 27.0.1とClaude desktop 2.26454.2でも同じ症状が出て、Windows固有ではないと書かれています。手動でbind_prを呼べば紐付けは通るとのことです。

症状B: MRは紐付くのにchecksが読めない

#100158は、macOSの利用者が10月7日に立てた報告です。Codeタブで自己ホストGitLabのMRがセッションに紐付き、get_statusはMRの番号・状態・ブランチを返します。ところがCIのchecksだけが取れません。

get_statusの返り値は次の形です(報告より、ホスト名は伏せ字)。

"pr": { "number": <iid>, "host": "gitlab.example.com", "state": "open" },
"checks": { "available": false, "error": "Unknown GitHub host \"gitlab.example.com\"." },
"monitor": { "auto_fix": false, "address_comments": false }

アプリのログ(macOSでは~/Library/Logs/Claude/main.log)には[GitHubPrManager] Bound gitlab #<iid> to session …と出ています。MR自体はGitLab向けの経路で読めているのに、checksの取得だけがGitHub専用のコードを通っているように見える、というのが報告者の読みです。

結果として、PRモニターはCIイベントを一度も送らず、Auto-fixも動きません。報告者の環境は、Claude Code 2.1.289(Claude desktop 2.26454.0に同梱)です。

Claudeが待機を断る理由

もう一つ困るのが、Claude自身が待ってくれない点です。報告によると、Codeタブのセッションでは、システムプロンプトに次の趣旨の指示が入っています。

never schedule or poll CI checks yourself (CronCreate, ScheduleWakeup, /loop, Monitor, gh polling)

CIはアプリのモニターが見る前提なので、Claudeは自分でポーリングしません。GitLabの場合はそのモニターがchecksを読めないため、「パイプラインが終わったら教えて」と頼んでも、Claudeはこの指示を引いて断ります。見張る側が誰もいない状態です。

同じ指示が引き起こす問題は、Azure DevOpsでも#98774として報告されています。そちらはPRモニターがそもそも紐付けできない例で、10月1日に立ち、openです。

切り分けの手順

自分の環境がどちらに当たるかは、次の順で確かめられます。

切り分け

GitLab連携が効かないときの切り分け

  1. QサイドバーやPRバーにMRが出ているか?
    答えが出ていない

    症状Aの可能性があります。アプリのバージョンを確認し、2.19675.1以降なら#100417と同じ状況です。Claudeにbind_prでMRのURLを渡して手動で紐付けられるか試します。

    答えがはい
  2. Qget_statusのchecksはavailable: trueか?
    答えがfalseでUnknown GitHub host

    症状Bです。glabの認証が通っていても起きる報告なので、認証を疑って入れ直す必要はありません。回避策の節に進みます。

    答えがはい
  3. QMRバッジの状態やパイプラインが更新されるか?
    答えが紐付け時の値で止まる

    #100158のコメントに同じ報告があります。手動で紐付けたあと、MRの状態もパイプラインも紐付け時の値のまま変わらないという内容です。

    答えがはい

どれにも当たらないとき

ghの認証切れ表示が出ているなら、#96503が近い症状です。このissueはclosedで、GitLabのMRにGitHub CLIの認証切れ警告が出る内容でした。

今できる回避策

アプリ側が直るまでの間、次の方法が使えます。どれもissueで報告者が試したか、報告に含まれる事実から導けるものです。

MRは手動で紐付ける

症状Aでは、bind_prを手で呼ぶ紐付けは通ると報告されています。Codeタブのセッションで、MRのURLを添えて「このMRをbind_prで紐付けて」と頼めば足ります。ただし症状Bのとおり、紐付いてもchecksは読めません。

CIの完了待ちはCLIで

#100158の報告者は、/loopはCLIなら使えるので、取りこぼしはDesktopだけだと書いています。パイプラインを見張りたい作業は、CLIのClaude Codeセッションに回す方法があります。

glabで状態を取りに行く

glabは自己ホストのホストに対しても使えます。報告者はパイプラインの状態をこのコマンドで取得しています。

glab api --hostname gitlab.example.com \
  projects/<project-id>/pipelines/<pipeline-id>

返るJSONのstatusを、別のターミナルで間隔を置いて読めば、完了を自分で見張れます。例えば次のような形です(jqが必要な例で、実行中と待機中だけを待ちます)。

while s=$(glab api --hostname gitlab.example.com \
  projects/<project-id>/pipelines/<pipeline-id> \
  | jq -r .status); [ "$s" = running ] || [ "$s" = pending ]; do
  sleep 30
done; echo "$s"

フック系プラグインで通知する

#100158の報告者は、glab apiを定期実行して完了を通知するプラグインを作っています。ただしセッションを起こすことはできないため、完了をユーザーに知らせるだけで、Auto-fixは使えません。

報告者が求めている修正

#100158が挙げる修正案は2つです。

  1. GitLabのバインディングでも、glab経由でCIを読む。MRのパイプライン、そのジョブ、トリガーで起動した子パイプラインを対象にし、checks.availableがtrueになれば、Auto-fixとci-monitor-eventがgitlab.comにも自己ホストにも効く
  2. それまでの間、「CIをポーリングしない」という指示は、紐付いたPRのchecksが読める場合だけに限る。これは#98774がAzure DevOps向けに提案している修正と同じ形で、ユーザーが頼めばClaudeがポーリングできるようになる

報告者はこれに加えて、MRを持たない単独のパイプライン(glab ci runで起動したE2Eスイートなど)も監視できると助かると書いています。

報告に添えると進みやすい情報

すでに同じ症状のissueがあるので、新規に立てるより既存のissueにコメントするほうが集約されます。コメントには次の情報が書かれていました。

  • Claude desktopのビルド番号(例: 2.26454.2)と同梱のClaude Codeのバージョン
  • OSとGitLabの種別(自己ホストかgitlab.comか)
  • get_statusの返り値のchecks部分
  • main.logのBound gitlab行の有無

CLIのglabでMRを扱う手順はClaude Code GitLab連携ガイドに、フッターのMRバッジの出方はClaude Code PRレビューステータスの見方にあります。GitLab CI/CD側に@claudeを組み込む場合はGitLab CI/CDへの組み込みが別の経路です。

まとめ

DesktopのGitLab連携では、MRを見つける部分とCIを読む部分が別々に壊れうる、というのが2件の報告から言えることです。エラー文が「Unknown GitHub host」であることから、checksの取得がGitHub向けの経路を通っている可能性を報告者は指摘していますが、原因は確定していません。

どちらの症状でも、Desktop単独ではCIの完了待ちを任せられません。CIの結果を受けて直す作業は、最初からCLIのセッションで始めたほうが手戻りが少なくなります。両issueはopenのままなので、修正の有無はコメント欄で追えます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →