एक हल्का सैंडबॉक्सिंग टूल, जो 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 टूल और लाइब्रेरी दोनों के रूप में किया जा सकता है। इसे **secure-by-default** दर्शन के साथ डिज़ाइन किया गया है जो सामान्य डेवलपर उपयोग मामलों के लिए अनुकूलित है: प्रक्रियाएँ न्यूनतम पहुँच के साथ शुरू होती हैं, और आप स्पष्ट रूप से केवल वही छेद करते हैं जिनकी आपको आवश्यकता होती है।
**मुख्य क्षमताएँ:**
- **नेटवर्क प्रतिबंध**: नियंत्रित करें कि किन होस्ट/डोमेन तक HTTP/HTTPS और अन्य प्रोटोकॉल के माध्यम से पहुँचा जा सकता है
- **फ़ाइलसिस्टम प्रतिबंध**: नियंत्रित करें कि किन फ़ाइलों/निर्देशिकाओं को पढ़ा/लिखा जा सकता है
- **Unix सॉकेट प्रतिबंध**: स्थानीय IPC सॉकेट तक पहुँच नियंत्रित करें
- **उल्लंघन निगरानी**: macOS पर, रीयल-टाइम अलर्ट के लिए सिस्टम के सैंडबॉक्स उल्लंघन लॉग स्टोर का उपयोग करें
### उदाहरण उपयोग मामला: MCP सर्वरों को सैंडबॉक्स करना
एक प्रमुख उपयोग मामला Model Context Protocol (MCP) सर्वरों को सैंडबॉक्स करके उनकी क्षमताओं को प्रतिबंधित करना है। उदाहरण के लिए, फ़ाइलसिस्टम 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) एग्रेस फ़ेंस, एक राइट-प्रतिबंधित टोकन, और कार्यशील ट्री पर स्पष्ट ACEs शामिल हैं
0d1c612947c798aef48e6ab4beb7e8544da9d41a-4096x2305
### दोहरा आइसोलेशन मॉडल
प्रभावी सैंडबॉक्सिंग के लिए फ़ाइलसिस्टम और नेटवर्क दोनों आइसोलेशन आवश्यक हैं। फ़ाइल आइसोलेशन के बिना, एक समझौता किया गया प्रोसेस SSH कुंजियाँ या अन्य संवेदनशील फ़ाइलें चुरा सकता है। नेटवर्क आइसोलेशन के बिना, एक प्रोसेस सैंडबॉक्स से बच निकल सकता है और अप्रतिबंधित नेटवर्क पहुँच प्राप्त कर सकता है।
**फ़ाइलसिस्टम आइसोलेशन** पढ़ने और लिखने के प्रतिबंध लागू करता है:
- **पढ़ना** (deny-then-allow पैटर्न): डिफ़ॉल्ट रूप से, पढ़ने की पहुँच हर जगह अनुमत है। आप व्यापक क्षेत्रों (जैसे, `/Users`) को अस्वीकार कर सकते हैं और फिर उनके भीतर विशिष्ट पथों (जैसे, `.`) को पुनः अनुमत कर सकते हैं। `allowRead` `denyRead` पर प्राथमिकता लेता है — लिखने के विपरीत, जहाँ `denyWrite` `allowWrite` पर प्राथमिकता लेता है। एक `denyRead` प्रविष्टि जो उस `allowRead` क्षेत्र से अधिक विशिष्ट है जिसके भीतर वह आती है (जैसे `denyRead: ["**/.env"]` या `allowRead: ["."]` के साथ `["./secrets"]`) फिर भी अस्वीकृत रहती है।
- **लिखना** (allow-only पैटर्न): डिफ़ॉल्ट रूप से, लिखने की पहुँच हर जगह अस्वीकृत है। आपको स्पष्ट रूप से पथों (जैसे, `.`, `/tmp`) को अनुमत करना होगा। एक खाली अनुमति सूची का अर्थ है कोई लिखने की पहुँच नहीं।
**नेटवर्क आइसोलेशन** (allow-only पैटर्न): डिफ़ॉल्ट रूप से, सभी नेटवर्क पहुँच अस्वीकृत है। आपको स्पष्ट रूप से डोमेन को अनुमत करना होगा। एक खाली allowedDomains सूची का अर्थ है कोई नेटवर्क पहुँच नहीं। नेटवर्क ट्रैफ़िक होस्ट पर चल रहे प्रॉक्सी सर्वरों के माध्यम से रूट किया जाता है:
- **Linux**: अनुरोधों को Unix डोमेन सॉकेट के माध्यम से फ़ाइलसिस्टम के ज़रिए रूट किया जाता है। सैंडबॉक्स्ड प्रोसेस का नेटवर्क नेमस्पेस पूरी तरह से हटा दिया जाता है, इसलिए सभी नेटवर्क ट्रैफ़िक को होस्ट पर चल रहे प्रॉक्सी के माध्यम से जाना चाहिए (Unix सॉकेट्स पर सुनना जो सैंडबॉक्स में बाइंड-माउंट किए गए हैं)
- **macOS**: Seatbelt प्रोफ़ाइल केवल एक विशिष्ट localhost पोर्ट से संचार की अनुमति देती है। प्रॉक्सी इस पोर्ट पर सुनते हैं, जिससे सभी नेटवर्क पहुँच के लिए एक नियंत्रित चैनल बनता है
- **Windows**: एक मशीन-व्यापी WFP फ़िल्टर सेट `srt-sandbox` खाते के रूप में चल रहे प्रोसेस द्वारा किए गए आउटबाउंड कनेक्शन को ब्लॉक करता है, सिवाय प्रॉक्सी पोर्ट रेंज के लिए लूपबैक के। प्रॉक्सी उस रेंज के भीतर सुनते हैं, जिससे सभी नेटवर्क पहुँच के लिए एक नियंत्रित चैनल बनता है। फ़िल्टर ऐसे सैंडबॉक्स्ड प्रोसेस का अनुसरण नहीं करते जो सॉकेट बनाने से पहले किसी थ्रेड पर एक अलग टोकन लगाता है, और न ही उस ट्रैफ़िक का जिसे कोई सिस्टम सेवा उसकी ओर से ले जाती है; Windows [ज्ञात सीमाएँ](#known-limitations) देखें
HTTP/HTTPS (HTTP प्रॉक्सी के माध्यम से) और अन्य TCP ट्रैफ़िक (SOCKS5 प्रॉक्सी के माध्यम से) दोनों इन प्रॉक्सी द्वारा मध्यस्थ किए जाते हैं, जो आपकी डोमेन allowlists और denylists को लागू करते हैं।
Claude Code में सैंडबॉक्सिंग के बारे में अधिक जानकारी के लिए, देखें:
- [Claude Code Sandboxing Documentation](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>` कॉलर द्वारा पहले से खोले गए डिस्क्रिप्टर से कॉन्फ़िग अपडेट पढ़ता है,
प्रति पंक्ति एक 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` — अगले कनेक्शन पर, हर प्लेटफ़ॉर्म पर प्रभावी होती हैं: प्रॉक्सी उन्हें प्रति अनुरोध देखता है, और resolved-address जाँच उसी पंक्ति से फिर से बनाई जाती है। `network.mitmProxy` और `network.tlsTerminate.excludeDomains` भी ऐसा ही करते हैं, जिन्हें यह प्रति अनुरोध पढ़ता है।
- `credentials.sigv4` अगले अनुरोध पर प्रभावी होता है, बशर्ते srt किसी `credentials` ब्लॉक के साथ शुरू हुआ हो: साइनिंग हुक केवल तभी स्थापित होता है, और नीतियों को कैप्चर करने के बजाय प्रति अनुरोध पढ़ता है।
- और कुछ नहीं बदलता। फ़ाइलसिस्टम नियम पहले से ही seatbelt प्रोफ़ाइल, bubblewrap argv या Windows ACEs में हैं, क्रेडेंशियल मास्क तब बनाए गए थे जब कमांड को रैप किया गया था, और चल रहे प्रॉक्सी सर्वरों ने शुरू होते समय `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 पर कमांड केवल तीन मानक स्ट्रीम के साथ स्पॉन किया जाता है, इसलिए नियंत्रण डिस्क्रिप्टर उन डिस्क्रिप्टरों में नहीं है जो उसे दिए जाते हैं।
### बाहरी निर्णायक के साथ एक स्टैंडअलोन प्रॉक्सी के रूप में: `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` (जैसे कोई tool-use id) पास करें — अनुशंसित: कुंजियों की तुलना उनके पहले 100 अक्षरों पर होती है, इसलिए एक ही उपसर्ग साझा करने वाले लंबे कमांड अन्यथा क्रॉस-एट्रिब्यूट हो जाएंगे, और उसी टेक्स्ट को दोबारा चलाने पर पिछले रन के इवेंट विरासत में मिल जाएंगे। यदि आप जिस स्ट्रिंग को _निष्पादित_ करते हैं वह उस कमांड से भिन्न है जिसे इनवोकेशन _प्रतिनिधित्व_ करता है (जैसे आप एक संयोजित `source <snapshot> && eval '<cmd>'` को रैप करते हैं), तो `commandText: '<cmd>'` भी पास करें: यही वह है जिसके विरुद्ध `ignoreViolations` कमांड पैटर्न मिलान करते हैं और जिसे प्रत्येक उल्लंघन अपने `command` के रूप में रिपोर्ट करता है। `wrapWithSandbox` को आप जो `commandId` पास करते हैं वह वही गैर-रिक्त स्ट्रिंग होनी चाहिए जिसे आप फिर `annotateStderrWithSandboxFailures` / `getViolationsForCommand` को पास करते हैं; एक रिक्त स्ट्रिंग को कोई `commandId` नहीं माना जाता, इसलिए कुंजी कमांड ही होती है।
---
[Read more](https://github.com/anthropic-experimental/sandbox-runtime)