claude-code-actionのtsconfig.jsonクラッシュ — Bunの内部バグと回避策

anthropics/claude-code-action@v1をGitHub Actionsで使っていると、Claudeが1文字も応答する前にexit code 1でジョブが落ち、ログにInternal error: directory mismatch for directory ".../tsconfig.json", fd Nという一行が残ることがあります。原因は少なくとも2系統あり、片方は修正済みです。もう片方はBunの未解決バグで、しかもその一行はジョブが赤くなる直接の理由ではない、という報告が出ています。

このログの一行は、ジョブを落とす原因なのか

この一行はBunが出す警告で、エラー文自体が「You don't need to do anything, but this indicates a bug」と、操作は不要だと名乗っています。--tsconfig-overrideを渡すと出るメッセージで、Bunのoven-sh/bun#22023には、テストが通ったまま警告だけが出る再現手順が載っています。

echo '{}' > empty.json
printf 'import { test, expect } from "bun:test";\ntest("t", () => expect(1).toBe(1));\n' > plain.test.js
bun test --tsconfig-override=./empty.json ./plain.test.js

報告された出力は、directory mismatch for directory "<絶対パス>/empty.json", fd 4の警告に続けて「テストは通る」というものです。同じ日の別のコメントには、Linux上のBun 1.4.2でも警告が出るという報告が続いています。

一方で、claude-code-actionのジョブが実際に落ちた報告のログには、この一行と並んで次のような出力が残っています。

SDK execution error: Error: Claude Code process exited with code 1
Internal error: directory mismatch for directory "/home/runner/work/_actions/anthropics/claude-code-action/v1/tsconfig.json", fd 4.
You don't need to do anything, but this indicates a bug.

同じ一行が、無害な警告のときにも、ジョブの失敗のときにも出ています。見るべきは、その前後に何が出ているかです。

シンボリックリンクが先に落ちていた場合

ログのtsconfig.jsonの行より前に、別のエラーが出ているケースです。claude-code-action#1220の報告では、PRのヘッドを信頼しない設定のとき、次の順にログが並びました。

Restoring .claude, .mcp.json, .claude.json, .gitmodules, .ripgreprc, CLAUDE.md, CLAUDE.local.md, .husky from origin/master (PR head is untrusted)
##[error]Action failed with error: ENOENT: no such file or directory, symlink
Internal error: directory mismatch for directory ".../v1/tsconfig.json", fd 4.

この報告ではCLAUDE.mdがAGENTS.mdへのシンボリックリンクでした。actionは機密パス(CLAUDE.md・.claude・.mcp.json・.claude.json・.gitmodules・.ripgreprc・.huskyなど)を.claude-pr/へスナップショットします。このときcpSyncが既定のdereference: falseでリンクをそのまま再現しようとし、宛先の親ディレクトリがまだ無いためsymlink()がENOENTで失敗します。

Action failed with errorと明示されているのはENOENTの行です。tsconfig.jsonの行は、その次のBun呼び出しで出た付随のメッセージという位置づけで、報告者は漏れたfdの影響と推測しています。

PR #1186がdereference: trueを追加し、2026年5月14日にマージされました。同じ日にENOENT側の根にあたるBunのcpSync不具合を直すBun 1.3.14への引き上げ(PR #1312)も入っています。このcpSync経路は、--tsconfig-overrideを足したPR #1174と同じ変更で入った退行だと、#1186のコメントは書いています。この経路の詳細はclaude-code-actionでsymlinkのCLAUDE.mdがcpSyncで落ちる問題と対処法にあります。

シンボリックリンクがなくても落ちる場合

こちらは--tsconfig-overrideをめぐる、Bun本体の問題です。actionがこのフラグを足したのは2026年4月5日のPR #1174で、メンテナーは「フラグ自体が引き金」と書いています。最初の対策案は、診断の段階で外れていました。

メンテナーのコメントによると、ホストランナー上の_actions/.../v1はシンボリックリンクではなく、ランナーがtarballをref名のディレクトリへそのまま展開します。PR #1239の想定した「リンク経由のパスと正規化後のパスのずれ」は、そこでは起きていませんでした。

現在のaction.ymlには、フラグを渡さない理由をコメントで残した箇所があり、「Bunが自動でactionのtsconfig.jsonを見つけるため、overrideは冗長」と書かれています。参照先はoven-sh/bun#25730ですが、このissueは2025年12月28日に起票され、同じ日にクローズされました。実際に追うべきissueはoven-sh/bun#22023のほうで、2025年8月21日の起票以来open、2026年10月3日にはBun 1.4.2での再現が2件追加されています。

10月3日のコメントは、ルートディレクトリのfdがdirname_fdとしてparse_tsconfigに渡され、openatがENOENTになって警告が出ると書いています。修正PRの#34980は#38606を優先して閉じられ、#38606はレビュー待ちです。

