Claude Code活用

Claude Codeの`--worktree`フラグ(git worktreeベースの並行セッション隔離)を、使い捨てのGitリポジトリで実機検証した記事。`.worktreeinclude`に書いても対象ファイルを`.gitignore`にも入れないと無言でコピーされない点、非対話`-p`セッションで作ったworktreeはロックが残ったままで`unlock`しないと`remove`が失敗する点の2つを、実際のコマンド出力とファイルサイズ確認付きで実証した。隔離の強制(worktree外への書き込みブロック)も`--permission-mode acceptEdits`下で実際にブロックされることを確認。さらに公式Worktreesドキュメントページ本文には出てこない`--tmux`フラグの存在をCHANGELOG.mdとCLIヘルプから裏取りした。関連するGitHub Issue #79424・#83098・#79888・#84787(いずれも状態を明記)も紹介。

Claude Code v2.1.265のCHANGELOG.mdが明記する「非対話stream-json入力でcdがターンをまたいで持続するようになった」修正を、このブログの無人claude -pパイプラインと同じstream-json多段手法で実機検証した記事。手元のv2.1.258とnpm --prefixで隔離導入したv2.1.265の両方で、2ターン目のpwdが1ターン目でcdした先ではなく元の起動ディレクトリに戻る同一の挙動を実測し、実費・所要時間つきで記録した。関連するGitHub Issue #76708・#83636(いずれもopen)も出典を分けて紹介し、原因の断定は避けている。

