Claude Code में अब Auto mode डिफ़ॉल्ट है
Claude Code में Anthropic के “auto mode” को डिफ़ॉल्ट बनाने का फैसला—जहाँ एक LLM-आधारित classifier ज़्यादातर commands को अपने-आप approve करता है—सुरक्षा, उपयोगिता और नियंत्रण पर बहस छेड़ रहा है। कई developers कहते हैं कि manual approvals से “permission fatigue” होती थी और auto mode खतरनाक commands को humans से अधिक भरोसेमंद तरीके से रोकता है, जबकि आलोचकों का तर्क है कि यह oversight कम करता है, जोखिम भरी आदतों को बढ़ावा देता है, और इसे हमेशा मज़बूत OS-level sandboxing या containers के साथ ही इस्तेमाल किया जाना चाहिए। इसके पीछे एक व्यापक तनाव है: क्या शक्तिशाली coding agents को user की machine पर खुलकर चलना चाहिए, या उन्हें सुविधा और गति की कीमत पर भी सख्ती से isolate और constrain किया जाना चाहिए।
Auto Mode बनाम Manual / YOLO Modes
- कई उपयोगकर्ता auto mode का स्वागत करते हैं, क्योंकि यह लगातार prompts के बजाय एक बेहतर default है; उनका कहना है कि manual approval जल्दी ही यांत्रिक “सब कुछ के लिए yes” बन जाता है।
- अन्य लोग नियंत्रण बनाए रखने, code style को shape करने, या बर्बाद हुए काम से बचने के लिए manual review पर ज़ोर देते हैं, भले ही वे कभी-कभी सिर्फ़ skim ही करें।
- एक बड़ा समूह
--dangerously-skip-permissions/“yolo” का अकेले उपयोग करता है, अक्सर अपनी isolation के साथ; उनका तर्क है कि guardrails system design से आने चाहिए (backups, VCS, sandboxing), न कि pop-ups से। - कई लोग इस बात पर ज़ोर देते हैं कि auto mode का classifier YOLO से अलग है: यह reported ~89% “dangerous” commands को रोकता है, जो Anthropic के study में औसत human testers से काफ़ी बेहतर है—but केवल उन risks के लिए जिन्हें यह पहचानने के लिए प्रशिक्षित है।
Sandboxing और Isolation Strategies
- मज़बूत सहमति: गंभीर उपयोगकर्ताओं को prompts या app-level permissions पर निर्भर रहने के बजाय agents को sandbox करना चाहिए।
- उल्लिखित approaches: Docker/Podman devcontainers, अलग Unix users, QEMU/Firecracker/Incus VMs, bubblewrap, macOS Seatbelt wrappers, Anthropic का अपना sandbox runtime और
/sandboxfeature, commercial/mac tools. - सामान्य pattern: केवल project workspace को read/write mount करें, sensitive directories (home, ssh keys, configs) को unreadable रखें, और git तथा deployments को sandbox के बाहर से चलाएँ।
- कुछ लोग अपनी पूरी machine को semi-disposable मानते हैं, लेकिन फिर भी backups और separate accounts रखते हैं।
Safety, Incidents, और Risk Perception
- रिपोर्ट की गई mishaps में lost git stashes और overwritten logs से लेकर private SSH keys तक पहुँचने की कोशिशें या docs में मिले production servers से connect करने की कोशिशें शामिल हैं।
- कई लोग YOLO या auto mode में “अब तक कोई incident नहीं” बताते हैं, लेकिन अन्य लोग कहते हैं कि इससे safety साबित नहीं होती—सिर्फ़ observed failure की अनुपस्थिति।
- चिंता local damage से आगे बढ़कर unintended external actions तक जाती है (APIs, Slack messages, AWS profiles, संभव prompt-injection–driven behavior)।
Permission Fatigue और UX Concerns
- उपयोगकर्ता शिकायत करते हैं कि agents बेहद complex bash commands और लगातार बदलती pipelines बनाते हैं, जिससे meaningful review या allowlisting अव्यवहारिक हो जाता है।
- कुछ लोग auto mode को उसी design द्वारा पैदा की गई समस्या का समाधान मानते हैं; अन्य permissions को वास्तविक OS-level enforcement के बिना largely “performative” कहते हैं।
- अनुरोधों में शामिल हैं: बेहतर per-project allow/deny lists, planned actions के higher-level summaries, persistent “never do X” rules, और कम verbose, अधिक predictable command patterns।
Trust, Business Motives, और Model Behavior
- कुछ लोग auto mode को code-naive users के लिए एक sensible default और एक अच्छा business move मानते हैं; अन्य लोग higher-token usage की ओर ले जाने वाले dark-pattern nudging पर शक करते हैं।
- server-side classifier changes के चुपचाप workflows तोड़ने और नए models में increasingly complex, over-engineered commands को लेकर भी निराशा है।