clawk v0.4.0

किसी कोडिंग एजेंट को अपनी मशीन नहीं, बल्कि उसका अपना डिस्पोज़ेबल Linux मशीन दें।

इंस्टॉल करें · क्विकस्टार्ट · VM क्यों? · यह कैसे काम करता है · तुलना · FAQ · दस्तावेज़

एक कोडिंग एजेंट तभी उपयोगी होता है जब आप उसे वास्तव में काम करने देते हैं: पैकेज इंस्टॉल करना, उसके द्वारा लिखा गया कोड चलाना, सर्वर शुरू करना, नेटवर्क का उपयोग करना। आपकी अपनी मशीन पर यह दो बुरे विकल्प छोड़ता है। आप हर कमांड को मंज़ूरी देते हैं (और हर कुछ सेकंड में एक प्रॉम्प्ट पर नज़र रखते हैं), या आप --dangerously-skip-permissions चलाते हैं और उम्मीद करते हैं कि कुछ भी महत्वपूर्ण एक rm -rf या एक लीक हुए टोकन की दूरी पर न हो।

clawk एक तीसरा विकल्प है। किसी रेपो में cd करें, clawk टाइप करें, और Claude Code (या Codex, या pi, या एक शेल) एक डिस्पोज़ेबल Linux VM के अंदर काम कर रहा है (आपका कोड अंदर माउंट किया गया है, गेस्ट में रूट, कोई अनुमति प्रॉम्प्ट नहीं) जबकि आपकी फ़ाइलें, आपका कीचेन, और आपकी बाकी मशीन पहुंच से बाहर रहती है। एजेंट को आपकी मशीन के बजाय उसकी अपनी मशीन मिलती है।

clawk डेमो: clawk एक VM बूट करता है और claude को अटैच करता है; किसी अज्ञात सर्वर को डेटा भेजने का एक अवरुद्ध प्रयास clawk नेटवर्क अस्वीकृतियों में दिखाई देता है; clawk attach बाद में सैंडबॉक्स को फिर से शुरू करता है
_{एक काम करने वाले एजेंट के लिए एक कमांड; किसी अज्ञात सर्वर को डेटा भेजने का एक प्रयास, नेटवर्क अनुमति-सूची द्वारा अवरुद्ध; clawk attach बाद में सत्र को फिर से शुरू करता है।}

