#worktree

この症状は、Claude Code の worktree を使って新しいローカルセッションを起動した直後に、ブランチ切り替えの段階で止まるものです。手元の issue 報告では、ダイアログに > ブランチを切り替えられませんでした (Could not switch branch) > `Background full checkout failed: other` と出て、そのままセッションが始まりません。#86276 では、worktree 自体は片付く一方で、セッション用に作られたブランチ `claude/<name>-<hash>` が base repo 側に残ると報告されています。[#86276](https://github.com/anthropics/claude-code/issues/86276) 似た見え方をする別件もあります。#74526 では、git submodule の中で worktree セッションや background-task chip を起動すると同じ `Background full checkout failed: other` に落ち、

最初に切り分けたいのは、「本当に WorktreeRemove hook が失敗したのか」と「削除経路の都合でそう見えているだけか」です。今回の issue 群では、その2通りが混ざっています。 ひとつは [#82097](https://github.com/anthropics/claude-code/issues/82097) です。ここでは、`claude agents` の agent 削除で `WorktreeRemove hook failed` が出るものの、報告者の言葉では `~/.claude/hooks/worktree-remove.sh` はどの経路でも `0` を返しており、hook が直接壊れているわけではありません。報告では、`WorktreeCreate` で作られた worktree のセッション記録に `hookBased: true` が入り、`originalHeadCommit` がないため、CLI 側が worktree 状態を検証できず削除を拒んでいる、という説明になっています。つまり、見えているエラー文と実際の原因がずれている可能性があ

この記事を読んでまず思ったのは、AI coding agent の話がもう「どのモデルが賢いか」ではなく、「どこで走らせるか」の話に移っているんだな、ということだった。 Anthropic が git worktree を agent ごとに切れと言う。でも現実には、コードだけ別れても、runtime や staging 環境が共有のままだと、そこで詰まる。ここがかなり生々しい。 たしかに、agent がそれぞれ好き勝手にコードを触るなら、検証用の実行環境もそれに合わせて分離したくなる。でないと、A の agent が作った変更を B が壊したり、shared staging が「最後に動かした人のもの」になってしまう。開発体験としてはかなりつらいはずだ。 この記事が面白いのは、AI エージェントの問題を「生成物の品質」ではなく「実行の分離不足」として見ているところだと思う。コード生成は派手だけど、ほんとうにボトルネックになるのはそこではない、という視点がある。 もう一つ引っかかったのは、ここで言う「full-stack branching」が、単なるブランチ運用の話ではなく、runt