CLAUDE_CODE_THRIFTY_SONICとは — Bash編集で/rewindが効かない問題の止め方

CLAUDE_CODE_THRIFTY_SONICは、Auto ModeがファイルをBashのsedやheredocで編集する挙動を止めるための、公式ドキュメントに載っていない環境変数です。GitHub issue #88041と#87575によると、この挙動下で行われた編集はチェックポイントに記録されず、/rewindが成功と表示されながら実際には何も戻さないケースが報告されています。

Auto ModeがファイルをBash経由で書き換える仕組み

Auto Modeが有効なセッションでは、条件がそろうとシステムプロンプトに次の指示が追加で挿入されます。issueのコメントで複数人が独立に確認した文面です。

Do your work through the Bash tool wherever it can accomplish the job: read files with cat, head, or sed -n, search with grep and find, and make file changes with sed, heredocs, or short scripts, rather than using the dedicated Read, Edit, or Write tools. Fall back to a dedicated tool only when Bash genuinely cannot do the job.

この指示自体はsedやgrepを使うなという普段のBashツール説明を上書きするもので、Claude Codeのauto modeが公式に説明している分類器(classifier)によるアクション審査とは別物です。分類器は危険な操作を止める仕組みですが、この指示はそもそもどのツールで編集するかを誘導するだけなので、分類器が承認した後の話として動きます。

挿入を制御しているのはbashFirstという内部フラグです。セッションにBashと、EditまたはWriteのどちらかがあり、かつautoモードかbypassPermissionsモードのときに条件を満たします。

フラグは環境変数CLAUDE_CODE_THRIFTY_SONICで上書きできます。0・false・no・offでオフ、1・true・yes・onでオンです。未設定、またはこれ以外の値なら、セッションごとの内部割り当てに従います。割り当ては"forced"(常にオン)・"none"(常にオフ)・"cohort"(A/Bテスト)の3状態です。これは内部の値で、環境変数にnoneやforcedと書いても意味を持ちません。

したがって、何も設定していないこと自体が「オフ」を意味しません。0やfalseを明示すれば、割り当てより先に判定が返り、確実にオフになります(値ごとの検証状況は後述の「止める方法」で扱います)。

どのモデル・権限モードの組み合わせで起こるか

この指示が付くバージョンは、issueのコメント群が独立に計測しています。バイナリ内の文字列はv2.1.219には存在せず、v2.1.234で確認されました。以後v2.1.241・v2.1.247・v2.1.257・v2.1.263でもゲートの構造は変わらず残り続けています。

auto modeは組み込みの既定モードです。macOS・Linux・WSLはv2.1.228以降、ネイティブWindowsはv2.1.233以降で、利用条件を満たせば、権限モードを何も設定していなくてもauto modeで始まります。

v2.1.228〜v2.1.282ではPro・Max・Teamプランだけが対象でした。v2.1.283以降は、対話式ターミナルとVS Codeのセッションが全プランで対象です。claude -pとAgent SDKの既定はManualです。設定した覚えがなくても、この記事の条件に入っている可能性があります。

付くかどうかはモデルと権限モードの組み合わせにも左右されます。v2.1.247で実際にセッションへ送られるプロンプトを傍受した計測では、次の結果が出ています。

v2.1.285のclaude --helpでは、--permission-modeの選択肢にacceptEdits・auto・bypassPermissions・manual・dontAsk・planが並びます。設定値のdefaultとmanualは同じモードを指します。

Opus 5をautoまたはbypassPermissionsで使うと、rm -rfやgit resetの前にgit statusを確認するよう促す安全指示ごと欠落し、その代わりにBash優先の指示だけが残ります。表のSonnet 5のautoでは、同じ安全指示が残っています。安全側の指示と危険側への誘導が同じ分岐で入れ替わっている点は、この計測の中でも懸念点として指摘されています。

Fable 5.1では条件がさらに広がりました。v2.1.257以降、Fable 5.1に割り当てられる内部バンドルは、Bash優先フラグを"forced"にする条件の一つになっています。Auto modeかbypassPermissionsで、BashとEdit・Writeがあり、環境変数が未設定なら、cohort判定を待たずに指示が付きます。Opus 5向けのバンドルも、別の内部ゲート次第で"forced"の経路に入ると報告されており、Fable 5.1だけが原因ではありません。

回避策として--permission-mode bypassPermissionsを明示すれば安全という報告がv2.1.238ではありましたが、v2.1.251ではこの条件が反転し、同じフラグがむしろ指示を発動させる側に変わっています。バージョン間でトリガーの向きが入れ替わるため、特定バージョンで確認した回避策を別バージョンでそのまま信用しない方が安全です。

Bash経由の編集で失われる保護機能

