exit code 126 だけでは原因は絞れませんが、今回の 2 件の issue はどちらも「Claude Code の Bash tool が、sandbox 有効時に毎回失敗する」という共通点がありました。しかも失敗は単発ではなく、pwd のような簡単なコマンドでも起きています。
症状の出方が似ていても、環境はかなり違います。ひとつは WSL2 上の Linux で、sandbox.enabled: true と filesystem.denyRead や permissions.deny Read(...) の組み合わせで起きています。もうひとつは macOS で、ログインシェルが zsh のときに起きています。前者は #51126、後者は #77466 です。
WSL2 側の issue では、表示上は Exit code 126 に加えて "Request interrupted by user for tool use" が出ています。ただし報告者は、実際にユーザーが中断したわけではないと書いています。#51126
macOS 側の issue では、sandbox.enabled: true と zsh の組み合わせで、Bash tool のコマンドが 100% 失敗すると報告されています。pwd ですら通りません。Claude Code が zsh 向けに生成する eval ベースのラッパーを、sandbox の静的なセキュリティフィルタが拒否している、という説明でした。#77466
WSL2 の件で特に目を引くのは、原因として bubblewrap のラッパーコマンドを /bin/bash -c の単一引数として渡しており、その文字列が Linux の MAX_ARG_STRLEN 制限を超える、という点です。報告では posix_spawn が E2BIG を返したとされています。ここは issue 本文でかなり具体的に書かれていますが、少なくとも筆者の環境出力だけからこの再現確認まではできていません。#51126
もう少し実務的に言うと、次のどちらかに当てはまるなら、このクラスタを疑う価値があります。
pwd など短いコマンドでも毎回 exit code 126 になるfilesystem.denyRead や permissions.deny Read(...) を多めに入れている一方で、今回の一次情報として手元で確認できているのは環境の基本情報だけです。再現コマンドや Claude Code の実行ログはありません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-06T08:51:32+09:00
なので、この検証環境そのものが issue の再現環境だとは言えません。言えるのは、少なくとも報告されている症状が「sandbox 有効時の Bash tool 失敗」「exit code 126」「WSL2 と macOS/zsh での別パターン」に分かれている、ということまでです。
もし自分のケースか見分けたいなら、まずは sandbox を有効にしているか、使っているシェルが zsh か、WSL2 かを見ます。ここが一致していて、しかも簡単なコマンドまで落ちるなら、アプリ側のコマンド内容より先に sandbox の組み立て方を疑うのが自然です。現時点では、少なくともこの 2 件について確立した恒久対処は本文中にありません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-06T08:51:32+09:00