SSD Nodes Learn Hosting plans →
ガイド Matt Connor著者 Matt Connor

Claude Code クラウド環境の設定：セットアップスクリプトとフックの使い分け

Claude Code のクラウドセッションで npm install が失敗する、API キーの置き場がない、起動が遅い、フックが動かない。原因と直し方を、ネットワーク、セットアップスクリプト、環境変数、シークレットの順に説明します。

Claude Code のクラウド環境で何を設定するのか

Claude Code のクラウド環境は、クラウドセッションが動く VM（仮想マシン）の設定をひとまとめにしたものです。環境ごとに、ネットワークの許可範囲、セットアップスクリプト、環境変数、ネットワークシークレットを持ちます。npm install が失敗する、API キーの置き場所がない、起動が遅い、ローカルで動くフックがクラウドでは動かない。こうした問題の多くは、セッションではなく環境の設定で解決します。

対象は、すでにクラウドセッションを使っている開発者です。始め方は、ブラウザの claude.ai/code、Claude モバイルアプリの Code タブ、Desktop アプリで Local ではなく Cloud を選ぶ方法、ターミナルの claude --cloud、ルーティンのどれでも構いません。どこから始めても、同じ環境が使われます。料金、クレジット、セッションがどこで動くかは クラウドセッションのクレジットと実行場所 で扱っているので、ここでは繰り返しません。

以下の内容は、2026 年 10 月 16 日に code.claude.com の公式ドキュメント（cloud-environments、claude-code-on-the-web、self-hosted-environments、interactive-mode、tools-reference の各ページ）で確認したものです。画面の項目名は英語のまま書きます。

クラウドセッションの VM はどんなマシンか

Anthropic がホストする環境では、セッションごとに新しい VM が作られます。OS は Ubuntu 24.04、CPU アーキテクチャは x86_64 です。手元のマシンの OS や CPU とは関係ありません。手元が Apple Silicon の Mac でも、VM は x86_64 です。

このため、ビルド済みバイナリを配るツールは x86_64 の Linux 版を使います。arm64 用のバイナリを決め打ちでダウンロードするスクリプトは、VM 上では動きません。bash は cannot execute binary file: Exec format error を出して止まります。原因はコードではなく、アーキテクチャの違いです。

リソースの上限は、目安として 4 vCPU、16 GB の RAM、30 GB のディスクと公開されています。ドキュメントには今後変わる可能性があると書かれているので、大きな作業の前には公式ページを確認してください。メモリを大量に使うビルドやテストは、VM に止められることがあります。それを超える作業は、Remote Control で自分のマシン上の Claude Code を使うか、VPS 上の tmux で Claude Code を動かす構成 のように、自分で管理するハードウェアに移すほうが確実です。

よく使うツールは最初から入っています。Python、Node.js 20、21、22（PATH 上は 22）、Ruby、PHP 8.3、OpenJDK 21、Go、Rust、GCC と Clang、Docker と docker compose、PostgreSQL 16、Redis 7.0、git、gh、jq などです。ほとんどのツールのバージョンは、Claude に check-tools の実行を頼めば分かります。これは VM に入っているシェルコマンドで、/ で始まるスラッシュコマンドではありません。ただし、Ruby、PHP、bun、PostgreSQL、Redis などは check-tools が報告しないので、psql --version のように、そのツール自身のバージョンコマンドの実行を頼みます。なお、VM にシェルで直接入ることはできません。VM 上のコマンドは、すべて Claude に頼んで実行してもらいます。

環境はどこで作り、どこで編集するのか

オンボーディングを終えると、Default という環境ができています。Default のネットワークアクセスは Trusted です。環境変数もセットアップスクリプトも持っていません。つまり、最初のセッションは何も追加されていない VM で動きます。

環境の追加と編集は、claude.ai/code の新規セッション画面で行います。メッセージ入力欄の下の行にある、最初のコントロールが環境セレクターです。

  • 新しい環境を作る: メニューの一番下の New environment を選び、フォームを埋めて Add environment を押します。
  • 既存の環境を編集する: Cloud の下にある環境の行にマウスを乗せ、右側に出る設定アイコンを押します。
  • 実行中のセッションの環境を編集する: 画面上部のセッション名の後ろにあるキャレットを押し、Edit cloud environment を選びます。