/rewindが効かなくなる点は後述するとして、issueのコメント群が挙げている副作用はそれだけではありません。PreToolUse・PostToolUseフックのうち、EditやWrite限定のマッチャーを指定したものは一切発火しません。ある報告では、lintと型チェックとテストと重複検出をまとめたプリコミットのバッテリーがEdit|Writeのフックから変更ファイル一覧を受け取る設計になっており、Bash経由の編集はこのバッテリーに「採点対象ファイルゼロ」として素通りしていました。バッテリー自体はエラーなく終了するため、対象ゼロと全件合格の区別がつかなかったと報告されています。

同じ理屈で、EditやWriteのパスを対象にしたallow・denyの権限ルールも素通りします。さらにsedが対象箇所にマッチしなければコマンドは正常終了(exit 0)するため、実際には何も変わっていないのに編集は成功したとClaudeが報告するケースもあります。

サブディレクトリのCLAUDE.mdが読み込まれる条件も同じ理屈で崩れます。読み込みはパスベースで、Read・Edit・Writeがそのパスに触れたときだけ発火し、Bashでcatしただけでは登録されません。ネストした.claude/rulesについても同様の報告があり、Bash経由の編集が続くセッションではサブディレクトリのルールが静かに無視されます。27通りのアクセス方法とパス限定ルールへの影響を検証したデータはauto modeでCLAUDE.mdとhooksが無視される問題と回避策にまとめています。

視覚的な影響も無視できません。差分表示と読み取り済みチェックによる上書き防止は、いずれもEdit・Writeツールの機能で、heredocやcat > fileはどちらも経由しません。全盲のユーザーからは、差分こそが変更内容を知る唯一の手段であり、これが失われると変更に気づく手段そのものがなくなるという報告が上がっています。

計測されたコスト影響もあります。同じジャッジング用エージェントを比較した報告では、指示が付く前後でターン数・キャッシュ読み取りトークン数がおよそ倍増しました。

原因はファイルを一度にReadせず、headやsed -nで少しずつ読み返す振る舞いに切り替わったことです。出力結果は変わらないままターン数だけが増えるため、エラーは出ずに課金だけが積み上がります。トランスクリプトを追うまで11日間気づかなかったとされています。

もう一つ、heredocを使う編集は別のバグと組み合わさると安全性が下がるという報告もあります。Bashツールには、コマンド文字列を正規表現で判定して標準入力のガードを外す既知の不具合があり、heredocの<<は毎回この判定に一致します。ガードが外れた状態で標準入力を読むコマンドが混じると、そのプロセスは120秒のタイムアウトまで固まります。ある利用者の計測では、Bash経由のファイル書き込みの割合が7月の21%から9月に74%まで上がるのに合わせて、ガードが外れた呼び出しの割合も20.4%から28.6%まで上昇しました。

/rewindが「成功」と表示されるのに戻らない理由

Claude Codeのrewindコマンドが記録しているのは、Claudeのファイル編集ツールによる変更だけです。rmやmvのような単純なbash操作が対象外なのはもともと知られていましたが、Auto ModeがEdit・Write自体をBash経由に振り替えると、普通のファイル編集までこの対象外の側に落ちてしまいます。

issue #87575の報告では、複数ファイルを編集させたあと/rewindで戻したにもかかわらず、git statusを確認すると変更がそのまま残っていたと記録されています。/rewindのメニュー自体はエラーを出さず、復元が成功したという表示だけが進みます。ユーザーが変更は取り消されたと信じて作業を続け、後から古いコードの上に新しい変更を積み重ねていた、という実害も報告されました。

編集手段が混在したセッションではさらに紛らわしいことが起きます。1ファイルをEditで、別の1ファイルをsed -iで編集して/rewindを試した報告では、メニューがコード復元の選択肢を通常どおり表示し、実行後も「成功」と出ました。

公式のチェックポイントのページは、シンボリックリンクなど復元できないファイルがあるとRestored the code, but skipped N filesという警告を出すと説明しています。Bash編集の報告では、この警告のない「成功」表示でした。

なお、公式の制限事項はBashでrm・mv・cpを実行した場合の変更を対象外としています。sedやheredocでの編集を名指しはしていませんが、同じ「Bash経由の変更」に含まれます。

CLAUDE_CODE_THRIFTY_SONICで止める方法

止める方法は環境変数CLAUDE_CODE_THRIFTY_SONICを"0"に固定することです。シェルのexportは自分の対話セッションにしか効かないため、チーム全体やヘッドレス実行にも効かせたい場合はsettings.jsonのenvに書きます。

{
  "env": {
    "CLAUDE_CODE_THRIFTY_SONIC": "0"
  }
}

値を"0"にする方法はissue #88041のコメントでv2.1.237・v2.1.241・v2.1.247・v2.1.257のそれぞれで有効と確認されています。別のissue #90450では、値を"false"にする方法がv2.1.261・v2.1.263でmacOS・Windows双方から複数人独立に確認されています。