सीमा कोई प्रॉम्प्ट में लिखा नियम नहीं है जिससे एजेंट को बात करके हटाया जा सके। यह एक अलग मशीन है, और एकमात्र खुले रास्ते वही हैं जिन्हें आपने माउंट किया है। सैंडबॉक्स के अंदर एक शेल से:```console $ curl https://tracker.evil.example # not on the allow-list: blocked curl: (7) Failed to connect to tracker.evil.example port 443 after 2 ms: Connection refused

$ cat ~/.ssh/id_rsa # your keys never entered the VM cat: /home/agent/.ssh/id_rsa: No such file or directory

$ git push # ...yet this works: ssh-agent is forwarded Enumerating objects: 5, done.

सीमाओं के बारे में ईमानदार होने के लिए, अनुमति-सूची *अज्ञात* सर्वरों से कनेक्शन ब्लॉक करती है, न कि उन सर्वरों से जिन्हें आपने अनुमति दी है: github.com पहले से अनुमत है और फॉरवर्ड किया गया ssh-agent पुश कर सकता है, इसलिए एजेंट जो कुछ भी पढ़ सकता है उसे ऐसा समझें जिसे वह प्रकाशित कर सकता है। [सुरक्षा मॉडल](#security-model-and-its-limits) इसे विस्तार से बताता है।

और अगर एजेंट VM को तोड़ देता है, तो `clawk destroy && clawk` चलाएँ: एक नया VM, वही रिपॉजिटरी, और `--resume` बातचीत को पुनर्स्थापित करता है।

> [!IMPORTANT]
> **Pre-1.0 और तेज़ी से आगे बढ़ना।** रिलीज़ के बीच ब्रेकिंग बदलाव और कभी-कभी खुरदरे किनारों की उम्मीद करें; चीज़ें टूट सकती हैं और टूटेंगी। कृपया issues दर्ज करें; वह फीडबैक 1.0 को आकार दे रहा है।

## मुख्य विशेषताएं

- **एजेंट को कुछ भी करने दें।** यह एक डिस्पोज़ेबल VM में प्रतिबंधित नेटवर्क के साथ चलता है, इसलिए `rm -rf`, पैकेज इंस्टॉल, और अविश्वसनीय कोड आपके होस्ट, आपकी फ़ाइलों, या किसी भी चीज़ तक नहीं पहुँच सकते जिसे आपने स्पष्ट रूप से साझा नहीं किया।
- **एक कमांड में काम करना।** एक रिपॉजिटरी में `cd` करें और `clawk` चलाएँ। कोई Dockerfile, devcontainer, या सेटअप फ़ाइल नहीं। पहला बूट आपकी इमेज से rootfs बनाता है; उसके बाद हर बूट में सेकंड लगते हैं।
- **बिना कुछ खोए इसे तोड़ें।** स्वतंत्र रूप से नष्ट करें और फिर से बनाएँ; आपका कोड और एजेंट की बातचीत होस्ट पर रहती है। केवल डिस्पोज़ेबल VM डिस्क खो जाती है।
- **एक वास्तविक Linux बॉक्स, आपका टूलचेन।** कोई भी OCI इमेज rootfs है: एक पूर्ण OS जिसमें ठीक वही टूल हैं जिनकी आपके प्रोजेक्ट को ज़रूरत है। कोई Docker daemon आवश्यक नहीं।
- **रहस्य आपकी मशीन पर रहते हैं।** आउटबाउंड ट्रैफ़िक अनुमति-सूचीबद्ध है और आपका ssh-agent फॉरवर्ड किया जाता है, इसलिए VM में कुंजियाँ दर्ज किए बिना `git push` काम करता है।
- **प्रति प्रोजेक्ट या टिकट एक सैंडबॉक्स।** एक साथ कई चलाएँ; मल्टी-रिपोजिटरी टिकटों को प्रति रिपॉजिटरी एक git worktree मिलता है जिसमें समन्वित PR होते हैं। निष्क्रिय VM स्वचालित रूप से मेमोरी मुक्त करते हैं और डिस्क पर सस्पेंड हो जाते हैं, इसलिए एक भूला हुआ सैंडबॉक्स (लगभग) कुछ भी खर्च नहीं करता।

## VM क्यों?

clawk स्वायत्त कोडिंग एजेंटों के लिए एक सामान्य-उद्देश्यीय स्थानीय वातावरण है। VM ही मुख्य बिंदु है: यह एक पूरी मशीन है जिसे एजेंट अपना सकता है, न कि एक प्रक्रिया जो आपके उपयोग में आने वाली मशीन पर नीतियों में लिपटी हो।

- **एक अलग कर्नेल।** गेस्ट अपना खुद का Linux कर्नेल चलाता है, इसलिए होस्ट फाइलसिस्टम deny नियमों के पीछे छिपा नहीं है; यह कभी माउंट ही नहीं हुआ था।
- **एक पारंपरिक Linux वातावरण।** मानक कर्नेल, मानक userland, `/dev/kvm`-आकार की अपेक्षाएँ, इसलिए टूल वैसे ही व्यवहार करते हैं जैसे उनके दस्तावेज़ कहते हैं, बिना किसी syscall-फ़िल्टर आश्चर्य के।
- **गेस्ट में रूट।** सिस्टम पैकेज इंस्टॉल करें, `/etc` संपादित करें, एक मॉड्यूल लोड करें, एक विशेषाधिकार प्राप्त पोर्ट बाइंड करें। यह एजेंट का बॉक्स है जिसे वह पुनः कॉन्फ़िगर कर सकता है।
- **एक डिस्पोज़ेबल जीवनचक्र।** तोड़ना सस्ता और फिर से बनाना त्वरित; एक बर्बाद VM केवल एक `clawk destroy && clawk` दूर है, आपकी रिपॉजिटरी और बातचीत होस्ट पर अछूती रहती हैं।
- **होस्ट से मजबूत अलगाव।** अलगाव प्रोसेस-सैंडबॉक्स नीति को बिल्कुल सही पाने के बजाय हाइपरवाइज़र सीमा पर निर्भर करता है।

यह संयोजन उन वर्कलोड को चलाता है जिन पर एक प्रतिबंधित प्रोसेस सैंडबॉक्स आपसे लड़ने लगता है:

- पैकेज और नेटिव निर्भरताएँ इंस्टॉल करना;
- बैकग्राउंड सेवाएँ चलाना (डेटाबेस, कतारें, dev सर्वर);
- अविश्वसनीय बिल्ड और टेस्ट को पूरी गति से निष्पादित करना;
- सिस्टम-स्तरीय Linux टूलिंग का उपयोग करना जो एक वास्तविक मशीन की अपेक्षा करता है;
- और, समर्थित हार्डवेयर पर KVM-सक्षम गेस्ट कर्नेल के साथ, कंटेनर और Kubernetes dev वर्कफ़्लो जैसे Docker या Kind जो सैंडबॉक्स के *अंदर* चलते हैं। यह ऑप्ट-इन और हार्डवेयर-गेटेड है; सटीक आवश्यकताओं के लिए [Images](https://github.com/clawkwork/clawk/blob/main/docs/images.md#guest-kernel-override) देखें।

इनमें से कोई भी *उत्पाद* नहीं है; clawk सामान्य रूप से स्थानीय एजेंट कार्य के लिए है। Docker और Kubernetes केवल "एक वास्तविक मशीन चाहिए, सैंडबॉक्स्ड प्रोसेस नहीं" का सबसे तीखा उदाहरण हैं।

## इंस्टॉल

Apple silicon पर macOS 14+ की आवश्यकता है। (Linux firecracker के माध्यम से समर्थित है और वर्तमान में प्रयोगात्मक है — **[docs/linux-quickstart.md](https://github.com/clawkwork/clawk/blob/main/docs/linux-quickstart.md)** से शुरू करें, जो सेटअप, वर्कफ़्लो और अंतराल को कवर करता है। यह README macOS-प्रथम है।)```sh
brew install clawkwork/tap/clawk