ダイアログには、名前、ネットワークアクセス、環境変数、セットアップスクリプトの欄があります。自分で作った環境は自分のアカウント専用です。Team と Enterprise では、Owner が作った共有環境も同じセレクターに並びます。Owner は組織のデフォルト環境も選べます。プロジェクトのスレッドは、プロジェクト設定で指定した環境を使います。スレッドの仕組みは Claude Code のプロジェクトとスレッドの解説 にまとめています。

npm install や apt install が失敗するのはなぜか

まず疑うのはネットワークアクセスです。各環境は、次の 4 つのレベルから 1 つを持ちます。

  • None: セッションのネットワークを通る外向きの通信はありません。
  • Trusted: 許可リストのドメインだけに届きます。パッケージレジストリ、GitHub、クラウド SDK などです。これがデフォルトです。
  • Full: どのドメインにも届きます。
  • Custom: 自分で書いた許可リストです。デフォルトのリストを含めることもできます。

None にすると、npm、PyPI、apt のミラーには届きません。そのため、セットアップスクリプトでもフックでも、パッケージのインストールは失敗します。ここで混乱しやすい点があります。None でもリポジトリの clone や GitHub の操作は動くのです。理由は、GitHub への通信が専用のプロキシを通り、セッションの許可リストを経由しないからです。同じように許可リストを経由しないものが、あと 3 つあります。有効にした MCP（Model Context Protocol）コネクタ、ネットワークシークレットに登録したホスト、そして Claude Code 自身の Anthropic API への通信です。GitHub は動くのに npm install だけ失敗するなら、ネットワークレベルを見てください。

Trusted の許可リストには、registry.npmjs.org、pypi.org、files.pythonhosted.org、archive.ubuntu.com、security.ubuntu.com、github.com、gitlab.com、bitbucket.org、Docker Hub、ghcr.io などが入っています。全体の一覧は公式ドキュメントの Default allowed domains で確認してください。

社内のミラーや独自のレジストリに届かせたいときは Custom を選びます。Allowed domains 欄に、1 行に 1 ドメインずつ書きます。先頭の *. はすべてのサブドメインに一致します。

npm.example.co.jp
*.internal.example.co.jp

ここで一番多い失敗は、Also include default list of common package managers のチェックを外したままにすることです。チェックがないと、書いたドメインだけが許可されます。archive.ubuntu.com も registry.npmjs.org もリストにないので、apt install と公開パッケージの npm install が両方とも失敗します。社内ドメインを足したいだけなら、このチェックを入れてください。

ネットワークアクセスを変えると、既存のセッションにも約 1 分で反映されます。新しいセッションを作る必要はありません。

もう 1 つの原因はパッケージマネージャー側です。Anthropic がホストする環境では、外向きの通信はすべてセキュリティプロキシを通ります。このプロキシと相性の悪いパッケージマネージャーがあり、Bun がその例としてドキュメントに挙がっています。Bun は VM に入っていますが、パッケージの取得には npm や pnpm を使うほうが安全です。

セットアップスクリプトで VM を準備する

セットアップスクリプトは、新しいクラウドセッションの開始時に、Claude Code が起動する前に実行される Bash スクリプトです。root として Ubuntu 24.04 上で動くので、apt install も、ほとんどの言語のパッケージマネージャーも使えます。環境のダイアログの Setup script 欄に書きます。

公式ドキュメントの例は、最初から入っていない ShellCheck を入れるものです。

#!/bin/bash
apt update && apt install -y shellcheck

書くときに守る条件は次のとおりです。

  • 終了コードを 0 にする: スクリプトが 0 以外で終わると、セッションが起動しません。止まっても困らないコマンドには || true を付けます。一時的なダウンロード失敗でセッション全体が止まるのを防ぐためです。
  • 約 5 分以内に終わらせる: 時間がかかると、後で説明するキャッシュが作られません。独立したインストールは & と wait で並列に実行します。1 つで 5 分を超える大きなダウンロードは、SessionStart フックからバックグラウンドで実行する形に移します。
  • ネットワークを許可する: None ではインストールが失敗します。Trusted なら主要なレジストリに届きます。

並列化の例です。wait は引数なしだと、バックグラウンドのジョブが失敗しても 0 を返します。ですから、必須のものは並列にせず、普通に実行して失敗が見えるようにします。

#!/bin/bash
apt update
apt install -y shellcheck &
pip install pre-commit &
wait
exit 0

