claude remote-controlの--sandboxがエラーで止まる原因と代替設定

claude remote-control --sandbox や --no-sandbox を実行して Error: --sandbox is not supported by claude remote-control と出たなら、原因はフラグそのものです。Claude Code v2.1.300でこの2つは claude remote-control から削除されました。サーバーは起動せず、終了コード1で止まります。

直し方は2択です。--no-sandbox はコマンドから外すだけで済みます。--sandbox で隔離したかったなら、フラグを外したうえで、設定ファイルの sandbox.enabled を true にします。

出るエラーは2種類で、どちらもexit 1

エラー文はフラグごとに違います。ターミナルに出る文言は次のとおりです。

Error: --sandbox is not supported by claude remote-control. The flag had no effect and was removed. To sandbox sessions, set sandbox.enabled to true in settings.
Error: --no-sandbox is not supported by claude remote-control. The flag had no effect and was removed. Remove it from the command.

どちらも「効果がなかったため削除した」と書かれています。つまり、旧版でフラグを付けていても、claude remote-control が起動するセッションは、そのフラグだけでは隔離されていなかったことになります。--sandbox を付けて安心していた場合、v2.1.300のエラーは、隔離の抜けに気づくきっかけにもなります。

変更自体はv2.1.300のchangelogにも載っています。リリース全体の変更点はClaude Code v2.1.300のリリースノートにまとめています。

旧フラグはどこに残っているか

手で打つコマンドより、一度書いて忘れた場所が本命です。サーバーを常駐させている環境では、起動コマンドが次のような場所に埋まっています。

• systemdのユニットファイルやlaunchdのplist(ExecStart や ProgramArguments)
• 起動用のシェルスクリプト、Makefile、package.json のscripts
• tmuxやscreenを立ち上げるラッパー、dotfiles内のエイリアス
• コンテナの CMD / ENTRYPOINT や、CIのジョブ定義

Claude Codeの更新だけが先に進むと、こうした定義は動いていた頃のまま残ります。サービスが再起動を繰り返しているときは、まず該当ファイルを検索します。

grep -rn -E "remote-control.*--(no-)?sandbox" \
  ~/.config ~/bin ~/dotfiles /etc/systemd/system 2>/dev/null

検索先は環境に合わせて足してください。見つかった行から --sandbox か --no-sandbox を消せば、エラーの原因は取り除けます。

フラグを消しても起動しないときは、別のエラーを疑います。信頼していないディレクトリで、標準入力や標準出力が端末でないまま起動すると、確認の質問ができず Workspace not trusted で終了します。サービス定義から起動する場合は、先に端末でそのディレクトリを一度信頼しておきます。ホームディレクトリでは信頼が保存されないため、作業用のプロジェクトディレクトリを指定します。

ExecStart=/usr/local/bin/claude remote-control --sandbox --name "dev-box"

ExecStart=/usr/local/bin/claude remote-control --name "dev-box"

--name のような他のフラグはそのまま使えます。claude remote-control が受け付けるフラグの一覧は、claude remote-control --help で確認できます。ただし、対応アカウントでサインインしていないと、ヘルプの代わりにエラーが返ります。

--sandbox の代わりに残っているフラグ

remote-control の後ろに置けるフラグは、隔離とは別の用途のものが中心です。旧フラグを外すついでに、起動コマンドを見直す材料になります。

--spawn worktree を選ぶと、オンデマンドで作られるセッションごとにgit worktreeが分かれます。ただし、これはファイルの競合を避けるための分離で、sandboxの代わりにはなりません。隔離したいのはBashの実行範囲なので、sandbox.enabled とは別に考える必要があります。

--permission-mode は、権限モードを acceptEdits などにして起動するときに使います。サーバーを無人で動かす環境では、モードの選び方が隔離と同じくらい挙動を左右します。

sandboxで動かしたいときはsettingsに書く

フラグの代わりになるのは、設定ファイルの sandbox.enabled です。Remote Controlのサーバーが起動するセッションを隔離するには、sandboxを設定ファイルで有効にします。

{
  "sandbox": {
    "enabled": true
  }
}

置き場所は、通常のsettingsと同じ4種類から選べます。

サーバーを動かすマシンのユーザー設定に書けば、claude remote-control を起動するたびに設定が読まれます。特定のリポジトリだけ隔離したいなら、そのリポジトリの .claude/settings.local.json が向きます。sandbox.enabled の既定値は false です。キー自体の挙動はsandbox.enabledの解説に詳しく書いています。設定ファイル全般はsettings.jsonの完全ガイドが参考になります。

LinuxとWSL2では先に依存パッケージを入れる

macOSは組み込みのSeatbeltで動くため、追加の準備は要りません。LinuxとWSL2では bubblewrap と socat が必要です。