注意点が2つあります。まず、環境変数はセッション開始時にしか読まれません。実行中のセッション内で気づいて設定しても、その回のセッションには反映されません。実行中にShift+Tabでauto modeから抜けても、すでに挿入されたBash優先の指示はそのセッションに残ったままです。次に、"disabled"や"none"のように0・false・no・off以外の文字列は、オフとは扱われません。未設定と同じく内部の割り当て(cohortなど)に従うため、止まらない可能性があります。"0"か"false"のどちらかを使うのが安全です。

disableAutoMode設定でauto mode自体を無効化しても、この指示は止まりません。~/.claude/settings.json・プロジェクトのローカル設定・--settings引数のいずれにdisableAutoModeを置いても、Opus 5とbypassPermissionsの組み合わせでは指示が挿入され続けたという報告があります。auto modeという選択肢を消す設定と、auto mode内でのツール選択を誘導する指示は、別の仕組みで動いています。

環境変数を触れない管理環境では、acceptEditsモードに切り替えたうえでpermissions.allowにBashとSkillを許可する運用が、指示が付かない代替として報告されています。使えるツールの範囲は変えずにコストは基準値に戻るとされていますが、PermissionDenied hookでauto mode拒否時の再試行を制御するような、auto mode固有のフック連携は使えなくなる点はトレードオフです。CLAUDE.mdへの注意書きだけで上書きしようとする対処法は、効いたという報告と効かなかったという報告の両方があり、システムプロンプトの指示に対する優先度が不安定なため、単独の対策では効果が安定しません。

v2.1.269で追加されたbashEditDiffEnabledはどこまで直すか

v2.1.269(2026年9月11日リリース)のchangelogには、「Bashツールがファイル編集を担ったとき、変更内容の差分をBashツールの結果に追加する(bashEditDiffEnabled設定)」という項目が入りました。Bash経由の編集がそのまま起きても、少なくとも差分は見えるようになる変更です。

changelogの記述はこの1行だけで、/rewindのチェックポイント追跡やEdit|Write限定のフックが発火するようになったとは書かれていません。issueのその後も、解決の報告は見当たりません。#88041の最後のコメントは9月9日の安全性の指摘で、#90450には9月23日にv2.1.280で再現するという報告、9月25日には実セッションでの発生頻度の計測が追加されています。3件ともopenのままです。チェックポイントの制約にあるとおり、Bashによる変更が復元対象外になる仕様の根は共通で、/rewindの失敗は解消されていないと見るのが妥当です。

この設定は差分の表示だけではありません。有効なとき、PostToolUseのBashフックはtool_response.bashEditDiffで変更されたファイルの一覧を受け取ります。Edit|Write限定のフックが素通りされる問題に対しては、Bash向けのフックで同じ検査を受け直す抜け道になります。ただし一覧はベストエフォートの公開ベータで、変更の取りこぼしがあり得ます。レビュー対象の把握には使えますが、強制ゲートの代わりにはなりません。

• 既定は未設定で、auto modeとbypassPermissionsのときに記録します。設定リファレンスの表現は「Claude CodeがBash経由の編集を指示するとき」です。
• trueにするとすべての権限モードで記録します。効くのはユーザー設定・--settings・管理設定のtrueだけで、リポジトリの.claude/settings.jsonに書いても有効になりません。
• 一覧はGitリポジトリ内の変更が対象で、Gitが無視するファイルとサブモジュールは載りません。実行中に別のプログラムが変えたファイルが載ることもあります。バックグラウンド実行と読み取り専用コマンドには差分が付きません。

{
  "bashEditDiffEnabled": true
}

環境変数CLAUDE_CODE_BASH_EDIT_DIFFは、この設定より優先して1セッションだけ切り替えます。一方でCLAUDE_CODE_THRIFTY_SONICは、v2.1.285の時点でも公式の環境変数一覧に載っていません。

まとめ

Auto Modeは条件がそろうと、ファイル編集をEdit・WriteでなくBashのsedやheredocへ誘導する指示をシステムプロンプトに追加します。この指示下で行われた編集は/rewindのチェックポイントに記録されず、Edit|Write限定のフックも発火しません。止めるにはCLAUDE_CODE_THRIFTY_SONICを"0"にしたsettings.jsonをセッション開始前に用意しておく必要があり、disableAutoModeやCLAUDE.mdへの注意書きでは代用できません。v2.1.269で差分表示とBash向けフックへの変更一覧の受け渡しが加わりましたが、チェックポイント側の追跡は直っていません。/rewindを当てにしない前提で、大きな編集の前にコミットを挟んでおくと、戻らなかったときにもgitで戻れます。CLAUDE.mdの編集ルールとの衝突はauto modeのBash優先指示とCLAUDE.mdの衝突で扱っています。