Claude Code Desktopの並列セッション機能(Git分離)を使う

Claude Code Desktopは、サイドバーから複数のセッションを同時に開いて並行作業できます。Gitリポジトリでは、ブランチ名の隣にあるworktreeオプションを選ぶと、そのセッションだけの独立したコピーで作業できます。コミットするまで、変更はほかのセッションに届きません。

ここで注意したいのは、分離が自動ではなくオプションだという点です。選ばなければ、セッションは通常のチェックアウトで動きます。CLIの--worktreeフラグに相当する操作が、Desktopではこのオプションにあたります。

Claude Code Desktopの並列セッションとは

セッションはそれぞれ独立した会話で、独自のチャット履歴とプロジェクトフォルダーを持ちます。

worktreeを選んだセッションは、Gitワークツリーでプロジェクトの独立したコピーを持ちます。同時に複数のタスクを走らせても、ファイルの取り合いや意図しない上書きが起きにくくなります。この並列管理とビジュアルなレビューが、DesktopがCLIと使い分けられる大きな理由です。

新しいセッションを開いて切り替える

2つのセッションを同時に画面へ出したいときは、macOSならCmd、WindowsならCtrlを押しながらサイドバーのセッションをクリックします。開いているペインの隣に、選んだセッションが第2ペインとして表示されます。

分割中に別のセッションをクリックすると、フォーカスがあるペインの中身が置き換わります。分割を閉じて1セッション表示に戻すには、Cmd+\(WindowsはCtrl+\)を押します。

worktreeを選ぶと何が起きるか

ワークツリーは既定で<プロジェクトルート>/.claude/worktrees/以下に作られます。保存先を変えたい場合は、Settings → Claude Codeの「Worktree location」でカスタムディレクトリーを指定します。同じ画面でブランチ名に付けるプレフィックスも決められるので、Claude発のブランチを一覧で見分けやすくなります。

新しいワークツリーは、既定ではリポジトリのデフォルトブランチから分岐します。作業中のブランチの先頭から分けたいときは、設定のworktree.baseRefを"head"にします。ブランチ名は指定できず、"fresh"(既定)と"head"の2値だけです。

デフォルトブランチを基点にするとき、Claude Codeはorigin/HEADを最新に保とうとします。前回のフェッチから24時間以上たっていれば、デフォルトブランチを最大5秒でフェッチします。失敗したらローカルにある参照を使います。リモートが未設定のときや、origin/HEADがローカルに無く取得もできないときは、現在のローカルHEADが基点になります。パスワードやパスフレーズを求められる場合も、取得の失敗として扱われます。

ワークツリーは新しいチェックアウトなので、node_modulesのような依存は入っていません。Claudeに依存のインストールを頼むか、.claude/worktrees/の下で自分でセットアップします。

設定にはworktree.symlinkDirectoriesもあり、--worktreeやEnterWorktreeツールで作るワークツリーでは、メインのリポジトリから大きなディレクトリーをシンボリックリンクで共有できます。既定では何もリンクされず、node_modulesのようなディレクトリー名を配列で指定します。

.envのようなgit管理外のファイルを新しいワークツリーに含めたい場合は、プロジェクトルートに.worktreeincludeファイルを作ります。書式は.gitignoreと同じです。ただし、パターンに一致し、かつgitignoreされているファイルだけがコピーされます。追跡済みのファイルが重複してコピーされることはありません。

.env
.env.local
config/secrets.json

終了したセッションを片付ける

タスクが終わったセッションは、サイドバーでカーソルを合わせてアーカイブアイコンをクリックすると、ワークツリーごと片付けられます。PRのマージやクローズをきっかけに自動で片付けたいなら、Settings → Claude CodeのAuto-archive after PR merge or closeをオンにします。対象は、実行が終わっているローカルセッションだけです。

PRを開いた後のCI監視や自動アーカイブの詳しい挙動は、Claude Code DesktopのPR監視機能の使い方にまとめています。ただし、アーカイブしたはずのワークツリーが実際には削除されず、次のセッションに再利用されるという報告もあります。詳しくはClaude Codeのworktreeが再利用されるバグを見てください。

アーカイブでも消えないワークツリーは、手元からgit worktree removeで外せます。未コミットの変更や追跡されていないファイルがあるときは--forceを付けます。ロックされていて拒否された場合は、先にgit worktree unlockを実行します。

Claudeがサブエージェントやバックグラウンドセッション用に作ったワークツリーは、定期的な掃除で消えます。対象はcleanupPeriodDaysの設定より古いものです。実行中のワークツリーにはロックが掛かるため、掃除は手を出しません。サブエージェントのワークツリーも、--worktreeと同じ基点ブランチから分岐します。