स्रोत से (योगदानकर्ता, या यदि आप Homebrew का उपयोग नहीं करते हैं), Go 1.26+ की आवश्यकता है:```sh git clone https://github.com/clawkwork/clawk && cd clawk make install

किसी भी तरह से कोई अतिरिक्त होस्ट टूलिंग नहीं है: कोई Docker नहीं, कोई qemu नहीं, कोई sudo नहीं। 
हाइपरवाइज़र Apple का Virtualization.framework है, जो बाइनरी में लिंक किया गया है, और 
रिलीज़ बाइनरी में इन-गेस्ट एजेंट पहले से बिल्ट होता है — इसलिए Go टूलचेन की 
ज़रूरत केवल तब होती है जब आप स्रोत से बिल्ड करते हैं, और उस स्थिति में आपके पास वह होती है। पहली बार चलाने पर 
किसी भी लापता चीज़ की जाँच होती है और उसे ठीक करने की पेशकश की जाती है।

**अनइंस्टॉल:** `clawk destroy` से अपने सैंडबॉक्स हटाएँ, `rm -rf ~/.clawk` चलाएँ, फिर 
बाइनरी को `brew uninstall clawk` से हटाएँ (या स्रोत इंस्टॉल के लिए इसे `$GOBIN` से डिलीट करें)। 
इसके अलावा कुछ भी इंस्टॉल नहीं किया गया था: कोई launchd जॉब नहीं हैं; 
प्रति-सैंडबॉक्स डेमॉन सामान्य प्रक्रियाएँ हैं जो अपने VMs के साथ बाहर निकलती हैं।

## क्विकस्टार्ट

रोज़मर्रा का मामला, उस डायरेक्टरी के लिए एक सैंडबॉक्स जिसमें आप हैं:```sh
cd ~/code/my-project
clawk                      # boot a sandbox for this dir + attach claude
clawk run shell            # drop into a shell in the same sandbox
clawk run codex            # or another agent: codex, pi, opencode, shell
clawk down                 # stop the VM (repo + agent state persist)
clawk attach               # come back later — boots if stopped, reattaches claude
clawk destroy              # remove the VM (conversation history is kept)

