2026 Cursor Agent は誤削除が怖い？Apple Container で隔離サンドボックスを構築

Cursor Agentが誤った削除コマンドを実行し、作業中のMac上のファイルまで消す。

最短解は「可逆的なコードコピー」だけをApple Containerへ渡し、読み書き範囲、実行ユーザー、ネットワークを別々に制限する二層構成です。危険なコマンドのブラックリストだけに依存してはいけません。

最終更新：2026年8月29日。Apple Containerの公式リポジトリ、コマンドリファレンス、Cursor公式セキュリティ文書を基に確認しています。

この記事は、Cursor Agentに依存関係の導入、コード変更、ビルド、単体テストを任せる個人開発者、小規模チームの責任者向けです。XcodeのGUI作業やmacOS固有の署名まで含む開発環境を比較している場合は、最後の判断基準も確認してください。

Cursor Agent サンドボックスは「承認」だけでなくファイル境界で作る

Apple ContainerはApple Silicon Mac上でLinuxコンテナを軽量仮想マシンとして実行する仕組みです。完全なmacOSをコンテナ内で動かすものではありません。現行の公式案内ではApple Siliconが必要で、主な対象はmacOS 26です。詳しいシステム要件はApple Container公式READMEで確認してください。

Cursorのターミナル承認、実行モード、ルール、.cursorignoreは有用です。しかし、これらは単独のファイルシステム境界ではありません。Cursor公式文書でも、実行モードは最善努力の保護策として扱われています。.cursorignoreもターミナルやMCPのアクセスを完全には遮断しません。(Cursor公式のAgentセキュリティ文書)

隔離できるのは「コンテナへ渡したLinux実行環境」と「明示的にマウントしたディレクトリ」です。書き込み可能なマウントを与えれば、その範囲のファイルはコンテナ内のコマンドから削除できます。

開始前の比較：唯一の作業コピーか、捨てられる作業コピーか

典型的な事故は、Cursorで開いたディレクトリがそのまま本番用のローカルリポジトリで、そこにSSH設定、環境変数、生成物が混在している状態です。Agentが親ディレクトリへ移動したり、相対パスを誤認したりすると、コマンド承認済みでも被害範囲が広がります。

Apple Containerの導入前に、container system startでサービスが起動することを確認します。インストール方法と対応環境は、導入時点のApple Container公式ドキュメントに合わせてください。

第一歩：捨てられる作業コピーと検証用ファイルを作る

原本の親ディレクトリで、次のように一時クローンを作成します。既存の未コミット変更がある場合は、先に別のバックアップかGit worktreeへ退避してください。

git clone --no-hardlinks /path/to/original-repo /tmp/cursor-agent-work
cd /tmp/cursor-agent-work
printf 'DO_NOT_DELETE_HOST_CHECK\n' > host-boundary-canary.txt
git status --short

この例では、/tmp/cursor-agent-workだけをCursorで開きます。原本のパス、ホームディレクトリ、.ssh、クラウド認証情報、キーチェーンを書き込んだファイルは開かないでください。

次に、作業コピーの中へ.cursorignoreを置きます。

.env
.env.*
*.pem
*.key
credentials/
secrets/

これはCursorのインデックス対象を減らすための設定です。秘密情報を確実に守る仕組みではありません。Agentのターミナルが直接ファイルを読む可能性を考え、そもそも作業コピーへ秘密情報をコピーしない設計にします。詳しい制限事項はCursorのIgnore Fileリファレンスを確認してください。

第二歩：非rootのLinuxツールチェーンを用意する

Apple Containerのcontainer buildはDockerfileまたはContainerfileを読み込み、OCIイメージを作成します。以下は軽量な例です。プロジェクトがNode.js、Python、Rustなどを必要とする場合は、必要なパッケージだけを追加してください。

FROM alpine:3.22

RUN apk add --no-cache \
    bash \
    ca-certificates \
    git \
    nodejs \
    npm \
    python3 \
    py3-pip \
    make \
    g++

RUN addgroup -S agent && adduser -S agent -G agent
WORKDIR /workspace
USER agent