Claude Code v2.1.259(GitHub CHANGELOG.md記載)はpermissions.denyのRead()ルールをBashコマンドの引数(オプション値・cd複合コマンド・grep -r/cp -r)にも適用する修正を入れたが、npm run buildのような正当なコマンドまでbypassPermissionsモードで拒否してしまい、翌日のv2.1.260でこの変更ごと撤回された。npm install --prefixでv2.1.258/259/260を隔離環境に導入し、Read(./**/build/**)ルール下でのnpm run build実行と、Read(./artifacts/**)ルール下でのgrep -r BUILD_IDによる中身の読み出しを3バージョンで対照実験した。npm run buildの誤ブロックはv2.1.259だけで発生し260で解消される一方、grep -rによるdenyルールのすり抜け(実際にBUILD_ID=99881という値が漏れる)はv2.1.258とv2.1.260の両方で再現し、v2.1.259だけがブロックしていた。denyルール単体に頼らずPreToolUseフックで再帰コマンドを機械的にブロックする代替策も実機で確認した。GitHub Issue #91690(open、Windows/VS Code拡張ではv2.1.259でも修正が再現しないという報告)を出典明記の上でプラットフォーム依存の可能性として紹介し、cp -rについては宛先パス名にモデル自身が安全上の疑義を持ち検証できなかった限界も明記した。GitHubリリース起点(a)で選定、YouTube不使用。

Claude Code v2.1.260(2026-09-03公開、GitHub CHANGELOG.md記載)は/diffパネル・/reload-plugins・/advisorのテキスト版の3つを「ヘッドセッションへの追加」として記載しているが、公式docsサイトのWeek次ダイジェスト(What's new)は2026-09-06時点でまだWeek 34(v2.1.234〜v2.1.239)止まりでこの週の内容が掲載されておらず、CHANGELOG.mdを優先する根拠が具体的に確認できた。手元の旧バージョン(v2.1.258)で3コマンドをclaude -pから叩くと、いずれも total_cost_usd=0・duration_ms=20前後で「/xxx isn't available in this environment.」という、存在しないコマンド名を打った場合の「Unknown command: ...」とは異なる、コマンド自体は認識された上での穏やかな拒否メッセージを返すことを確認した。npm install --prefixでグローバル環境を汚さない隔離ディレクトリにv2.1.260を導入して同じコマンドを叩いたところ、/advisorは実際の設定状態(Advisor: off / Usage: ...)を、/reload-pluginsは実際のプラグイン・スキル数(Reloaded: 18 plugins・189 skills・8 agents・9 hooks)を返すようになった一方、/diffだけはv2.1.260でも文言が一切変わらず「isn't available in this environment.」のままだった。フルスクリーンモードの会話横に開くパネルという/diffの性質上、バージョンを上げても無人実行では原理的に表示できないためと考えられる。さらに--advisor sonnet --model haikuで実際に課金を伴う呼び出しを行い(実費約3.6セント)、単純な計算タスクではmodelUsageにアドバイザーモデルが一切含まれず、公式ドキュメントの『Claudeが必要と判断した時だけアドバイザーを呼ぶ』という説明を実測で裏付けた。GitHub Issue #87514(open、/reload-pluginsのコンテキスト肥大化)・#84320(open、キュー入力の順序バグ)・#92101(open、/diffパネルのサンドボックス誤表示)を出典明記の上で無人パイプライン運用時の注意点として整理した。GitHubリリース起点(a)で選定、YouTube不使用。

Claude Code v2.1.261(2026-09-04公開、GitHub CHANGELOG.md記載)は/skill-doctor(未使用スキルとそのコンテキストコストを表示)、bashOutputMaxChars/taskOutputMaxChars(Bash・バックグラウンドタスク出力のインライン上限を最大128Kまで引き上げ)、--append-subagent-system-prompt-file(サブエージェントのシステムプロンプトをファイルから読む)の3機能を追加した。いずれも公式docsサイト(settings-reference/cli-reference)にはまだ掲載がなく、CHANGELOG.mdのみが一次情報の段階だったため、そのまま裏取りせず自分の手元バージョン(v2.1.258、v2.1.261の3つ前)で実際に3つを叩いた。--append-subagent-system-prompt-fileは`error: unknown option`で即エラー(2026-08-27/08-30と同じCLIフラグの壊れ方)、bashOutputMaxCharsは--settingsで100000を指定してもエラーなく無視され、60,000文字の意図的な大量出力が従来どおり58.6KBでファイル保存に切り替わることをstream-json出力の実測で確認した(同じく既知の設定ファイル無言無視パターン)。ところが/skill-doctorはv2.1.258でも完全に動作し、total_cost_usd=0・duration_ms=373というAPIコールを伴わないローカル実行であることを実測した。これはCHANGELOG.md v2.1.261自身が挙げる別の修正項目「新しいバージョン向けの機能フラグが同じマシン上の古いバージョンにまで稀に適用される不具合」と符合する可能性があるが、原因をソースコードで確認したわけではないため断定はしていない。GitHub Issue #82169(open、2026-07-29作成、『セッションを開始せずスキル一覧を見たい』という要望)を出典を分けて紹介し、/skill-doctorは要望に近いがセッションID自体は発行されるため文字通り無セッションではない点も明記した。3つの検証結果を1本の版差監査スクリプトと、このブログ自身の自動投稿パイプラインへの組み込み方針(健康チェックへの/skill-doctor追加、設定キー導入前の対照実験、CLIフラグ導入前のバージョン分岐)にまとめた。GitHubリリース起点(a)で選定、YouTube不使用。

Claude Code v2.1.259(2026-09-02公開)のGitHub CHANGELOG.mdは『--permission-prompts noneを無人ヘッドレスホスト向けに追加。本来確認を求めるはずの操作は、稼働中の権限モード(autoモードを含む)が判断を続けたまま自動的に拒否される』と明記している。手元のバージョンは1つ前のv2.1.258で、実際に--permission-prompts noneを渡すとerror: unknown optionで即エラーになることを確認した。フラグ自体は試せないため、代わりに『このフラグが無い今、無人のclaude -p実行中に確認が必要な操作に出会うとどうなるか』を--permission-mode default(Manual)とautoの両方で実機検証した。使い捨ての作業ディレクトリで、Bashを--allowedToolsに含めない状態から読み取り系コマンド(catで一意なマーカー文字列を読む)と書き込み系コマンド(echoでのリダイレクト)を試したところ、Manualモードでは読み取りは無確認で通り、書き込みはpermission_denialsに記録された上でハングせず拒否された。autoモードでは同じ書き込みがclassifierによって確認なしに承認された。公式ドキュメント(/docs/en/permission-modes)の『Sessions that can't prompt』の記述(autoモードのフォールバックとして書かれたもの)と自分の実験結果を出典を分けて突き合わせ、Manualモードへの一般化は自分の推測であることを明記した。加えて自分のマシンのユーザー単位設定がbypassPermissions(全許可)であるため、このブログ自身の自動投稿パイプラインには今回の検証結果がそのまま当てはまらないことも確認し、フラグの追加を待つより先に見直すべき設定として指摘した。書き込みブロック時のエラーメッセージがmacOSの/tmpシンボリックリンクにより自己矛盾して見えた実測結果を、症状のクラスが近いGitHub Issue #77972(open、再現条件は異なる)と出典を分けて紹介し、クラウド版Routinesの権限確認スタール問題(Issue #83166、open)とCLIの-pの挙動を混同しないよう明記した。

Claude Code v2.1.257のCHANGELOG.mdは『.claude/settings.jsonやsettings.local.jsonのdefaultMode: bypassPermissionsは、autoと同様に無視されるようになった。ユーザー設定/管理者設定に置くか--permission-modeを使え』と明記している。この変更は告知が薄く、GitHubには2026-09-01〜02だけで複数の『バグではないか』という報告(Issue #91296など、いずれもopen)が立っていた。使い捨てのGitリポジトリで、plan/auto/bypassPermissionsを組み合わせた対照実験を行い、(1)プロジェクト設定ファイル自体は今も正常に読み込まれること(2)--settingsフラグがユーザー単位の設定より強いこと(3)--permission-modeフラグがどんな設定階層より最終的に勝つこと、を実際のJSON出力付きで確認した。加えて同バージョンで追加されたpermissions.blockReadsOutsideWorkingDirectories設定が、作業ディレクトリ外の読み取りを実際にブロックする様子もpermission_denialsフィールドで確認した。自分の環境のユーザー単位設定がすでにbypassPermissionsだったため『プロジェクト設定のbypassPermissions自体がどうフォールバックするか』は交絡により再現確認できず、その限界は本文で明記している。

Claude Codeの実験的機能agent teams(CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1)を、非対話モード(claude -p)で実際に有効化して検証した。公式ドキュメントは『-pモードではチームメイトを起動せず、通常のサブエージェントとして動作する』と明記しているが、これを鵜呑みにせず実際にclaude -pでハイクを書かせる2種類のテスト(環境変数あり/なし)を実行し、どちらも~/.claude/teams/が作られず、subagent_stats.by_typeがgeneral-purposeのままであることを確認した。応答テキスト自体は『teammates』という言葉を使い続けるため、出力を読むだけでは通常のサブエージェントとの違いに気づきにくいという実務上のつまずき所も指摘した。GitHub Issue #90453(open)にある『/rewindがin-processチームメイトを実は保持する』というドキュメントとの食い違いの報告も、他ユーザーの報告として出典を明記して紹介している。