सामान्य विकल्प:```sh clawk run claude -- --resume # pass args through to the agent clawk forward add my-project 3000 # expose a guest dev server on localhost:3000 clawk network allow my-project api.example.com

कई रिपॉजिटरी में फैले टिकट पर काम कर रहे हैं? एक ही कमांड हर रिपो के लिए एक नई ब्रांच पर git worktree के साथ एक सैंडबॉक्स बनाता है, और `clawk pr` बाद में जो भी बदला है उसके लिए क्रॉस-लिंक्ड PR खोलता है:```sh
cd ~/code/my-workspace     # contains a clawk.mod listing the repos
clawk work INFRA-123       # one sandbox, a worktree per repo, claude attached
clawk pr INFRA-123         # push branches + open one PR per repo

टिकट का पूरा जीवनचक्र (स्थिति, मर्ज के बाद फॉलो-अप ब्रांचेस, रीबेस) docs/ticket-mode.md में है।

टिप: Claude Code का उपयोग कर रहे हैं? claude setup-token चलाएँ, फिर clawk auth set-token एक बार चलाएँ, और हर सैंडबॉक्स पहले से साइन इन होकर आएगा, बिना /login और समानांतर सैंडबॉक्स के बीच कोई लॉगिन विरोध नहीं। देखें docs/claude-auth.md।

क्या क्या बचता है

एक नियम दृढ़ता को नियंत्रित करता है: VM डिस्पोज़ेबल है; जो कुछ भी आपको याद आएगा वह होस्ट पर रहता है।

	`clawk down`	`clawk destroy`
आपका रिपो (माउंटेड वर्कट्री; कमिट, ब्रांचेस)	✅	✅
एजेंट स्टेट (Claude/Codex/pi/opencode वार्तालाप, मेमोरी)	✅	✅
VM डिस्क (apt इंस्टॉल, कैशे, `$HOME`)	❌ (हर बूट पर नया बनाया जाता है*)	❌ (यही तो मकसद है)

* दो अपवाद: clawk snapshot को फिर से शुरू करने से डिस्क और मेमोरी बिल्कुल सस्पेंड की स्थिति में बहाल हो जाती है, और Linux/firecracker प्रोवाइडर अपनी डिस्क को destroy तक रखता है। हर बूट को जिन टूल्स की ज़रूरत होती है वे इमेज में होने चाहिए (vm ( image … )); प्रति-बूट सेटअप on up हुक में होता है।

एजेंट स्टेट प्रति-सैंडबॉक्स होस्ट-माउंटेड है: हर रनर का होम डायरेक्टरी — claude का ~/.claude/, codex का ~/.codex/, pi का ~/.pi/, opencode के दो XDG डायरेक्टरी — होस्ट पर ~/.clawk/namespaces/default/state/<name>/ के अंतर्गत रहते हैं, इसलिए एक पुनः बनाया गया सैंडबॉक्स --resume के साथ अपनी पुरानी वार्तालाप उठा लेता है। वह माउंट ही है जो वादे को सच बनाता है: VM डिस्क हर बूट पर इमेज से फिर से क्लोन होती है, इसलिए रनर उन डायरेक्टरी के बाहर जो कुछ भी लिखता है वह अगले clawk up पर चला जाता है।

डिफ़ॉल्ट रूप से पूर्ण स्वायत्तता (और `--safe` ऑप्ट-आउट)