sudo apt-get install bubblewrap socat

Fedoraなら dnf で同じ2つを入れます。入っていない状態で sandbox.enabled を true にしても、起動できない場合の既定は「隔離なしでコマンドを実行する」です。サーバーを無人で動かす環境では、sandbox.failIfUnavailable を true にしておくと、隔離できないときに起動時エラーで止まります。気づかないうちに素の状態で動き続ける事態を避けられます。

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

--settings で一時的に有効にしようとして詰まる落とし穴

通常の claude なら、--settings でセッション限りのsandbox設定を渡せます。そこで次のように書きたくなりますが、これは通りません。

claude --settings '{"sandbox": {"enabled": true}}' remote-control

上の1行は拒否されます。通る形は、--settings を使わず設定ファイルに書く方法だけです。

remote-control の前に置いたグローバルフラグは、サーバーが作るセッションに引き継がれません。--settings のように挙動を変えるフラグは、引き継げないまま黙って捨てる代わりに、Claude Codeが起動を拒否します。表示は「--settings before remote-control is not carried over to the sessions Remote Control starts」で始まるエラーです。

前に置くと拒否されるフラグと、黙って捨てられるフラグ

remote-control の前に置いた claude のグローバルフラグは、すべてが拒否されるわけではありません。サーバーが作るセッションの制限や設定を変えてしまうフラグだけが止まり、捨てても挙動が変わらないフラグは無視されて起動します。

見覚えのない新しいフラグも拒否の対象になりえます。まだ「捨てても安全」と認識されていないフラグは、新しいリリースで追加された直後だと同じエラーに当たります。

対処は、前に置いたフラグを外し、remote-control の後ろの専用オプションで同じことを指定することです。たとえば権限モードなら claude remote-control --permission-mode acceptEdits と書けます。--model を前に置いて起動が通っても、サーバーが作るセッションには反映されません。

v2.1.248より前は、グローバルフラグを先に置くと claude remote-control が自分のフラグを受け付けず、unknown option で失敗していました。古い環境から更新した直後にエラーの種類が変わっていたら、この変更が理由です。

隔離できているかを確かめる

設定を入れたら、サーバーを再起動し、接続したセッションからClaudeに次の2行を実行させます。自分で ! プロンプトに打つと、隔離の外で動くことが多いため、検証になりません。

touch が成功したら、ホームディレクトリが書き込み許可に入っていないかを確認し、作られた ~/sandbox-probe は消します。その後、セッション内で /sandbox を開き、設定の反映状態と依存パッケージを確かめます。

隔離の対象はBashコマンドで、サーバー自体ではない

sandbox.enabled が囲むのは、Bashコマンドとその子プロセスです。claude remote-control というサーバープロセスそのものを箱に入れる設定ではありません。ファイル編集ツールやMCPサーバーなど、隔離の外で動く部品もあります。サーバー全体を境界で包みたい場合は、dev containerやsandbox runtimeのような別の仕組みと組み合わせる話になります。

隔離の外で動くものは、おおむね次の3系統です。

• 組み込みのファイル・Webツール(Read、Edit、Write、WebFetch、WebSearch)は、sandboxではなく権限ルールで制御されます。denyRead に書いてもReadツールは止まらず、allowedDomains でWebFetchの宛先は絞れません
• Claude Codeが起動する別プロセス(コマンド型のhooks、ローカルのMCPサーバー、LSPサーバー、ステータスラインのコマンド、apiKeyHelper)は、ユーザーの権限のまま動きます
• Bashコマンドでも、excludedCommands に一致するもの、Claudeが許可を求めて隔離なしで再実行するもの、! プロンプトに自分で打ったものは隔離されません

Dockerなどのコンテナ内でサーバーを動かす場合、Linuxの実装には enableWeakerNestedSandbox という弱い入れ子モードがあります。特権のない環境でも動くようにする代わりに、隔離は大きく弱まります。外側で別の隔離が効いているときだけの選択肢です。

サブエージェントは親セッションと同じsandbox設定を使い、Bashコマンドは隔離されます。Remote ControlのセッションでhooksやMCPサーバーを多用していても、sandbox.enabled を true にしたところで、それらは対象外のままです。副作用まで抑えたいなら、権限ルールの側で別に絞ります。

旧版の --sandbox が「効果がなかった」と明記されている以上、フラグが消えたことで隔離が弱まった環境はありません。変わったのは、効いていなかった指定がエラーで見えるようになった点です。起動が通ったあとに、本当に隔離されているかをこの記事の手順で確かめておく価値があります。

Remote Controlの接続まわりのつまずきは別の原因が多く、起動後の切断や認証は接続できない・切れるときの対処が受け皿になります。基本の使い方はRemote Controlの使い方にあります。