再現2件のうち1件は、フラグを自分で渡していなくても、プラグイン経由で子プロセスのBunが--tsconfig-override付きで起動され、警告が毎回出るというものです。こうなると--tsconfig-overrideを避けるだけでは足りず、ツールチェーンのどこかに潜んでいる可能性があります。

フラグを消した後も落ちる理由

#1315のマージ後も、報告は止まっていません。claude-code-action#1568の報告者は、同梱スクリプトにフラグを避けるコメントがあり、実際の呼び出しにもフラグがないのにエラーが出ると書いています。そのうえで、actionのBunランタイム内の別の経路が同じ根本バグを引いているのではないか、と推測しています。

もう一つ、見落とされやすい点があります。claude-code-action#1295の2026年7月15日のコメントは、バージョンを二分探索した結果を載せました。v1.0.171(2026年7月11日)までは成功し、v1.0.172(同14日公開)から失敗に転じたという内容です。コメントは理由を二つに分けています。

• Bunのエラーは自称どおり致命的ではなく、PRに.tsが1つも含まれなくても出る
• PR #1496(v1.0.172に入った)が、subtype: "success"かつis_error: trueの結果をステップ失敗として扱うようになった

つまり、以前は警告のまま緑になっていた実行が、7月14日から赤になった、という読み方です。#1568の8月15日のコメントは、{ "type": "result", "subtype": "success", "is_error": true, "num_turns": 1, "total_cost_usd": 0 }が結果として返り、Claude Codeの初期化自体は成功していたと書いています。報告者によれば、total_cost_usdはMax/OAuthの契約では常に0になる項目で、認証失敗の証拠にはなりません。実際のエラー本文が出力のサニタイズで隠れることも、原因の特定を難しくしています。

この9月の報告は@v1が指す9月15日付のコミット(Claude Code 2.1.273)でのものです。「同じSHAでも成功と失敗が入れ替わる」という8月までの報告と違い、毎回の再現になっています。

切り分けと回避策

ログを見た最初の手順は、症状の順序で絞り込むことです。

版のピン留め報告は食い違っている

7月15日の報告は、浮動タグ@v1をやめ、v1.0.171のコミットSHAに固定すると緑に戻ったとしています。ところが8月14日の別の報告では、v1.0.161とv1.0.165でクラッシュが再現し、v1.0.111では安定して成功していたとされます。7月の報告ではv1.0.171「以前」は成功とされているので、v1.0.161が失敗する8月の観測とは矛盾します。

再現条件の違い(ワークフローの種類、ランナーのイメージ、非決定性)が絡む可能性がありますが、片方の報告で一般化はできません。ピン留めを試すときは、直近の成功SHAを自分の環境で緑になるまで確かめる前提で使います。

自前のBunを指定する

FAQには、path_to_bun_executableで自前のBunバイナリを指定できるとあり、用途にNix/NixOS、Dockerコンテナ、特定バージョンの問題のデバッグが挙がっています。

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    path_to_bun_executable: "/path/to/custom/bun"

action.ymlの入力説明は「通常は不要」としており、このバグの修正手段としては案内されていません。Bunのissueでは、バグはBun 1.2.20で報告され、1.3.10、1.4.2でも再現しているため、Bunの版を替えるだけで消える見込みは低いと言えます。

show_full_outputの相関

claude-code-action#1568には、show_full_output: trueを入れると5回中5回で失敗を避けられたという報告があります。オン・オフを切り替えた結果が並んだ表も添えられていますが、#1568のスレッドには、同じ入力で再現したという続報は載っていません。この入力は、action.ymlの説明によれば、ツール実行結果を含む全メッセージを公開ログに出すため、秘密情報が漏れる恐れがあります。常設の回避策ではなく、原因を探る手がかりとして読むのが適切です。

Bunを買収した後も、Bun本体のバグは残っている

Anthropicは2025年12月3日にBunを買収しました。買収後もBunはオープンソースのまま提供が続いていますが、oven-sh/bun#22023は買収より前の起票から、openのままです。action側の対策(realpath案の却下、Bunの更新、フラグの削除)は、Bunの挙動を迂回する形で、fd管理の不整合そのものは直していません。

claude-code-actionでの不安定性報告は今回が初めてではありません。v2.1.227でも、allowed_non_write_users設定時にBashコマンドが全滅する別種の不具合が報告・修正されています。GitHub Actionsへの組み込み全体の設計はClaude CodeをGitHub Actionsに組み込むで扱っています。

まとめ

tsconfig.jsonの一行だけでBunのせいと決めると遠回りになります。ENOENTが先にないか、結果のis_errorが何を返しているかを読んでから、ピン留めなどの回避策を自分の環境で試すのが近道です。