रनर अपने "बाहरी रूप से सैंडबॉक्स्ड" मोड में लॉन्च होते हैं: claude को --dangerously-skip-permissions मिलता है, codex को --dangerously-bypass-approvals-and-sandbox मिलता है, pi को --approve मिलता है (इसमें कोई अनुमोदन प्रॉम्प्ट नहीं है जिसे बायपास किया जाए — यह बिल्कुल कोई सैंडबॉक्स नहीं भेजता — लेकिन यह प्रोजेक्ट-स्थानीय .pi/ सेटिंग्स और एक्सटेंशन को ट्रस्ट प्रॉम्प्ट के पीछे गेट करता है), और opencode को --auto मिलता है। अपनी खुद की मशीन पर वे फ्लैग लापरवाही होंगे; यहाँ वे ही मुद्दा हैं: VM सीमा और नेटवर्क अनुमति-सूची कंटेनमेंट प्रदान करते हैं, इसलिए एजेंट बिना प्रति-क्रिया प्रॉम्प्ट के पूरी गति से काम करता है। एजेंट केवल उसी को प्रभावित कर सकता है जो आपने माउंट किया और अनुमति-सूची में डाला, इससे अधिक कुछ नहीं (देखें SECURITY.md)।

फिर भी पुष्टिकरण प्रॉम्प्ट पसंद हैं? किसी भी अटैच में --safe जोड़ें (clawk --safe, clawk run claude --safe) और रनर उस सत्र के लिए अपने बायपास फ्लैग के बिना शुरू होता है।

नेटवर्किंग

आउटबाउंड ट्रैफ़िक डिफ़ॉल्ट रूप से अस्वीकृत है; हर सैंडबॉक्स की अपनी अनुमति-सूची होती है। DNS सब कुछ हल करता है; TCP, UDP (QUIC सहित), और सूची में नहीं आने वाले होस्ट्स के लिए ICMP echo अस्वीकार किए जाते हैं। सामान्य रजिस्ट्री (npm, PyPI, crates.io, GitHub, Anthropic, …) पहले से अनुमत हैं, और फ़िल्टर DNS-जागरूक है, इसलिए example.com को अनुमति देने से उसके IP घूमने पर भी काम जारी रहता है।```sh clawk network allow my-project api.stripe.com '*.internal.mycorp.com' 10.0.0.5 clawk network denials my-project # what the agent tried that got blocked clawk forward add my-project 3000 # localhost:3000 → the guest's dev server clawk forward add-reverse my-project 63342 # and the other way: a service on YOUR # localhost, reachable inside the guest

Denials को *hostname के आधार पर रिकॉर्ड किया जाता है जिसे guest ने resolve किया*, इसलिए `clawk network
denials` एक लॉग के रूप में पढ़ा जाता है कि agent क्या पहुँचने की कोशिश कर रहा था। पुनः उपयोग योग्य नामित
policies (जिसमें oisd जैसी बाहरी blocklists की सदस्यता लेना भी शामिल है) और `use` chain जो उन्हें परतों में जोड़ती है,
**[docs/networking.md](https://github.com/clawkwork/clawk/blob/main/docs/networking.md)** में हैं।

## Configuration: `clawk.mod`

कोई config file आवश्यक नहीं है; defaults उचित हैं। जब किसी project को अधिक
की आवश्यकता होती है, तो एक `clawk.mod` file उसे वर्णित करती है, go.mod-style syntax में:```text
sandbox my-project (
    vm (
        cpu    4
        memory 8GiB
        image  golang:1.25          # any OCI image is the rootfs
    )
    network ( allow api.example.com )
    forwards ( 3000 )
    env ( DATABASE_URL )            # forward a host var; values come from your shell
    # also: GH=${OTHER_NAME}, LOG=${LOG:-info} defaults, API=${API:?required}
    mcp (                           # MCP servers, ready on first boot
        linear https://mcp.linear.app/mcp header "Authorization: Bearer ${LINEAR_TOKEN}"
    )
    on create ( "go mod download" )
    agent (
        instructions "Ask before running destructive commands."
    )
)

