Background full checkout failed: other が出て worktree セッションが始まらないときこの症状は、Claude Code の worktree を使って新しいローカルセッションを起動した直後に、ブランチ切り替えの段階で止まるものです。手元の issue 報告では、ダイアログに
ブランチを切り替えられませんでした (Could not switch branch)
Background full checkout failed: other
と出て、そのままセッションが始まりません。#86276 では、worktree 自体は片付く一方で、セッション用に作られたブランチ claude/<name>-<hash> が base repo 側に残ると報告されています。#86276
似た見え方をする別件もあります。#74526 では、git submodule の中で worktree セッションや background-task chip を起動すると同じ Background full checkout failed: other に落ち、freshly created worktree 内の git コマンドが死ぬと報告されています。#74526
この2件から、少なくとも「worktree を作ったあとに full checkout へ進む段階で失敗している」ことまでは読めます。ただし、原因の中身はケースで違います。#86276 は空の HEAD tree を持つ新規リポジトリで起き、#74526 は absorbed submodule と extensions.worktreeConfig=true が絡む構成で再現しています。どちらも同じ文言に見えて、壊れている git 状態は同じではありません。#86276 #74526
自分のケースがこの症状に当たるかを見るなら、まず次の2点を比べるのが早いです。新規に作った worktree セッションが「ブランチを切り替えられませんでした」と出て止まるか。そして、対象のリポジトリが空コミットだけの新規 repo なのか、あるいは submodule の中なのか。前者は #86276、後者は #74526 にかなり近いです。#86276 #74526
なお、筆者環境で確認できたのは実行環境の情報だけです。Node.js は次のとおりでした。
$ node --version
v16.15.0
OS と Python は次の出力でした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-01T08:56:34+09:00
この症状について、今回の情報だけでは恒久的な回避策までは断定できません。少なくとも issue 上で確認できるのは、「同じエラー文字列でも、空 tree の新規 repo と submodule では別の壊れ方をしている」という点です。再現条件を切り分けたうえで、該当 issue の続報を追うのが安全です。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-01T08:56:34+09:00