キャッシュは何を残し、何を残さないか

セットアップスクリプトが約 5 分以内に終わると、Anthropic はファイルシステムのスナップショットを取ります。以後のセッションはこのスナップショットから始まり、セットアップスクリプトは実行されません。インストールしたパッケージ、pull した Docker イメージ、書き込んだファイルは残ります。

残らないのは、動いていたプロセスです。スナップショットはディスクの内容しか保存しないからです。スクリプトで起動したデータベースや docker compose up で立ち上げたサービスは、次のセッションでは止まっています。PostgreSQL と Redis は最初から入っていますが、起動はしていません。セッションごとに Claude に頼むか、後で説明する SessionStart フックで起動します。

キャッシュが作り直されるのは、次の場合です。

  • セットアップスクリプトを変更したとき
  • 許可するネットワークホストを変更したとき
  • キャッシュが期限（約 7 日）を迎えたとき

注意点が 1 つあります。アイドル状態から復帰した VM では、セットアップスクリプトは実行されません。数分操作がないと VM はファイルを保存したまま一時停止し、次のメッセージで同じ VM が再開します。そのため、スクリプトの変更が既存のセッションに届くのは、一時停止中の VM が回収され、作り直されたときだけです。スクリプトを直したのに何も変わらないときは、新しいセッションを始めてください。

セッションの途中で Claude にパッケージを入れてもらうこともできます。ただし、そのインストールは他のセッションには残りません。毎回必要なものは、セットアップスクリプトに書きます。

セットアップスクリプトと SessionStart フックの使い分け

ここが一番大事なところです。2 つは似ていますが、動くタイミングと場所が違います。公式の線引きは単純です。VM そのものの準備（最初から入っていないツールチェーンや CLI）はセットアップスクリプトの仕事です。どこでも動かしたいプロジェクトの準備（npm install など）は SessionStart フックの仕事です。

セットアップスクリプトの性質:

  • claude.ai/code の環境ダイアログで設定します。共有環境は管理画面の Cloud environments ページです。
  • Claude Code の起動前に動きます。キャッシュがあれば実行されません。
  • クラウドセッションだけで動きます。

SessionStart フックの性質:

  • リポジトリの .claude/settings.json などの設定ファイルに書きます。
  • Claude Code の起動後に動きます。再開したセッションも含め、毎回動きます。
  • ローカルとクラウドの両方で動きます。

フックの基本は Claude Code のフックの仕組み で説明しています。ここではクラウド特有の動きだけを扱います。

ローカルで動くフックがクラウドで動かないのはなぜか

原因は、ほぼ次の 2 つのどちらかです。

1 つ目は、フックをユーザー設定の ~/.claude/settings.json に書いていることです。ユーザー設定は手元のマシンにしかありません。クラウドセッションはこのファイルを読みません。.claude/settings.local.json も読みません。Anthropic がホストする環境で動くフックは、リポジトリにあるものと、組織のサーバー管理設定にあるものだけです。クラウドで動かしたいフックは、リポジトリの .claude/settings.json に書いてコミットします。

2 つ目は、セッションに複数のリポジトリを付けていることです。Anthropic がホストする環境では、リポジトリが複数あるセッションは、どのリポジトリの .claude/settings.json からもフックを読みません。この場合、依存関係はセットアップスクリプトで入れるよう、ドキュメントが案内しています。

クラウドだけで動くフックを書く

フックはローカルでも動くので、クラウドだけで実行したい処理は自分で分岐させます。クラウドセッションでは、環境変数 CLAUDE_CODE_REMOTE が自動で true になります。ローカルで true になることはありません。

まず、リポジトリの .claude/settings.json にフックを書きます。matcher の startup は新しいセッション、resume は --resume、--continue、/resume での再開です。

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "startup|resume",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR\"/scripts/install_pkgs.sh"
          }
        ]
      }
    ]
  }
}

$CLAUDE_PROJECT_DIR はリポジトリのルートを指します。そのため、作業ディレクトリがどこでもスクリプトが見つかります。

次に scripts/install_pkgs.sh を作ります。クラウド以外ではすぐ終了し、クラウドでは PostgreSQL を起動して依存関係を入れます。

#!/bin/bash

if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
  exit 0
fi

cd "$CLAUDE_PROJECT_DIR" || exit 0
service postgresql start || true

if [ ! -d node_modules ]; then
  npm install