ब्लॉक एक टेम्पलेट है: सैंडबॉक्स बनाते समय इसका स्नैपशॉट लिया जाता है, इसलिए चल रहा सैंडबॉक्स कभी अप्रत्याशित रूप से नहीं बदलता। पूरा संदर्भ (शेयर, गुप्त फ़ाइलें, स्किल्स, एजेंट मेमोरी सीडिंग, मल्टी-रेपो वर्कस्पेस रूट्स) docs/configuration.md में है; MCP सर्वर और उनके क्रेडेंशियल डिस्क से बाहर कैसे रहते हैं, यह docs/mcp.md में है; अपने Mac से USB-सीरियल बोर्ड को सैंडबॉक्स के अंदर रखकर माइक्रोकंट्रोलर कार्य करना docs/serial.md में है; इमेज और कस्टम गेस्ट कर्नेल (नested वर्चुअलाइज़ेशन के लिए उपयोग किए जाने वाले KVM-सक्षम कर्नेल सहित) docs/images.md में हैं।

लाइफ़साइकल```sh

clawk list # all sandboxes clawk status [] # state, forwards, blocked hosts; --json for scripts clawk up / down # boot / stop clawk pause / resume # suspend / resume the running VM in memory clawk snapshot # save to disk: RAM freed, guest intact; resume restores it clawk destroy # remove the VM; host-side state persists

`clawk snapshot` सैंडबॉक्स के लिए हाइबरनेशन है: गेस्ट की मेमोरी उसकी डिस्क के बगल में सहेजी जाती है और अगला बूट गेस्ट को ठीक वहीं पुनर्स्थापित करता है जहाँ वह था।
बैकग्राउंड प्रोसेस और डेव सर्वर ऐसे जारी रहते हैं जैसे कुछ हुआ ही न हो, और
`clawk attach` आपको एजेंट के सामने वापस ले आता है। पूर्ण कमांड सतह,
रनर डिस्पैच, और आइडल-मैनेजमेंट मशीनरी (बैलूनिंग, एडमिशन
कंट्रोल, ऑटो-स्टॉप) **[docs/commands.md](https://github.com/clawkwork/clawk/blob/main/docs/commands.md)** में हैं।

## यह कैसे काम करता है```text
you ──▶ clawk CLI ──▶ per-sandbox daemon (detached; owns the VM)
                        ├─ gvproxy: in-process userspace TCP/IP stack —
                        │  the DNS-aware outbound filter the guest can't reconfigure
                        ├─ vsock bridge to the in-guest pty-agent (no sshd)
                        ├─ ssh-agent proxy, macOS (signing stays on the host)
                        └─ VM: Virtualization.framework (macOS) / firecracker (Linux)
                             ├─ clawk-init, PID 1 (no systemd, no cloud-init)
                             ├─ your repo, live-mounted over virtio-fs
                             └─ claude / codex / pi / shell on a PTY

कुछ जानबूझकर किए गए विकल्प, संक्षेप में:

rootfs एक साधारण OCI इमेज है। clawk इसे खींचता है (कोई Docker daemon नहीं), लेयर्स को समतल करता है, और सीधे एक ext4 डिस्क लिखता है, बिना root और बिना loop devices के। एक ही इमेज से हर सैंडबॉक्स एक copy-on-write क्लोन है (APFS clonefile / FICLONE), इसलिए प्रति-सैंडबॉक्स डिस्क लागत वही है जो गेस्ट लिखता है।
नेटवर्क गेस्ट के नीचे फ़िल्टर किया जाता है। VM का पूरा L3 (gateway, DHCP, DNS, NAT) daemon प्रोसेस के अंदर एक userspace स्टैक है। हर आउटबाउंड कनेक्शन और DNS उत्तर वहाँ allow-list से परामर्श करता है, जहाँ गेस्ट के अंदर root भी इसे नहीं बदल सकता। कोई host iptables नहीं, कोई sudo नहीं।
अंदर जाने का एक ही रास्ता। कोई sshd नहीं, कोई cloud-init नहीं: एक एकल vsock एजेंट गेस्ट में नियंत्रण का एकमात्र रास्ता है, और हर attach container-exec-शैली का है: एक नई प्रक्रिया, डिस्कनेक्ट होने पर नष्ट कर दी जाती है।

