Claude Media
claude ultrareviewのtrust-workspaceでWorkspace not trustedを解消
Claude CodeTips

claude ultrareviewのtrust-workspaceでWorkspace not trustedを解消

claude ultrareviewがError: Workspace not trustedで終了する原因と、--trust-workspace・環境変数・手動の信頼承認の使い分けを、CI向けに解説します。

読了目安 約14分

このTipsでできること

CIやスクリプトからclaude ultrareviewを動かすと、レビューが始まる前にError: Workspace not trustedで終了することがあります。原因は、実行フォルダを信頼してよいかをコマンドが尋ねられない状況にあります。対処は3通りで、--trust-workspaceフラグ、環境変数CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK、手元で信頼ダイアログを承認する方法です。いずれもv2.1.309以降の話です。ultrareview自体の使い方はultrareviewの使い方にあります。

なぜCIでだけ止まるのか

claude ultrareviewは、v2.1.309でワークスペースの信頼を必須にする変更が入りました。変更履歴には、端末では信頼を尋ね、尋ねられない場面では拒否すると書かれています。

端末で実行すると、次の質問が出ます。

Trust <folder>? [y/N]

yと答えれば進みます。質問できないのは、標準入力か標準出力が端末でないときです。CIジョブのほか、claude ultrareview --json > findings.jsonのように出力をファイルへ流す場合も、標準出力が端末でなくなるので質問できません。その場合は次のエラーで終了コード1になり、レビューは始まりません。

Error: Workspace not trusted. Please run `claude` in /Users/you/project first to review and accept the workspace trust dialog. Or, in a script or CI job, pass `--trust-workspace` to trust the folder for this run only.

3つの対処の使い分け

くらべる

信頼の渡し方で何が違うか

実行ごとに明示

--trust-workspace

その実行1回だけフォルダを信頼します。コマンド行に残るので、スクリプトを読めば信頼している箇所が分かります。

環境ごとに一括

環境変数 =1

起動する環境にCLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1を設定します。質問できない実行すべてで、確認が省かれます。

手元でclaudeを実行して信頼ダイアログを承認する方法も、エラーページが案内しています。ダイアログの意味や設定との関係はWorkspace has not been trustedの警告にあります。ただしCIの使い捨て環境では承認の保存先が残らないため、実質は上の2つから選ぶことになります。

フラグ: --trust-workspace

信頼を、そのコマンド1回に限って与えるフラグです。質問は出ません。

claude ultrareview 1234 --trust-workspace
claude ultrareview origin/main --trust-workspace

注意点は引数の位置です。--trust-workspaceは値を取りません。PR番号やベースブランチを渡すなら、フラグより前に置きます。

# 正しい: 対象を先に、フラグを後ろに
claude ultrareview 1234 --trust-workspace
 
# 誤り: フラグの後ろに対象を置く
claude ultrareview --trust-workspace 1234

後者はフラグの直後に値のようなものが続くため、Ultrareview did not start: `--trust-workspace` takes no valueで止まります。falseのような値を付けても同じ扱いで、無効にはなりません。信頼したくないときは、フラグ自体を外します。

環境変数: CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK

1を設定すると、質問できない状況でもError: Workspace not trustedで終了しなくなります。公式のメモには、守るべき条件が3つあります。

  • 設定は、Claude Codeを起動する環境に置く。settingsのenvブロックには置かない
  • 対象は、質問できない実行だけ。質問できる実行では、今までどおり尋ねられる
  • 使ってよいのは、その環境で動く実行がすべて信頼できるフォルダから始まる場合だけ

CIのジョブ定義で環境変数として渡す形になります。

export CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1
claude ultrareview origin/main

ジョブ定義の側では、ステップのenv:に置く方法と、run:の行にフラグを付ける方法の2通りがあります。GitHub Actionsの書式で並べると次のとおりです。

# 方式A: 環境変数(このステップで動く実行すべてに効く)
- name: ultrareview
  env:
    CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK: "1"
  run: claude ultrareview origin/main
 
# 方式B: フラグ(この1行のコマンドだけに効く)
- name: ultrareview
  run: claude ultrareview origin/main --trust-workspace

ここで言う「環境」は、Claude Codeを起動するプロセスの環境です。上のenv:はそのプロセスに渡る環境変数なので条件を満たします。一方、settingsのenvブロックに同じ変数を書いても、この用途には使えません。上の3条件のとおり、置き場所はジョブ側の環境に限られます。リポジトリに置く設定ファイルは、信頼できるかを確かめたいフォルダの側にあるものです。迂回の可否をジョブ定義の側で握っておくという意味でも、env:かフラグを選ぶ形になります。

フラグとの違いは、信頼の判断がコマンド行から環境の設定へ移ることです。ジョブが1つでレビュー対象が自社のリポジトリだけなら、どちらでも差は出ません。同じ環境で複数のリポジトリを順に処理するなら、フラグのほうが、どこで信頼を与えたかが読み取りやすくなります。

信頼してよい範囲を決める