ほかのセッションの様子をClaudeに聞く

見ていないセッションでタスクが終わると、DesktopはOS通知を送ります。サイドバーのセッション一覧は、ステータス・プロジェクト・環境で絞り込めて、プロジェクトごとにグループ化もできます。セッション名は、ツールバーのタイトルをクリックして変更します。

Claudeに「認証まわりを触ったセッションはどれか」と尋ねると、ほかのセッションの状況を確認してくれます。「決済のセッションにスキーマが変わったと伝えて」と頼めば、メッセージも送ります。セッションの名前変更やアーカイブも、頼めばClaudeがやってくれます。

この経路でClaudeが見えるのは、Desktopアプリ自身が動かしているローカル・SSH・WSLのセッションだけです。クラウドセッションや、ターミナルのCLI、VS Code拡張で始めたセッションは、同じプロジェクトのワークツリーでも見えません。ターミナルのワークツリーが9つ開いていてDesktopのセッションが2つなら、答えは「ほかにもう1つ」になります。既定で見えるのは直近でアクティブな20セッションで、アーカイブ済みは頼まない限り除外されます。

受信側が作業中なら、メッセージは保留されて、今の作業が終わってから読まれます。受信したセッションには送信元のセッション名付きのカードが出ます。アーカイブ済みのセッションには送れず、失敗はClaudeが知らせます。CLIも含めたセッション間の連携は、Claude Code @メンションでセッション間の連携を制御するで扱っています。Windowsでメッセージ送信後に応答なしになる不具合は、この記事にあります。

現在のタスクの範囲外で直すべき点にClaudeが気づくと、チャットにタスクチップとして提案することがあります。チップをクリックすると、専用のワークツリーを持つ新しいセッションが始まり、元のセッションは中断されません。

CLIの--worktreeフラグと何が違うか

手元のClaude Code v2.1.286でclaude --helpを実行すると、worktree関連のフラグは次の2つでした。

claude --help

  --tmux                                Create a tmux session for the worktree
                                        (requires --worktree). Uses iTerm2
                                        native panes when available; use
                                        --tmux=classic for traditional tmux.
  -w, --worktree [name]                 Create a new git worktree for this
                                        session (optionally specify a name)

--worktree(短縮形-w)の[name]は省略でき、名前を付けるとワークツリーの名前になります。--tmuxは--worktreeとセットで使い、ワークツリー用のtmuxセッションを作ります。

--worktreeには、#<number>形式のPR番号や、PR・GitLabのMRのURLも渡せます。その場合はoriginから該当のPRまたはMRを取得し、それを基点にワークツリーを作ります。

DesktopにはCLIの--printやAgent SDKに当たる機能がありません。単体のワークツリー運用との違いは、Claude Code Worktree実践ガイドで掘り下げています。

worktreeセッションの権限ルールは本体に書かれる

ワークツリーのセッションでBashコマンドに「Yes, and don't ask again」を選ぶと、そのルールはメインのチェックアウトの.claude/settings.local.jsonに保存されます。ほかのワークツリーにも効きますし、そのワークツリーを消した後にも残ります。ただしWindowsと、リポジトリルートを使わない場合は、ルールがそのワークツリー内に残ります。v2.1.211より前のClaude Codeでも同様で、承認はほかのワークツリーに効かず、ワークツリーを消すと失われました。

一方で、.claude/skillsがgitignoreされていてワークツリー側にそのディレクトリがない場合は、メインのチェックアウトにあるプロジェクトのスキルが読み込まれます。ワークツリー自身に.claude/skillsがあれば、読まれるのはそちらのコピーだけです。

よくある落とし穴

• ワークツリーの場所を勘違いする: 既定は.claude/worktrees/以下で、プロジェクト本体のディレクトリーとは別の場所です。「変更が見当たらない」と感じたら、まずこのパスを確認します
• .claude/worktrees/が未追跡ファイルとして出る: メインのチェックアウトの.gitignoreにこのパスを足しておくと、ワークツリーの中身がgit statusに出なくなります
• .envが新しいセッションに引き継がれない: .worktreeincludeに書いたうえで、そのファイルがgitignoreされている必要があります。環境変数ファイルに依存するプロジェクトでは、先に用意しておきます
• クラウドセッションが作ったブランチがローカルに見当たらない: クラウドで作られたブランチは、ローカルには自動では存在しません。セッションツールバーのブランチ名をクリックしてコピーし、手元に取り込みます

git fetch origin <ブランチ名>
git checkout <ブランチ名>

まとめ

並列セッションの安全性は、worktreeを選んだかどうかで決まります。同じファイルを触る作業を並走させるなら、選んでから始めるのが前提です。