fi
exit 0

node_modules の有無を確かめているのは、フックが再開のたびに動くからです。アイドルから復帰した VM にはファイルが残っているので、毎回 npm install をやり直すと起動が遅くなるだけです。一方、PostgreSQL の起動は毎回必要です。プロセスはキャッシュにも一時停止にも残らないからです。ただし、ディレクトリの有無だけではロックファイルの変更を検出できません。依存関係を変えたブランチでは、Claude に npm install を頼んでください。

クラウドでフックを使うときの注意:

  • ネットワークが必要: None の環境では、インストールするフックは失敗します。
  • 起動が遅くなる: フックはキャッシュされず、開始と再開のたびに動きます。
  • タイムアウト: command フックは 600 秒で打ち切られます。長くかかるならフックのエントリーに timeout（秒）を付けます。"async": true で動かすフックにはタイムアウトが適用されません。

環境変数には何を書いてよいのか

環境変数は .env 形式で、1 行に KEY=value を 1 つ書きます。値は引用符なしで構いません。対になった引用符で囲んだ場合、引用符は値に含まれません。# を含む値と複数行の値は、必ず引用符で囲みます。引用符がないと # 以降がコメントとして捨てられ、値が途中で切れるからです。

NODE_ENV=development
LOG_LEVEL=debug
WEBHOOK_PATH="/hooks#main"

値を変えても、既存のセッションはすぐには新しい値を使いません。セッションが値を読むのは、作成時と、VM 内で Claude Code が再び起動したとき（アイドルからの復帰、回収後の作り直し）だけだからです。今すぐ試したいときは LOG_LEVEL=trace npm test のようにコマンドの前に付けるよう Claude に頼むか、新しいセッションを始めます。OTEL_* で始まる変数は Claude Code のテレメトリー用なので、Claude が実行するコマンドには渡りません。

一番大事な点は、環境を使う人は誰でも環境変数とセットアップスクリプトを読めることです。ダイアログにもそう書かれています。共有環境なら、組織の全メンバーのセッションが値を読みます。API キーやトークンをここに書くと、その環境を使う全員に見えます。

API キーはネットワークシークレットに置く

ネットワークシークレットは、クラウド環境に保存する API キーやトークンです。Claude はキーを見ずに、その API を呼べます。仕組みはこうです。リクエストが VM を出た後で、Anthropic のエージェントプロキシが、登録したホスト宛てのリクエストにだけキーを付けます。キーそのものは VM の中に入りません。Pro、Max、Team、Enterprise で使えます。

追加の手順:

  1. claude.ai/code で環境の編集ダイアログを開き、Network secrets 欄を探します。
  2. Add secret を選びます。Secret type はデフォルトの Bearer のままにします。
  3. Name と Allowed websites（先頭の *. でサブドメインに一致）を入れます。Custom headers の行は、Authorization と接頭辞 Bearer が入った状態で始まります。

シークレットは 1 つずつ追加します。追加後は編集できず、値を再表示することもできません。ホストや値を変えるときは、削除して追加し直します。シークレットのホストには、ネットワークレベルが None でも届きます。そして、その環境で動くすべてのセッションで、誰が始めたかに関係なく使われます。

便利ですが、シークレットが付かない通信があります。

  • GitHub（専用のプロキシが認証します）
  • api.anthropic.com、registry.npmjs.org、jsr.io、npm.jsr.io、pypi.org、files.pythonhosted.org、index.crates.io、proxy.golang.org
  • セットアップスクリプトからのリクエスト
  • Claude Code 自身のテレメトリー送信

3 つ目が見落としやすい点です。Claude Code がエージェントプロキシに接続するのは起動時で、セットアップスクリプトの後だからです。たとえば、社内のプライベートレジストリのトークンをシークレットにしても、セットアップスクリプトの npm install にはそのトークンが付きません。プロキシが付けられないキーは、環境変数に置くしかありません。その場合は、共有環境ではなく自分専用の環境に置き、権限の小さい読み取り専用トークンを使ってください。キー全般の扱い方は AI エージェントに秘密情報を渡さない方法 で詳しく説明しています。

ネットワークシークレットが使えない場合もあります。セルフホスト環境にはこの機能がありません。組織が顧客管理の暗号鍵を使っている場合も保存できません。また、リクエストは Anthropic のネットワークから出るので、API がインターネットからの接続を受け付けている必要があります。

