anthropic-experimental/sandbox-runtimeコンテナを必要とせず、OSレベルで任意のプロセスに対してファイルシステムとネットワークの制限を強制する軽量なサンドボックスツール。
# Anthropic Sandbox Runtime (srt)
任意のプロセスに対して、コンテナを必要とせずOSレベルでファイルシステムとネットワークの制限を適用するための軽量サンドボックスツールです。
`srt` はネイティブのOSサンドボックスプリミティブ（macOSでは `sandbox-exec`、Linuxでは `bubblewrap`）とプロキシベースのネットワークフィルタリングを使用します。エージェント、ローカルMCPサーバー、bashコマンド、および任意のプロセスの動作をサンドボックス化するために使用できます。
> **ベータ版リサーチプレビュー**
>
> Sandbox Runtimeは、より安全なAIエージェントを実現するために [Claude Code](https://www.claude.com/product/claude-code) 向けに開発されたリサーチプレビューです。より広範なエコシステムがより安全なエージェント型システムを構築できるよう支援するため、早期のオープンソースプレビューとして公開されています。これは早期のリサーチプレビューであるため、APIや設定フォーマットは進化する可能性があります。AIエージェントをデフォルトでより安全にするためのフィードバックと貢献を歓迎します！
## インストール
```bash
npm install -g @anthropic-ai/sandbox-runtime
```
## 基本的な使い方
```bash
# Network restrictions
$ srt "curl anthropic.com"
Running: curl anthropic.com
<html>...</html> # Request succeeds
$ srt "curl example.com"
Running: curl example.com
Connection blocked by network allowlist # Request blocked
# Filesystem restrictions
$ srt "cat README.md"
Running: cat README.md
# Anthropic Sandb... # Current directory access allowed
$ srt "cat ~/.ssh/id_rsa"
Running: cat ~/.ssh/id_rsa
cat: /Users/ollie/.ssh/id_rsa: Operation not permitted # Specific file blocked
```
## 概要
このパッケージは、CLI ツールとしてもライブラリとしても使用できるスタンドアロンのサンドボックス実装を提供します。**デフォルトで安全**という設計思想に基づいており、開発者の一般的なユースケースに合わせて調整されています。プロセスは最小限のアクセス権で起動し、必要な穴だけを明示的に開けます。
**主な機能:**
- **ネットワーク制限**: HTTP/HTTPS やその他のプロトコル経由でアクセスできるホスト/ドメインを制御
- **ファイルシステム制限**: 読み取り/書き込み可能なファイル/ディレクトリを制御
- **Unix ソケット制限**: ローカル IPC ソケットへのアクセスを制御
- **違反モニタリング**: macOS では、システムのサンドボックス違反ログストアに接続してリアルタイムのアラートを取得
### ユースケース例: MCP サーバーのサンドボックス化
主要なユースケースの一つは、Model Context Protocol (MCP) サーバーをサンドボックス化してその機能を制限することです。例えば、filesystem MCP サーバーをサンドボックス化するには:
**サンドボックス化なし** (`.mcp.json`):
```json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
```
**サンドボックス化あり**（`.mcp.json`）：
```json
{
"mcpServers": {
"filesystem": {
"command": "srt",
"args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
}
}
}
```
次に、`~/.srt-settings.json` で制限を設定します:
```json
{
"filesystem": {
"denyRead": [],
"allowWrite": ["."],
"denyWrite": ["~/sensitive-folder"]
},
"network": {
"allowedDomains": [],
"deniedDomains": []
}
}
```
これで、MCP サーバーは拒否されたパスへの書き込みがブロックされます:
```
> Write a file to ~/sensitive-folder
✗ Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'
```
## 仕組み
サンドボックスは OS レベルのプリミティブを使用して、プロセスツリー全体に適用される制限を強制します：
- **macOS**: 動的に生成された [Seatbelt プロファイル](https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sandbox-Guide-v1.0.pdf) を使用して `sandbox-exec` を実行します
- **Linux**: ネットワーク名前空間の分離を伴うコンテナ化のために [bubblewrap](https://github.com/containers/bubblewrap) を使用します
- **Windows**: 専用の `srt-sandbox` ローカルユーザーアカウントでサンドボックス化されたプロセスを実行し、そのアカウントの SID をキーとした [Windows Filtering Platform](https://learn.microsoft.com/en-us/windows/win32/fwp/windows-filtering-platform-start-page) の外向きフェンス、書き込み制限付きトークン、および作業ツリー上の明示的な ACE を適用します
0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305
### 二重分離モデル
効果的なサンドボックス化には、ファイルシステムとネットワークの両方の分離が必要です。ファイル分離がなければ、侵害されたプロセスが SSH キーやその他の機密ファイルを窃取する可能性があります。ネットワーク分離がなければ、プロセスがサンドボックスを脱出して無制限のネットワークアクセスを獲得する可能性があります。
**ファイルシステム分離** は読み取りと書き込みの制限を強制します：
- **読み取り**（拒否してから許可するパターン）：デフォルトでは、読み取りアクセスはどこでも許可されます。広い領域（例：`/Users`）を拒否し、その中の特定のパス（例：`.`）を再許可することができます。`allowRead` は `denyRead` より優先されます — これは書き込みとは逆で、書き込みでは `denyWrite` が `allowWrite` より優先されます。`allowRead` 領域の内側にあり、その領域より具体的な `denyRead` エントリ（例：`allowRead: ["."]` と組み合わせた `denyRead: ["**/.env"]` や `["./secrets"]`）は、依然として拒否されたままです。
- **書き込み**（許可のみのパターン）：デフォルトでは、書き込みアクセスはどこでも拒否されます。パス（例：`.`、`/tmp`）を明示的に許可する必要があります。許可リストが空の場合、書き込みアクセスはありません。
**ネットワーク分離**（許可のみのパターン）：デフォルトでは、すべてのネットワークアクセスが拒否されます。ドメインを明示的に許可する必要があります。allowedDomains リストが空の場合、ネットワークアクセスはありません。ネットワークトラフィックはホスト上で実行されるプロキシサーバーを経由してルーティングされます：
- **Linux**: リクエストは Unix ドメインソケットを介してファイルシステム経由でルーティングされます。サンドボックス化されたプロセスのネットワーク名前空間は完全に削除されるため、すべてのネットワークトラフィックはホスト上で実行されるプロキシ（サンドボックスにバインドマウントされた Unix ソケットでリッスン）を経由する必要があります
- **macOS**: Seatbelt プロファイルは特定の localhost ポートへの通信のみを許可します。プロキシはこのポートでリッスンし、すべてのネットワークアクセスのための制御されたチャネルを作成します
- **Windows**: マシン全体の WFP フィルタセットが、プロキシポート範囲へのループバックを除き、`srt-sandbox` アカウントとして実行されるプロセスによる外向き接続をブロックします。プロキシはその範囲内でリッスンし、すべてのネットワークアクセスのための制御されたチャネルを作成します。このフィルタは、ソケットを作成する前にスレッドに別のトークンを設定するサンドボックス化されたプロセスや、システムサービスがその代理で運ぶトラフィックには追従しません。Windows の[既知の制限事項](#known-limitations)を参照してください
HTTP/HTTPS（HTTP プロキシ経由）とその他の TCP トラフィック（SOCKS5 プロキシ経由）の両方が、ドメインの許可リストと拒否リストを強制するこれらのプロキシによって仲介されます。
Claude Code でのサンドボックス化の詳細については、以下を参照してください：
- [Claude Code サンドボックス化ドキュメント](https://docs.claude.com/en/docs/claude-code/sandboxing)
- [Beyond Permission Prompts: Making Claude Code More Secure and Autonomous](https://www.anthropic.com/engineering/claude-code-sandboxing)
## アーキテクチャ
```
src/
├── index.ts # Library exports
├── cli.ts # CLI entrypoint (srt command)
├── utils/ # Shared utilities
│ ├── debug.ts # Debug logging
│ ├── settings.ts # Settings reader (permissions + sandbox config)
│ ├── platform.ts # Platform detection
│ └── exec.ts # Command execution utilities
└── sandbox/ # Sandbox implementation
├── sandbox-manager.ts # Main sandbox manager
├── sandbox-schemas.ts # Zod schemas for validation
├── sandbox-violation-store.ts # Violation tracking
├── sandbox-utils.ts # Shared sandbox utilities
├── http-proxy.ts # HTTP/HTTPS proxy for network filtering
├── socks-proxy.ts # SOCKS5 proxy for network filtering
├── linux-sandbox-utils.ts # Linux bubblewrap sandboxing
├── macos-sandbox-utils.ts # macOS sandbox-exec sandboxing
└── windows-sandbox-utils.ts # Windows srt-win sandboxing
```
## 使用方法
### CLI ツールとして
`srt` コマンド（Anthropic Sandbox Runtime）は、あらゆるコマンドをセキュリティ境界でラップします:
```bash
# Run a command in the sandbox
srt echo "hello world"
# With debug logging
srt --debug curl https://example.com
# Specify custom settings file
srt --settings /path/to/srt-settings.json npm install
```
設定ファイルは任意です — `~/.srt-settings.json` にファイルがなければ、`srt` は組み込みのデフォルトで動作します。ネットワークアクセスなし、デフォルトの書き込みパス以外への書き込みなし、読み取りは無制限です。ファイルが _存在する_ にもかかわらず空である場合、読み取れない場合、または検証に通らない場合はエラーとなります。`srt` はその旨を通知して終了し、デフォルトへのフォールバックは行いません。デフォルトはより弱い設定ではなく別の設定であり、フォールバックするとファイルの `denyRead`、`allowRead`、認証情報ルールをはじめ、ファイルに記述されたすべてが失われてしまうからです。`--settings` で指定したファイルも同様で、こちらも存在していなければなりません。
#### コマンド実行中に設定を更新する: `--control-fd`
`--control-fd <fd>` は、呼び出し元がすでに開いているディスクリプタから設定の更新を読み取ります。1 行につき 1 つの JSON オブジェクトで、設定ファイルと同じ形式です。各行は設定全体を置き換え、同じスキーマに対して検証されます。つまり、各行はパッチではなく完全な設定です。`network` と `filesystem` は必須であり、行に含まれないキーはデフォルトに戻ります。
```bash
# fd 3 is the read end of a pipe the caller writes lines to
srt --control-fd 3 -- npm test
```
コマンド実行中に、受け入れられた行が変更するもの:
- ネットワークリスト — `network.allowedDomains`、`deniedDomains`（`deniedDomainReasons` 付き）、および `deniedResolvedAddresses` — は、すべてのプラットフォームで次の接続時に有効になります。プロキシはリクエストごとにこれらを参照し、解決済みアドレスのチェックも同じ行から再構築されます。同様に `network.mitmProxy` と `network.tlsTerminate.excludeDomains` も、リクエストごとに読み取られます。
- `credentials.sigv4` は、srt が `credentials` ブロック付きで起動していた場合に限り、次のリクエストで有効になります。署名フックはその場合にのみインストールされ、ポリシーをキャプチャするのではなくリクエストごとに読み取ります。
- それ以外は何も変わりません。ファイルシステムルールはすでに seatbelt プロファイル、bubblewrap の argv、または Windows の ACE に組み込まれており、資格情報マスクはコマンドがラップされた時点で構築され、実行中のプロキシサーバーは起動時に `network.parentProxy` と、そもそも TLS を終端するかどうかをキャプチャしています。
- Windows では、srt はファイルアクセスセット（`filesystem.*` と `credentials.files`）が起動時に適用されたものと異なる行を検出し、`SRT_DEBUG` の下でのみそれを通知します。ACL の付与はセッション全体にわたるため、起動時に適用されたセットが有効なままです。行の残りの部分は上記のとおりに適用されます。
srt がチャネルを読み取る方法と、拒否するもの:
- ディスクリプタは **3 以上** の整数で、読み取り可能でなければなりません — `0`〜`2` は標準ストリームです。srt は、与えられたディスクリプタを読み取れない場合、コマンドを実行せずにエラーで終了します。そのため、死んだチャネルが生きているチャネルと見なされることはありません。単一の更新を配信する前に死んだチャネルは、コマンドも道連れにします。配信後に死んだチャネルはその旨を通知し、最後に適用された設定の下でコマンドを実行し続けます。
- 有効な設定でない行は stderr に報告されて破棄され、以前の設定が有効なままです。行自体はターミナルではなくデバッグログに送られ、空行は黙って無視されます。
- srt はサンドボックスが起動してから初めて読み取りを開始するため、それ以前に書き込まれた更新は失われることなくチャネル内で待機します — また、サンドボックスが起動時に使用する設定によって上書きされることもありません。そのような行はコマンドがまだラップされている間に読み取られることがあり、その場合はファイルシステムルールを含めて、ラップに使用される設定となります。それがそんなに早く読み取られるかどうかは、ラップにかかる時間に依存します（Linux では、大きなツリーに対する deny glob は十分に長くなります）。そのため、コマンドが起動時に従わなければならないルールは設定ファイルに記述する必要があります。
- srt は **ラップされたコマンドとともに終了** し、ライターがディスクリプタを閉じるのを待ちません。入力の終了もエラーではありません。コマンドは最後に適用された設定の下で実行され続けます。
- srt には **専用の読み取り専用の端** を渡してください。srt はパイプまたはソケットを非ブロッキングモードに設定し、そのフラグはオープンファイル記述に付随するため、同じ記述を保持する他のもの — シェルの `exec 3<fifo`、親が引き続き使用するディスクリプタの `pass_fds` — は、それ以降自身のブロッキング読み取りで `EAGAIN` を受け取ります。
- macOS と Linux では、サンドボックス化されたコマンドはディスクリプタを受け取りません。srt はコマンドに対してそのスロットを `/dev/null` に向けるため、サンドボックス内の何も更新を読み取ったり、独自の設定を書き込んだりできません。Windows では、コマンドは 3 つの標準ストリームのみで起動されるため、制御ディスクリプタは渡されるディスクリプタの中に含まれません。
### 外部デサイダーを備えたスタンドアロンプロキシとして: `srt proxy`
`srt proxy`（または `bun run build:srt-proxy` でビルドされる単一ファイルの `srt-proxy` 実行ファイル）は、ワークロードを別の場所で実行するホスト向けに、サンドボックス化された子プロセスなしで SRT の HTTP プロキシのみを実行します。ホストが渡すリスニングソケットで受け入れ、すべての CONNECT をプロセス内で終端し、別の継承されたディスクリプタを介して到達する別個のデサイダープロセスが許可した場合にのみリクエストを転送します。コマンドライン、デサイダープロトコル、セキュリティモデルについては [docs/srt-proxy.md](https://github.com/anthropic-experimental/sandbox-runtime/blob/main/docs/srt-proxy.md) を参照してください。
### ライブラリとして
```typescript
import {
SandboxManager,
type SandboxRuntimeConfig,
} from '@anthropic-ai/sandbox-runtime'
import { spawn } from 'child_process'
// Define your sandbox configuration
const config: SandboxRuntimeConfig = {
network: {
allowedDomains: ['example.com', 'api.github.com'],
deniedDomains: [],
},
filesystem: {
denyRead: ['~/.ssh'],
allowWrite: ['.', '/tmp'],
denyWrite: ['.env'],
},
}
// Initialize the sandbox (starts proxy servers, etc.)
await SandboxManager.initialize(config)
// Wrap a command with sandbox restrictions
const sandboxedCommand = await SandboxManager.wrapWithSandbox(
'curl https://example.com',
)
// Execute the sandboxed command
const child = spawn(sandboxedCommand, { shell: true, stdio: 'inherit' })
// Handle exit and cleanup after child process completes
child.on('exit', async code => {
console.log(`Command exited with code ${code}`)
// Cleanup when done (optional, happens automatically on process exit)
await SandboxManager.reset()
})
```
**違反の帰属（`commandId` / `commandText`）。** ラップされたコマンドの実行中に観測された違反（seatbelt のログ行、seccomp イベント、プロキシによる拒否）は帰属キーの下に保存され、`annotateStderrWithSandboxFailures(key, stderr)` / `getViolationsForCommand(key)` は同じキーでそれらを検索します。デフォルトでは、キーはラップされた文字列そのものです。代わりに、呼び出しごとの不透明な `commandId`（例: ツール使用 ID）を渡してそれをキーにしてください — 推奨: キーは先頭 100 文字で比較されるため、そうしないと共通のプレフィックスを持つ長いコマンドが相互に誤帰属され、同じテキストの再実行が以前の実行のイベントを継承してしまいます。_実行する_ 文字列が呼び出しが _表す_ コマンドと異なる場合（例: 組み立てた `source <snapshot> && eval '<cmd>'` をラップする場合）、`commandText: '<cmd>'` も渡してください: これが `ignoreViolations` のコマンドパターンが照合される対象であり、各違反がその `command` として報告するものです。`wrapWithSandbox` に渡す `commandId` は、その後 `annotateStderrWithSandboxFailures` / `getViolationsForCommand` に渡すものと同じ非空の文字列でなければなりません。空のものは `commandId` がまったくないものとして扱われるため、キーはコマンドになります。
100 文字に切り詰められるのはキーのみです。v0.0.76 以降、報告される `command` — および `ignoreViolations` のコマンドパターンが照合されるテキスト — は、`commandId` なしでラップされた呼び出しではコマンド全体であり、先頭 100 文字ではありません。したがって、パターンが抑制できるのは以前より多くなることはあっても、少なくなることはありません。このプロセスのどの呼び出しも登録していない帰属キー（キャリアはサンドボックス内部から書き込み可能です）は、サニタイズされて同じキー長に切り詰められて報告されます。
```typescript
const wrapped = await SandboxManager.wrapWithSandbox(
assembledCommand, // what actually runs
undefined,
undefined,
undefined,
{ commandId: invocationId, commandText: rawCommand },
)
// ... run it ...
const annotated = SandboxManager.annotateStderrWithSandboxFailures(
invocationId,
stderr,
)
```
**どのルールも判定しないホストについての問い合わせ（ask コールバック）。** `SandboxManager.initialize` の第2引数は省略可能な `SandboxAskCallback` です。これは `network.deniedDomains`、`network.allowedDomains`、および（次のセクションで説明する）コマンドごとの許可リストのいずれも判定しなかった宛先について問い合わせを受けますが、`network.strictAllowlist` の下では決して問い合わせを受けません。コールバックがない場合、そのような宛先は拒否されます。コールバックは次のいずれかに解決されます：
- `true` - 接続を許可します。許可するのは値 `true` のみです。
- `false` - 拒否します。違反行には汎用の理由 `user denied` が報告されます。
- `{ allow: false, reason: '...' }` - 拒否し、汎用テキストの代わりに `reason` を違反行に報告します。これにより、`<sandbox_violations>` ブロックを読む者（モデルを含む）が、なぜ拒否されたのか、代わりに何をすべきかを知ることができます。サンドボックス化されたクライアントも、自身の CONNECT に応答する `403` のステータスフレーズとしてこれを読み取ります。
その他の応答は、真値かどうかに関わらず拒否され、汎用の理由が報告されます。これには `{ allow: true, reason: '...' }` のように `allow: false` を明示せずに `reason` を持つオブジェクトも含まれます。その理由は報告されません。
理由は、違反行の他の部分と同様に、保存される前にサニタイズされます。制御文字（改行やタブを含む）や不可視文字（ゼロ幅文字、その中の joiner、および bidi 制御文字を含む）の連続はそれぞれ1つのスペースになり、`<` と `>` は削除されるため、`re-run with <host> listed` は `re-run with host listed` として保存され、両端はトリムされます。結果は500文字に切り詰められ、`String.prototype.length` が数えるのと同じく UTF-16 コード単位で数えられます。その後に何も残らない理由は `user denied` にフォールバックします。1行のプレーンテキストとして記述してください。
**0.0.79 以降の最初のリリースにおける動作変更：** 以前のフィルタは任意の真値の応答で許可していたため、`true` 以外の真値（`1`、文字列、任意のオブジェクト）に解決されるコールバックは接続を許可していました。現在は拒否します。同じ理由で、`{ allow: false, reason }` を古いリリースに返すと、オブジェクトは真値であるため、そこでは許可として読み取られてしまいます。`SandboxManager.askCallbackDenyReason` は、このオブジェクトを理解するリリースでは `true` です。オブジェクトを返す前にこれを確認し、存在しない場合はプレーンな `false` で拒否してください。
```typescript
const deny = (reason: string) =>
SandboxManager.askCallbackDenyReason
? { allow: false as const, reason }
: false
await SandboxManager.initialize(config, async ({ host, port }) => {
if (await userApproves(host, port)) return true
return deny(`${host} was not approved for this session`)
})
```
**コマンドごとのネットワーク許可リスト（`registerCommandNetworkLists`）。** 1回の呼び出しは、実行中に限り、設定済みのものに加えて独自の許可リストを持てます：
```typescript
import { randomBytes } from 'node:crypto'
// 128 bits of randomness, 22 characters. See below for why nothing less will do.
const commandId = randomBytes(16).toString('base64url')
const wrapped = await SandboxManager.wrapWithSandbox(
command,
undefined,
undefined,
undefined,
{ commandId },
)
SandboxManager.registerCommandNetworkLists(commandId, {
allowedDomains: ['registry.example.org', '*.cdn.example.org:443'],
})
const child = spawn(wrapped, { shell: true })
const unregister = () => SandboxManager.unregisterCommandNetworkLists(commandId)
child.once('exit', unregister)
child.once('error', unregister) // the child never started
```
エントリは `network.allowedDomains` の文法とマッチャーを使用し、同じ検証を受けます。`registerCommandNetworkLists` は無効なエントリ、および 22 文字未満の `commandId`（対になっていないサロゲートはカウントされません）に対して例外をスローします。同じ id を再度登録するとそのリストが置き換えられます。`unregisterCommandNetworkLists` はリストを持たない id に対しては何も行いません（no-op）。`reset()` はすべての登録を削除します。
接続に対する評価順序は次のとおりです：
1. `network.deniedDomains` に一致すれば拒否；
2. `network.allowedDomains` に一致すれば許可；
3. `network.strictAllowlist` が拒否；
4. 接続が提示する id に対して登録されたリストに一致すれば許可；
5. ask コールバックがあればそれが決定し、なければ接続は拒否されます。
したがって、コマンドごとのエントリが設定済みの `deniedDomains` エントリを上書きすることは決してなく、`strictAllowlist` の下では完全に無視されます。また `network.*` に入ることもありません：`getConfig()` や `getNetworkRestrictionConfig()` には表示されず、マスクされたクレデンシャルのデフォルトの `injectHosts` スコープ（すなわち `network.allowedDomains`）も拡大しません。この方法で許可されたホストも、ダイヤル時に解決済みアドレスのチェックを通過します。また、コマンドごとのリスト内の IP リテラルは、そこでの除外を一切追加しません。
id が満たすべき条件、およびこの機能がそうでないもの：プロキシは、接続がどの呼び出しに属するかをプロキシのユーザー名から学習し、そのユーザー名はサンドボックス内のクライアントによって提示されます。したがって、id は接続を許可リストに結び付ける**唯一**のものです。id は**推測不可能**でなければなりません：少なくとも 128 ビットのランダム性を持ち、カウンタ、タイムスタンプ、コマンドから派生したものなどであってはなりません。別の稼働中の呼び出しの id を提示するサンドボックス化されたプロセスは、その呼び出しの許可を得ます。つまり、これは帰属（attribution）であり、1 つのセッションの同時実行コマンド間の境界ではありません。ラップされたコマンドを起動する直前に登録し、子プロセスが終了したとき、または起動しなかったときに登録を解除してください：コマンドより長く存続する登録は、その id を提示する価値がある期間を広げます。すべての帰属キーと同様に、id の最初の 100 文字のみが関与します。id は ASCII に保ってください：エンコードされた形式がプロキシのユーザー名（255 バイト）に収まらない非 ASCII の id の下にあるリストは、登録されますが決して適用されません。
`network.httpProxyPort` が外部プロキシを指定している間は、どのリストも適用されません：ラップはそのプロキシにユーザー名を与えないため、どの接続も id を運びません。`registerCommandNetworkLists` はそれでも成功し（`SRT_DEBUG` の下で 1 行でその旨を表示します）、すべての接続はリストが存在しないかのように決定されます。
#### 利用可能なエクスポート
```typescript
// Main sandbox manager
export { SandboxManager } from '@anthropic-ai/sandbox-runtime'
// Violation tracking
export { SandboxViolationStore } from '@anthropic-ai/sandbox-runtime'
// TypeScript types
export type {
SandboxRuntimeConfig,
NetworkConfig,
FilesystemConfig,
IgnoreViolationsConfig,
SandboxAskCallback,
FsReadRestrictionConfig,
FsWriteRestrictionConfig,
NetworkRestrictionConfig,
} from '@anthropic-ai/sandbox-runtime'
```
## 設定
### 設定ファイルの場所
デフォルトでは、サンドボックスランタイムは `~/.srt-settings.json` にある設定を探します。`--settings` フラグを使用してカスタムパスを指定できます:
```bash
srt --settings /path/to/srt-settings.json <command>
```
### 完全な設定例
```json
{
"network": {
"allowedDomains": [
"github.com",
"*.github.com",
"lfs.github.com",
"api.github.com",
"npmjs.org",
"*.npmjs.org"
],
"deniedDomains": ["malicious.com"],
"allowUnixSockets": ["/var/run/docker.sock"],
"allowLocalBinding": false
},
"filesystem": {
"denyRead": ["~/.ssh"],
"allowRead": [],
"allowWrite": [".", "src/", "test/", "/tmp"],
"denyWrite": [".env", "config/production.json"]
},
"ignoreViolations": {
"*": ["/usr/bin", "/System"],
"git push": ["/usr/bin/nc"],
"npm": ["/private/tmp"]
},
"enableWeakerNestedSandbox": false,
"allowNestedUserNamespaces": false,
"enableWeakerNetworkIsolation": false,
"allowAppleEvents": false
}
```
### 設定オプション
#### ネットワーク設定
**許可のみのパターン**を採用しています。すべてのネットワークアクセスはデフォルトで拒否されます。
- `network.allowedDomains` - 許可するドメインの配列（`*.example.com` のようなワイルドカードをサポート）。空の配列 = ネットワークアクセスなし。オプションの `:port` サフィックス（`api.example.com:443`、`*.example.com:8443`）を付けると、そのエントリをその宛先ポートに制限します。ポートを指定しないエントリは任意のポートに一致します。
- IPv6 リテラルは RFC 3986 形式で角括弧で囲む必要があります: `[::1]`、`[2001:db8::1]:443`。角括弧で囲まれていない複数コロンのエントリは曖昧として拒否されます（`2001:db8::1:443` 自体は有効なアドレスです）。
- `network.deniedDomains` - 拒否するドメインの配列（最初にチェックされ、allowedDomains より優先されます）。同じ `:port` サフィックスが使え、全拒否には裸の `*`（または `*:22`）が受け付けられます。
---
[Read more](https://github.com/anthropic-experimental/sandbox-runtime)