Claude Codeのsandboxで-600エラー — openとosascriptの直し方

macOSでClaude Codeのサンドボックスを有効にしたあと、openやosascriptがエラー-600で失敗するなら、原因はApple Eventsの遮断です。サンドボックスは既定でApple Eventsの送信を止めており、sandbox.allowAppleEventsをtrueにすると通ります。ただし、この設定はコード実行の分離を崩します。ユーザー設定か管理設定にだけ書け、プロジェクト設定では効きません。

-600エラーの原因はApple Eventsの遮断

macOSのopenコマンドやosascriptは、内部でほかのアプリケーションにApple Eventsを送ります。サンドボックスはこの送信を既定で許可しません。そのため、次のようなコマンドが-600で失敗します。

• openでファイルやアプリを開く
• osascriptでAppleScriptを実行する
• ブラウザでURLを開く認証フローを持つツール

トラブルシューティングの節には、open・osascript・ブラウザ経由の認証フローがmacOSで-600になる、という見出しの項目があります。症状が認証フローで出る場合も、同じ設定が対象です。

Windowsのネイティブ環境ではサンドボックス自体が動かず、LinuxとWSL2ではSeatbeltを使いません。この-600はmacOS固有の症状です。

sandbox.allowAppleEventsの設定

キーはsandbox.allowAppleEventsで、型はBooleanです。既定値はfalseで、trueにするとサンドボックス化されたコマンドがApple Eventsを送れます。サンドボックスを有効にするenabledと並べて書きます。

{
  "sandbox": {
    "enabled": true,
    "allowAppleEvents": true
  }
}

設定ファイルの置き場所は、次のとおりです。

設定リファレンスの一覧ではスコープが「User or managed」と書かれ、サンドボックスの解説ページはユーザー・管理・CLIの3つを挙げています。いずれにしても、リポジトリ側のファイルからは有効にできません。チェックアウトしたプロジェクトが勝手にこの緩和を持ち込めない作りです。

設定はこの書式で書き、反映後にopenを含む操作をもう一度試します。

# ユーザー設定の sandbox ブロックを確認する
grep -n -A4 '"sandbox"' ~/.claude/settings.json

許可すると何が崩れるか

allowAppleEventsをtrueにすると、サンドボックス化されたコマンドは次の2つができるようになります。

後者には歯止めがあります。アプリごとのmacOSの自動化許可ダイアログ(TCC)が出る場合は、そこで止まります。一方、前者のアプリ起動にはClaude Code側の確認がありません。サンドボックスの価値は「任意のコマンドが走っても、外には出られない」点にあるので、起動したアプリが外側の権限で動くなら、その分だけ分離は薄まります。

サンドボックスにはモードが2つあります。自動許可モードでは、サンドボックス内で動くコマンドは確認なしで承認されます。つまりallowAppleEventsをtrueにしたうえで自動許可モードを使うと、アプリの起動を含むコマンドが、承認の画面を一度も挟まずに流れます。通常の権限モードを選べば、サンドボックス内のコマンドにも従来どおり確認が出ます。モードは/sandboxのModeタブで切り替えられます。

一方、excludedCommandsに載せたコマンドと、サンドボックス外での再実行は、自動許可モードでも通常の権限確認を通ります。openを外に出す方式の確認が毎回出るのは、この仕様によるものです。

この設定が影響するのはコード実行の分離で、ファイルシステムやネットワークの制限は別です。ほかの緩和キーであるenableWeakerNetworkIsolationは、システムのTLS信頼サービスに届くための別の設定で、-600には効きません。症状に合わせてキーを選びます。

同じmacOSで出る別の失敗との見分け方

macOSのサンドボックスで外部コマンドが落ちる原因は、Apple Eventsだけではありません。トラブルシューティングの節には、症状の違う項目が並んでいます。

• gh、gcloud、terraformなどGo製のCLIがTLS検証で失敗する場合は、Apple Eventsではなく通信の信頼サービスの問題です。gh *のようなパターンをexcludedCommandsに足すか、MITMプロキシとカスタムCAを使っているならenableWeakerNetworkIsolationをtrueにします
• dockerコマンドが失敗する場合も、別の項目で扱われています
• エラーコードが-600で、コマンドがopen、osascript、ブラウザを開く認証フローなら、この記事の対象です

見分ける手がかりはエラーコードとコマンドの種類です。URLをブラウザで開いて認証するツールは、Apple Eventsを必要とするツールとして挙げられています。そこで-600が出るなら、通信の設定を変えても直りません。TLS検証の失敗のように、エラーの文言が証明書や接続を指しているときは、別の項目の対処に進みます。