長いビルドやテストが途中で切れるのはなぜか

クラウド環境は独自のコマンドタイムアウトを持たず、Bash ツールのデフォルトが使われます。Claude はフォアグラウンドのコマンドを標準で 2 分待ち、最大 10 分まで延ばせます。タイムアウトに達したコマンドは、sleep で始まるものを除き、止まらずにバックグラウンドに移り、さらに最大 30 分動きます。ただし、環境変数 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS を 1 にするか、bare モードで起動してバックグラウンドタスクを無効にしている場合は、コマンドはタイムアウトの時点で止まります。

もっと長い待ち時間が必要なら、環境変数に設定します。単位はどちらもミリ秒です。

BASH_DEFAULT_TIMEOUT_MS=600000
BASH_MAX_TIMEOUT_MS=1200000

この例では、標準の待ち時間が 10 分、Claude が頼める上限が 20 分になります。BASH_MAX_TIMEOUT_MS のデフォルトは 600000（10 分）で、実際の上限は 2 つの値の大きいほうです。BASH_DEFAULT_TIMEOUT_MS を 1800000 より大きくすると、バックグラウンドの制限時間も延びます。このバックグラウンドの制限時間の動作には Claude Code v2.1.285 以降が必要です。

CLI から使う環境を選ぶ：/remote-env

ターミナルで /remote-env を実行すると、既存の環境の一覧が出ます。選んだ環境が、claude --cloud など CLI から作るクラウドセッションのデフォルトになります。選択はユーザー設定の remote.defaultEnvironmentId に保存されます。そのため、どのプロジェクトでも効きます。ただし、リポジトリのプロジェクト設定など、優先度の高い設定に同じキーがあれば、そちらが勝ちます。

/remote-env はデフォルトを決めるだけです。セッションは始めませんし、環境の追加や編集もできません。編集は claude.ai/code の環境セレクターで行います。何も選んでいない場合、CLI は一覧に Anthropic がホストする環境があればそれを使います。

claude --cloud が手元の変更を見ないのはなぜか

claude --cloud は、手元の作業ツリーではなく、カレントディレクトリの GitHub リモートを現在のブランチで clone します。push していないコミットは、クラウドからは見えません。先に push します。

git push
claude --cloud "テストを実行して、失敗したものを直して"

リポジトリに git のリモートがない場合や、github.com 上で Claude GitHub App が入っていない場合は、Claude Code が手元のリポジトリをバンドルにしてアップロードします。バンドルの条件:

  • 1 つ以上のコミットがある git リポジトリであること。
  • 100 MB 未満であること。超えると現在のブランチだけ、次に作業ツリーのスナップショット 1 つ、と縮め、それでも大きければ失敗します。
  • 追跡されていないファイルは入りません。見せたいファイルは git add します。
  • macOS、Linux、WSL では git 2.31 以降が必要です。
  • macOS、Linux、WSL では、.env、*.tfvars、id_rsa、*.pem のような認証情報らしいファイルの未コミットの変更は入りません。

GitLab や Bitbucket のリポジトリは使えるか

リポジトリの clone とプルリクエストの作成には GitHub が必要です。GitHub Enterprise Server は Team と Enterprise で使えます。GitLab、Bitbucket などのリポジトリは、CCR_FORCE_BUNDLE=1 を付けるとバンドルとして送れます。

CCR_FORCE_BUNDLE=1 claude --cloud "テストを実行して、失敗したものを直して"

ただし、セッションはその GitLab や Bitbucket のリモートに push できません。結果は、セッションの差分を見て手元に取り込む前提で使います。

GitHub のリポジトリでも制限があります。GitHub への通信は専用プロキシを通り、プロキシは GraphQL へのリクエストを 403 で拒否します。メッセージは GitHub GraphQL is not available from Claude Code sessions で始まります。gh pr や gh issue は GraphQL を使うので失敗します。GH_TOKEN を設定しても同じです。代わりに gh api repos/{owner}/{repo}/... の REST API を使います。

日本の開発者が最初のセッションで確かめること

日本向けのプロジェクトでは、タイムゾーンとロケールでテストが落ちることがあります。VM の既定値は、ここでは書きません。実際のセッションで確かめるのが一番確実だからです。新しいセッションで、Claude に次のコマンドの実行を頼んでください。