पूरी तस्वीर (गेस्ट स्टैक, दोनों providers, frame-level नेटवर्किंग) ARCHITECTURE.md में है, और हर निर्णय के पीछे का तर्क DESIGN.md में है।

तुलना

कंटेनर और devcontainers। वे आपका kernel साझा करते हैं और आपकी फ़ाइलसिस्टम को deny rules घटाकर देखते हैं; एक kernel बग या गलत mount host को उजागर कर सकता है। Devcontainer सेटअप अक्सर host Docker socket को इमेज बनाने के लिए bind-mount करते हैं, जिससे कंटेनर को host daemon का नियंत्रण मिल जाता है; clawk इसके बजाय Docker को VM के अंदर रखता है। और लिखने के लिए कोई Dockerfile/devcontainer.json नहीं है: कोई भी OCI इमेज rootfs है।
OS-स्तरीय एजेंट सैंडबॉक्स। Anthropic के sandbox-runtime जैसे टूल आपकी वास्तविक मशीन पर process-level guardrails लागू करते हैं: हल्के नियमों के लिए बढ़िया, लेकिन एक policy गलती सब कुछ उजागर कर देती है (keychain सहित), और installs, background services, या nested hypervisor को सुरक्षित रूप से अनुमति देना मुश्किल है। clawk पूरे workload को एक अलग मशीन पर ले जाता है।
सामान्य-उद्देश्य VM प्रबंधक (जैसे Lima)। Lima आपको एक Linux VM देता है; clawk उसके ऊपर एक वर्कफ़्लो है: प्रति प्रोजेक्ट एक VM जिसमें repo माउंटेड होता है, एक एजेंट जुड़ा और प्रमाणित होता है, egress डिफ़ॉल्ट रूप से allow-listed और denials लॉग किए जाते हैं, एजेंट वार्तालाप destroys के बीच बने रहते हैं, और एक ticket मोड जो worktrees और PRs प्रबंधित करता है। (हुड के नीचे दोनों Virtualization.framework का उपयोग करते हैं।)
क्लाउड सैंडबॉक्स। Local-first: आपका कोड कभी मशीन नहीं छोड़ता, कुछ भी घंटे के हिसाब से बिल नहीं होता, और एजेंट जिस worktree को संपादित करता है वह आपके editor में वही है, macOS पर live-mounted (Linux provider वर्तमान में इसे create पर बेक करता है; Roadmap देखें)। क्लाउड सैंडबॉक्स fleets के लिए हैं; clawk आपकी डेस्क पर मशीन के लिए है।

सुरक्षा मॉडल (और इसकी सीमाएँ)

दो सीमाएँ काम करती हैं: VM (host फ़ाइलसिस्टम अदृश्य है सिवाय जो आप माउंट करते हैं) और आउटबाउंड allow-list (गेस्ट के नीचे userspace में लागू, हर प्रोटोकॉल के लिए जो इसे छोड़ सकता है)। clawk जिसके खिलाफ सुरक्षा नहीं करता:

जो आप माउंट या अनुमति देते हैं वह उजागर होता है। Worktrees लिखने योग्य हैं, इसलिए एक एजेंट बुरा कोड commit कर सकता है या किसी भी repo में push कर सकता है जिस तक आपका forwarded ssh-agent पहुँच सकता है। सैंडबॉक्स से जो निकलता है उसकी समीक्षा करें जैसे आप किसी अजनबी के PR की समीक्षा करते हैं।
जो secrets आप अंदर डालते हैं वे दिखाई देते हैं। files ( … ) और shares ( … ) सामग्री, forwarded env vars, और Claude token एजेंट के पढ़ने के लिए हैं (और, यदि कोई गंतव्य allow-listed है, तो वहाँ भेजने के लिए)। न्यूनतम साझा करें।
हाइपरवाइज़र escapes। clawk Virtualization.framework/KVM अलगाव पर निर्भर करता है; यह उनसे परे कोई सुरक्षा नहीं जोड़ता।