全体を緩めずに済ませるexcludedCommands

openだけが必要なら、サンドボックス全体でApple Eventsを許可する必要はありません。open *のようなパターンをexcludedCommandsに足す方法があります。

{
  "sandbox": {
    "enabled": true,
    "excludedCommands": ["open *"]
  }
}

こちらは該当コマンドだけをサンドボックスの外で動かします。外で動くコマンドは通常の権限確認の流れに乗るので、openを呼ぶたびに確認が出ます。ただしopenはファイルでもアプリでも開けるため、Claudeが書いたファイルをopenで起動できてしまう点には注意が要ります。excludedCommandsは書いても効かない呼び出しの形があり、cdやリダイレクトを含む呼び出しは内側に残ります。なお、サンドボックスが管理者必須になっている環境では、プロジェクトの.claude/settings.jsonとsettings.local.jsonに書いたexcludedCommandsの項目は無視されます。チームで共有したい場合も、書く場所はユーザー設定か管理設定です。書き方と落とし穴はexcludedCommandsの解説にまとめています。

サンドボックス外での再実行を提案されたとき

-600で失敗したコマンドは、ClaudeがdangerouslyDisableSandboxを付けてサンドボックスの外で再実行しようとすることがあります。これは設定で許可を足す方法とは別の経路で、1回ごとに外で動かす抜け道です。承認の扱いは権限モードで変わります。

この再実行を許したくないときは、sandbox.allowUnsandboxedCommandsをfalseにします。dangerouslyDisableSandboxが無視され、excludedCommandsに一致しないコマンドは常にサンドボックス内で動きます。この場合、-600を避ける手段はallowAppleEventsかexcludedCommandsに絞られます。設定の意味と固め方はallowUnsandboxedCommandsの解説にあります。

/sandboxのOverridesタブでは、この項目が「Strict sandbox mode」として表示されます。

組織で管理する場合

管理設定でサンドボックスを必須にしている組織では、この緩和を開発者に使わせたくない場合があります。サンドボックスの解説ページは、管理設定に載せていない場合、開発者がユーザー設定や--settingsで緩和キーを有効にできるキーの一覧を挙げています。allowAppleEventsはその一覧にあり、リポジトリ側では有効にできないと注記されています。

使わせないなら、管理設定でfalseにします。Booleanのキーは管理設定の値が優先され、開発者が手元でtrueにしても上書きされます。

{
  "sandbox": {
    "enabled": true,
    "allowAppleEvents": false
  }
}

反映されないときの確認

trueにしても-600が残るときは、書いた場所を疑います。

• プロジェクトの.claude/settings.jsonやsettings.local.jsonに書いていないか。これらでは無視されます
• 管理設定がfalseを指定していないか。管理設定の値が優先されます
• sandbox.enabledがtrueになっているか。緩和キーはサンドボックスを有効にする設定ではありません
• --settingsで渡した場合、その設定は起動したセッションにだけ効きます。別のセッションで試していないかを確かめます

どれにも当たらないときは、openをサンドボックスの外に出すexcludedCommandsのほうが小さい変更で済みます。

設定が読み込まれているかを見る

セッション内で/sandboxを実行すると、パネルにModeタブ、Overridesタブ、Configタブが並びます。Configタブには解決後のサンドボックス設定が出るので、allowAppleEventsがtrueとして読まれているかを確かめられます。

/sandboxが「Sandbox settings are overridden by a higher-priority configuration」というエラーを出してパネルを開かないこともあります。管理設定や--settingsがsandbox.enabledなどを固定していると起きる表示です。どの設定元が読み込まれているかは、/statusのSetting sourcesの行で分かります。

excludedCommandsに切り替えた場合は、手動モードでopenを含む変更を伴うコマンドをClaudeに実行させます。「Bash command (unsandboxed)」という確認が出れば、パターンが一致してサンドボックスの外で動いています。

macOSの自動化の同意ダイアログ(TCC)は、allowAppleEventsをtrueにしても残ります。アプリごとに出るもので、-600が消えたあとにこの確認が出ても、設定が効いていないわけではありません。

まとめ

-600はバグではなく、Apple Eventsを既定で止めるサンドボックスの仕様どおりの動作です。allowAppleEventsで直せますが、見返りに、確認なしのアプリ起動を許す設定になります。使うツールが決まっているならexcludedCommandsで絞り、日常的に必要な個人環境だけユーザー設定で許可するのが、影響範囲の小さい順です。このキーが追加された経緯はv2.1.181のリリースノートにあります。