date
echo "TZ=$TZ"
locale
locale -a

date の結果が JST でなく、テストが日本時間を前提にしているなら、環境変数に TZ=Asia/Tokyo を足します。その後、新しいセッションで date が JST を表示するか確認します。表示が変わらないなら、タイムゾーンのデータがない可能性があります。セットアップスクリプトに apt install -y tzdata を足してください。

locale -a の一覧に ja_JP.utf8 がなく、テストが日本語ロケールを必要とするなら、セットアップスクリプトでロケールを作ります。

#!/bin/bash
apt update && apt install -y locales tzdata
locale-gen ja_JP.UTF-8

そのうえで、環境の Environment variables 欄に LANG=ja_JP.UTF-8 を書きます。セットアップスクリプトの仕事はロケールの生成だけです。LANG はスクリプトではなく、セッションが読む環境変数の欄に置きます。

日本語のファイル名は、git status で "\346\227\245..." のような 8 進数のエスケープで表示されます。これはロケールの問題ではありません。git の core.quotePath の既定値が true で、0x80 より大きいバイトをエスケープするからです。ログを読みやすくしたいなら、Claude に git config core.quotePath false の実行を頼みます。

セルフホスト環境：社内サービスに届かせたいチームへ

社内のデータベースや非公開のレジストリにセッションを届かせたいなら、セルフホスト環境があります。セッションを自社のネットワーク内のランナーで実行する仕組みです。現在は Team と Enterprise 向けのパブリックベータで、初期状態では無効です。Owner が管理画面の Cloud environments ページで Allow self-hosted environments を有効にする必要があります。リポジトリのチェックアウトやビルド成果物は自社のマシンに残りますが、プロンプト、応答、ツールの結果を含む会話は api.anthropic.com に送られます。導入する場合は、公式ドキュメントの self-hosted-environments ページから始めてください。

FAQ

Claude Code のクラウドセッションで npm install が失敗するのはなぜですか？

多くの場合、環境のネットワークアクセスが原因です。None ではパッケージレジストリに届きません。Custom で Also include default list of common package managers のチェックを外していると、書いたドメイン以外はすべて拒否されます。そのため registry.npmjs.org にも届きません。GitHub は専用プロキシを通るので、clone は成功しても npm install だけ失敗することがあります。Trusted に戻すか、Custom でチェックを入れてください。変更は既存のセッションにも約 1 分で反映されます。

ローカルで動く SessionStart フックが、クラウドで動かないのはなぜですか？

ユーザー設定の ~/.claude/settings.json に書いたフックは、クラウドセッションに届きません。ユーザー設定は手元のマシンにしかないからです。リポジトリの .claude/settings.json に書いてコミットしてください。また、Anthropic がホストする環境でリポジトリを複数付けたセッションは、どのリポジトリの .claude/settings.json からもフックを読みません。その場合はセットアップスクリプトを使います。

クラウド環境で API キーはどこに置けばよいですか？

ネットワークシークレットに置きます。Anthropic のエージェントプロキシが、VM を出た後のリクエストにキーを付けるので、キーは VM に入りません。環境変数に書くと、その環境を使う全員が値を読めます。ただし、セットアップスクリプトからのリクエストや、npm や PyPI などの公開レジストリ宛ての通信にはシークレットが付きません。そうしたキーは自分専用の環境の環境変数に置き、権限を絞ったトークンを使います。

セットアップスクリプトを変えたのに、反映されないのはなぜですか？

アイドルから復帰した VM では、セットアップスクリプトが実行されないからです。スクリプトを変えるとキャッシュは作り直されますが、既存のセッションに届くのは、VM が回収されて作り直されたときだけです。新しいセッションを始めれば、新しいスクリプトで準備された VM が使われます。スクリプトが約 5 分を超えるとキャッシュ自体が作られないので、& と wait で並列化してください。

GitLab のリポジトリでクラウドセッションを使えますか？

使えますが、制限があります。CCR_FORCE_BUNDLE=1 を付けて claude --cloud を実行すると、手元のリポジトリをバンドルにしてアップロードできます。ただし、セッションは GitLab のリモートに push できません。バンドルは 100 MB 未満である必要があり、追跡されていないファイルは含まれません。プルリクエストの作成まで任せたいなら、GitHub のリポジトリが必要です。

#claude-code#cloud-sessions#setup-scripts#network-access#environment-variables