यदि आपको कोई सीमा तोड़ने का तरीका मिलता है (guest-to-host escape, network-filter bypass, credential leakage), तो कृपया इसे निजी तौर पर SECURITY.md के माध्यम से रिपोर्ट करें।

FAQ

ओवरहेड क्या है? किसी इमेज से पहला बूट एक बार का rootfs निर्माण (pull → flatten → ext4) चुकाता है। उसके बाद, डिस्क copy-on-write क्लोन होती हैं और kernel सीधे बूट होता है, बिना firmware और बिना installer के। निष्क्रिय VMs मेमोरी को ~1 GiB तक छोड़ देते हैं, 30 निष्क्रिय मिनटों के बाद स्वचालित रूप से रुक जाते हैं, और डिस्क पर snapshotted किए जा सकते हैं ताकि वे केवल storage की लागत लें।

क्या यह Intel Macs पर काम करता है? Windows? नहीं। macOS को Apple silicon (macOS 14+) चाहिए। Linux पर, firecracker provider काम करता है लेकिन प्रयोगात्मक है (docs/commands.md देखें)। Windows समर्थन नहीं है।

क्या मुझे Docker इंस्टॉल करने की आवश्यकता है? नहीं। clawk OCI इमेज खींचता है और बूट करने योग्य डिस्क खुद बनाता है। Docker इमेज इनपुट प्रारूप हैं; Docker engine शामिल नहीं है। (सैंडबॉक्स के अंदर Docker daemon चलाना एक अलग, opt-in सुविधा है; हार्डवेयर और kernel आवश्यकताओं के लिए Images देखें।)

"clawk" क्यों? निशान एक पंजा है; clawkwork A Clockwork Orange पर एक नाटक है। एक VM जिसे आप घुमाते हैं, छोड़ देते हैं, और हमेशा रीसेट कर सकते हैं।

Roadmap

आगे: आपके RAM की क्षमता से अधिक सैंडबॉक्स एक साथ चलाना।

Idle stops जो snapshot करते हैं। Manual suspend-to-disk clawk snapshot / clawk resume के रूप में भेजा गया; अगला, स्वचालित idle stop भी इसका उपयोग करता है, ताकि dev servers रुकने के बाद बचे रहें और एक suspended सैंडबॉक्स केवल डिस्क की लागत ले।
चल रहे VMs पर एक सीमा। जब RAM प्रतिबद्ध हो तो नया VM मना करने के बजाय, सबसे कम उपयोग किए गए सैंडबॉक्स को डिस्क पर suspend करें और नया शुरू करें।
Firecracker समानता। Linux पर live worktree प्रसार और host-file push।

स्थिति

Pre-1.0 और सक्रिय विकास के तहत, और तेज़ी से विकसित हो रहा है: रिलीज़ के बीच breaking changes की उम्मीद करें। CLI सतह सबसे कम बदलती है और आंतरिक सबसे अधिक, लेकिन 1.0 तक कुछ भी स्थिर नहीं है।

योगदान

Issues और PRs का स्वागत है। निर्माण और परीक्षण के लिए CONTRIBUTING.md देखें, यह कैसे बनाया गया है इसके लिए ARCHITECTURE.md, और यह कहाँ जा रहा है इसके लिए DESIGN.md देखें।

लाइसेंस

Apache License 2.0। clawk अपने स्वयं के लाइसेंस के तहत दो तृतीय-पक्ष घटकों को वेंडर करता है (gvisor-tap-vsock, Apache-2.0; एक hcsshim ext4 writer, MIT); NOTICE देखें।