CMD ["/bin/bash"]

USER agentで通常ユーザーを既定にします。ただし、実行時にUIDを指定する場合は、Apple Containerの--uidと--gidを使ってホスト側の所有者に合わせます。マウント、UID、GID、作業ディレクトリの指定方法は、導入するバージョンのApple Containerコマンドリファレンスで再確認してください。

container system start
container build -t cursor-agent-sandbox:local .

第三歩：読み取り専用のルートと内部ネットワークで起動する

実行時だけ作業コピーを読み書き可能でマウントし、コンテナのルートファイルシステムは読み取り専用にします。キャッシュや一時生成物はtmpfsへ逃がします。Apple Containerの一時ファイルシステムとマウントオプションについては、公式のVolumesガイドに説明があります。

まず、ホスト専用ネットワークを作成します。

container network create --internal cursor-agent-internal

--internalはホスト専用ネットワークを作るオプションです。ただし、内部ネットワークだけで通信安全性を断定しないでください。実行環境のバージョンやネットワーク実装を確認し、実際に外部接続を検証します。

続いて、実行用スクリプトを作成します。

#!/bin/bash
set -euo pipefail

WORKSPACE="${1:?作業コピーの絶対パスを指定してください}"
shift

if [[ "$WORKSPACE" != /* || ! -d "$WORKSPACE" ]]; then
  echo "絶対パスの既存ディレクトリを指定してください" >&2
  exit 2
fi

IMAGE="cursor-agent-sandbox:local"
UID_VALUE="$(id -u)"
GID_VALUE="$(id -g)"

exec container run \
  --rm \
  --read-only \
  --uid "$UID_VALUE" \
  --gid "$GID_VALUE" \
  --workdir /workspace \
  --mount "type=bind,source=${WORKSPACE},target=/workspace" \
  --tmpfs /tmp \
  --tmpfs /run \
  --network cursor-agent-internal \
  "$IMAGE" \
  "$@"

保存後に実行権限を付けます。

chmod +x sandbox-run.sh
./sandbox-run.sh /tmp/cursor-agent-work bash -lc 'git status && npm test'

--read-onlyはルートファイルシステムを読み取り専用にし、--rmは停止後にコンテナを削除します。--mountの作業コピーだけは書き込み可能です。そのため、Agentがrm -rf /workspace/*を実行すれば、作業コピーは壊れます。原本まで守れるのは、原本をマウントしていない場合だけです。

依存関係を取得するために外部通信が必要な場合は、イメージ作成時に済ませるか、検証用ネットワークへ一時的に切り替えます。実行時にSSHエージェントを転送する設定、環境変数ファイル、認証情報のボリュームを追加しないでください。外部通信の制限と秘密情報の非注入は別の管理項目です。

Cursorへの接続：ルールは実行経路を揃えるために使う

Cursorで開くのは/tmp/cursor-agent-workだけです。プロジェクトルールには、次のような運用方針を記載します。

ビルド、単体テスト、依存関係の導入、スクリプト実行は sandbox-run.sh 経由で実行する。
原本リポジトリ、ホームディレクトリ、SSH設定、クラウド認証情報へアクセスしない。
削除、認証情報の操作、公開、署名、ホスト設定の変更は必ず人間の確認を得る。

自動実行を許可する候補は、git status、対象ディレクトリ内の読み取り、コンテナ内のビルド、単体テスト、静的解析です。次の操作は常に手動確認にします。

• rm、mv、一括削除、権限変更
• ssh、秘密鍵の読み取り、認証情報の投入
• 公開、リリース、署名、デプロイ
• /Users、ホームディレクトリ、システム設定へのアクセス
• コンテナ外でのインストールやサービス変更

Cursorの承認機能は残してください。ただし、Agentが包装スクリプトを迂回した場合も想定します。承認画面で許可したコマンドが宿主側で実行されれば、Apple Containerの保護は適用されません。Cursorの実行モードは補助防線であり、コンテナのマウント境界を代替しません。

破壊的な受け入れ確認：削除できる範囲を実際に壊す

初回は本物の重要データを使わず、誘餌ファイルで確認します。

• [ ] Apple SiliconとmacOS 26を確認した
• [ ] container system startが成功した
• [ ] 実行するバージョンと公式コマンドリファレンスをそろえた
• [ ] Cursorで原本ではなく一時コピーを開いた
• [ ] .ssh、キーチェーン由来のファイル、クラウド認証情報をコピーしていない
• [ ] --read-only、--rm、--tmpfsを実行コマンドで確認した
• [ ] 作業コピー内の誘餌ファイルを削除できることを確認した
• [ ] 原本の誘餌ファイルが残っていることを確認した
• [ ] ホームディレクトリの代表ファイルが読めないことを確認した
• [ ] 内部ネットワークから外部サイトへ接続できないことを確認した
• [ ] 終了後にcontainer list --allで不要なコンテナが残っていないことを確認した
• [ ] git diff、ログ、環境変数、作業コピー内の秘密情報を確認した

失敗基準は明確にします。原本が変わった、ホストの秘密情報が読めた、外部通信が通った、終了後もコンテナが残った、またはAgentが宿主側でコマンドを実行した場合は不合格です。すぐに作業コピーを削除し、原本との差分を確認してから構成を作り直します。

個人利用なら、この方式でLinux向けのビルドやテストを分離できます。一方、Xcode GUI、Appleデバイス、macOS署名、複数人の同時利用が必要になると、ローカルのスクリプトだけでは運用負荷が上がります。

チームで統一したい場合は、MacHTMLのヘルプで接続方式や環境管理を確認してください。複数の作業環境を切り替えながら検証する場合は、MacHTMLのコンソールで独立したMac環境の操作方法も確認できます。原本を公開せず、作業ごとに初期化できるMac環境が必要なら、MacHTMLの独立環境も比較対象になります。

よくある判断を先に確認する

原本をマウントしても安全ですか

安全とは言えません。読み取り専用のルートファイルシステムでも、書き込み可能なバインドマウントは別扱いです。コンテナ内のプロセスは、そのマウント先に対して削除、上書き、権限変更を実行できます。守るべき原本はマウントせず、一時クローンやGit worktreeだけを渡してください。

.cursorignoreだけで秘密情報を隠せますか

隠せません。.cursorignoreはCursorのインデックスや編集対象を減らす設定であり、Agentのターミナル処理を完全には制限しません。秘密情報を作業コピーへ置かないこと、コンテナへ認証ソケットを渡さないこと、環境変数を最小化することが必要です。

ネットワークを止めれば完全に安全ですか

完全ではありません。外部通信を止めても、書き込み可能な作業コピー内の削除は実行できます。また、悪意のある依存関係やビルドスクリプトがローカルファイルを破壊する可能性もあります。ネットワーク、マウント、UID、承認を別々に確認してください。

Apple ContainerをmacOS仮想マシンの代わりにできますか

できません。Apple Containerの主対象はLinuxコンテナです。macOSアプリ、Xcode GUI、キーチェーン、署名、実機接続が必要なら、完全なmacOS環境を持つ独立Macへ分離します。Linuxツールチェーンの隔離と、macOS開発環境の隔離は別の選択です。

ローカル構成から独立Mac環境へ切り替える境界

現在のローカル方式は、作業コピーを毎回作り直す手間、依存関係のキャッシュ管理、Apple SiliconとmacOS 26への依存、チームごとのルール配布が残ります。さらに、複数人で共有すると、誰かが原本や認証情報をマウントしてしまう運用ミスも起こり得ます。

Agentタスクを一時環境へ移したい、終了後にすぐ初期化したい、利用者ごとにMacを分けたいという条件なら、MacHTMLのレンタル環境を候補に入れる価値があります。長期間同じ環境で重い処理を続ける場合や、物理ポートへ直接接続する場合は自前Macが向きます。

反対に、短期の検証、危険度の高い自動実行、共有を避けたい開発作業では、最初から独立したMac環境へ逃がすほうが設計を単純にできます。ローカルのCursor Agent サンドボックスで原本、秘密情報、チーム共有の境界を守れないなら、作業場所そのものを分ける段階です。