フラグも環境変数も、信頼の質問を飛ばすだけで、中身が安全かを確かめてくれるわけではありません。信頼するのは、コードを信頼できるときに限ります。理由は、信頼したフォルダではgitとClaude Codeが、そのgit設定とプロジェクト設定に書かれたプログラムを実行できるようになるためです。

第三者から届いたプルリクエストをレビューしたいときの手順は、次のとおりです。信頼している自分のブランチから、PR番号を指定して実行します。

claude ultrareview 1234 --trust-workspace

PRはクラウド側でクローンされるため、そのブランチをローカルに持っている必要がありません。信頼を与える対象は手元の信頼できるフォルダで、PRの中身ではない、という分け方です。ブランチを信頼できるかを、実行前に決めておくことになります。

別のメッセージが出たとき

同じ系統のエラーでも、直し方が違うものがあります。公式のエラーページは、すべてレビューが始まっておらず終了コードは1だと説明しています。

表示意味と次の一手
Error: Workspace not trusted. This terminal ...意味と次の一手端末が行数・列数を返さない、または質問と警告が収まらない。ウィンドウを広げるか、サイズを報告する端末で再実行
Error: Workspace not trusted. <folder> is your home directory意味と次の一手ホームディレクトリの信頼は保存されない。プロジェクトのフォルダから実行するか--trust-workspaceを付ける
No answer in time. に続くError: Workspace not trusted意味と次の一手質問に5分間答えなかった。再実行して答える
Ultrareview did not start: <folder> is not trusted意味と次の一手nかEnterで断った。やり直してyと答える
Ultrareview did not start: `--trust-workspace` takes no value意味と次の一手フラグの後ろに値がある。対象をフラグより前に移す

信頼以外の理由で始まらない場合は、GitHubアカウントの接続エラーで原因を切り分けられます。

終了コードはどのメッセージでも1で、コードからは違いが分かりません。CIログでは出力の先頭の文字列(Error: Workspace not trustedかUltrareview did not start:か)を見て表のどの行かを判別します。ジョブの失敗通知に、標準エラーの末尾数行を付けておくと切り分けが速くなります。なお、信頼の質問にnやEnterで答えた場合だけでなくCtrl-Cで中断した場合も、終了コードは1です。

ホームディレクトリは見落としやすい落とし穴です。信頼の保存が行われないため、claudeを先に実行しても解決しません。CIのワーカーで作業ディレクトリがホームのままになっている場合は、リポジトリのフォルダへ移ってから実行します。

終了コードと出力をCIで扱う

信頼エラーを越えたあとは、終了コードと出力の扱いが問題になります。claude ultrareviewの終了コードは3種類です。

  • 0: レビューが完了した(指摘の有無は問わない)
  • 1: 起動に失敗した、途中で止まった、クラウドセッションがエラーになった、タイムアウトした。フォルダが信頼されていない場合も1
  • 130: 起動中・結果待ち・--postのコメント送信中にCtrl-Cを押した

つまり、指摘が見つかってもジョブは成功のままです。指摘があればジョブを落とす運用にするなら、出力を自分で判定する必要があります。--jsonを付けると整形前のbugs.json相当の内容が標準出力に出ます。進捗メッセージは標準エラーに出るので、標準出力は取り込みやすい状態に保たれます。待ち時間の上限は--timeout <分>で変えられ、既定は45分です。

claude ultrareview origin/main --trust-workspace \
  --json --timeout 30 > findings.json
echo "exit: $?"

終了コード1のときは、結果が端末に届いていません。クラウドではレビューが続いている場合がありますが、同じコマンドを再実行しても続きから再開せず、新しいレビューが始まります。新しいレビューは、無料枠か利用クレジットの課金対象になります。信頼エラーはレビュー開始前なので、この心配は要りません。

切り分けの順番

切り分け

Workspace not trustedの切り分け

  1. QClaude Codeはv2.1.309以降か?
    答えが更新する

    v2.1.309より前のclaude ultrareviewは--trust-workspaceを受け付けません。

    答えがはい
  2. Qエラーの先頭はError: Workspace not trusted.か?
    答えが表の別メッセージを確認

    Ultrareview did not start:で始まるなら、断ったか、フラグの後ろに値が付いています。

    答えがはい
  3. Q実行場所はホームディレクトリではないか?
    答えがリポジトリのフォルダへ移る

    ホームの信頼は保存されないので、ここでは--trust-workspaceが唯一の近道です。

    答えがはい

CIなら対象を先に、--trust-workspaceを後ろに付ける

信頼できるコードのときに限り、フラグか環境変数で渡します。

よくある質問

claude -p '/code-review ultra'ならエラーにならないのか

この形では結果が得られません。-pで起動したレビューは、クラウドでの実行を始めたあと完了を待たずに終了します。しかもレビューが利用クレジットの課金対象になる場合は、起動せずに止まります。スクリプトで結果を受け取るならclaude ultrareviewを使います。

まとめ

エラーの正体は、尋ねられない場面でフォルダの信頼が確認できないことです。CIではコマンドごとに--trust-workspaceを付けるのが追跡しやすく、環境全体で許すなら環境変数を使います。どちらも、実行するフォルダのコードを信頼できることが前提です。

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

関連する記事

Claude Code をもっと見る →