GitHub Copilot App Local Sandbox: सेटअप और जाँच

आपने sandbox चालू किया, फिर भी current session पुराने permissions के साथ चल रहा है—या agent dependency install, local server और branch push के लिए बार-बार extra access माँग रहा है। आम तौर पर समस्या सिर्फ on/off switch में नहीं, बल्कि project default, session override और file, network तथा credentials की अलग सीमाओं में होती है।

इस guide के बाद आप local repository या working tree के लिए सही starting policy चुन सकेंगे, changes सही session में लागू कर सकेंगे और dummy data से verify कर सकेंगे कि restrictions सच में काम कर रही हैं। सबसे छोटा रास्ता है: session type जाँचें → Sandbox new sessions चालू करें → तीन permission areas सीमित करें → नया session शुरू या restart करें → safe checks चलाएँ।

GitHub ने यह feature 23 सितंबर 2026 को घोषित किया था और यह अभी public preview में है, इसलिए interface और behavior बदल सकते हैं। तीन boundaries याद रखें: local sandbox default रूप से बंद है, policy project-wise सेट होती है, और host requested policy enforce न कर सके तो sandboxed shell fail होता है—command बिना protection के चुपचाप नहीं चलता।

पहले जाँचें कि आपका session इस policy के दायरे में है

यह project policy केवल local repository और local working-tree sessions पर लागू होती है। Cloud sandbox, remote host और GitHub Copilot CLI अलग isolation या configuration इस्तेमाल करते हैं, इसलिए settings बदलने से पहले table से scope confirm करें।

Session का प्रकार	लागू होती है?	याद रखने वाली सीमा
Local repository session	हाँ	मौजूदा project की sandbox settings इस्तेमाल होती हैं
Local working-tree session	हाँ	Working tree branches और files अलग रखता है, पर machine के बाकी हिस्सों तक command की पहुँच नहीं रोकता; यह सीमा sandbox देता है
Cloud sandbox session	नहीं	Cloud session की अपनी isolation होती है
Remote host पर चलने वाला session	नहीं	Local project policy remote host पर लागू नहीं होती
GitHub Copilot CLI	अलग configuration	Copilot app और Copilot CLI की sandbox settings एक-दूसरे की जगह नहीं लेतीं

Enterprise-managed settings effective policy को project में माँगी गई policy से अधिक सख्त बना सकती हैं। इसलिए project page यह बताता है कि app क्या माँगता है, यह जरूरी नहीं कि organization उतनी अधिकतम पहुँच दे ही दे।

नए sessions के लिए sandbox कैसे चालू करें

आने वाले local sessions पर project policy लागू करने के लिए Sandbox new sessions चालू करके नया session शुरू करना जरूरी है; केवल switch बदलने से running session update नहीं होता। ये steps करें:

1. GitHub Copilot app settings खोलें।
2. वह project चुनें जिसे configure करना है।
3. Sandbox section खोलें।
4. Sandbox new sessions चालू करें।
5. नया local session शुरू करें।

यह switch केवल बाद में बने sessions पर लागू होता है। पहले से चल रहा session नहीं बदलता। Filesystem, network या credential policy में बाद के बदलाव भी नए session या session restart के बाद ही लागू होते हैं।

बातचीत का मौजूदा history रखते हुए policy दोबारा load करनी हो तो /restart-session चलाएँ।

GitHub अधिकतर projects के लिए default policy से शुरुआत करने की सलाह देता है। वह dependency install करने, local development server से जुड़ने, branch push करने और pull request बनाने जैसे सामान्य कामों को अनुमति देती है। Project के पास sensitive folders हों, network की जरूरत न हो या credentials इस्तेमाल नहीं होने चाहिए हों, तब policy को सख्त करें।

Files, network और credentials अलग-अलग कैसे सीमित करें

ये तीन independent controls हैं: files सीमित करने से credentials बंद नहीं होते, और credentials बंद करने से readable sensitive directory सुरक्षित नहीं होती। Task के अनुसार हर area को अलग tighten करें; सब कुछ एक साथ बंद न करें।

1. Filesystem: क्या पढ़ा और बदला जा सकता है

File access न्यूनतम रखें: workspace पर read/write रहने दें और अतिरिक्त paths तभी जोड़ें जब task को सच में उनकी जरूरत हो। Default रूप से sandboxed session workspace और current working directory पढ़-बदल सकता है; project settings में तीन lists मिलती हैं:

• Additional read/write: वे अतिरिक्त folders जिन्हें agent-run tools पढ़ और बदल सकते हैं।
• Additional read-only: वे अतिरिक्त folders जिन्हें पढ़ा जा सकता है, पर बदला नहीं जा सकता।
• Denied: वे folders जिन तक पहुँच पूरी तरह रोकी जाती है।

यदि कोई बड़ा parent folder allowed है, फिर भी उसके भीतर अधिक specific folder Denied में हो तो वह specific deny rule लागू रहता है। पूरे home directory को खोलकर बहुत सारे exceptions बनाने के बजाय केवल न्यूनतम जरूरी path दें।

Windows पर एक महत्वपूर्ण सीमा है। Denied path settings में save किया जा सकता है, लेकिन active Windows sandbox capabilities उस deny को guarantee न कर सकें तो command unsupported-policy प्रकार के message के साथ fail होगा। वह exposed path के साथ आगे नहीं चलेगा और sandbox अपने आप बंद नहीं होगा।

2. Network: internet और local network अलग रखें

Task को dependency install या local development server चाहिए तो दोनों network paths एक साथ बंद न करें; outbound internet और local network की जरूरत अलग-अलग तय करें। Default रूप से sandboxed session दोनों तक पहुँच सकता है, और आप नियंत्रित कर सकते हैं:

• Outbound internet: GitHub, package registries और अन्य internet services तक पहुँच।
• Local network: loopback तथा local-network connections, जिनमें local development servers शामिल हैं।

Network restriction dependency installation, API calls, preview servers और connection चाहने वाले दूसरे tools को प्रभावित कर सकती है। Network बंद करना बिना लागत वाला security switch नहीं है; पहले तय करें कि task को वास्तव में कौन-से connections चाहिए।

Linux पर एक documented सीमा है: sandbox spawned processes—जैसे shell commands, local MCP servers या LSP servers—के local-network access को अलग से नियंत्रित नहीं कर सकता। Setting in-process operations, जैसे web requests और remote MCP connections, पर फिर भी लागू होती है। Linux पर in-process और spawned-process दोनों paths जाँचें।

3. Credentials: Git और GitHub CLI अलग नियंत्रित करें

सिर्फ code review या offline analysis हो तो पहले Git और GitHub CLI credentials बंद करें; branch push या pull request बनाना हो तभी खोलें। Default रूप से authenticated operations sandbox में उपलब्ध होते हैं, और आप बंद कर सकते हैं:

• Git credentials: authenticated HTTPS Git operations के लिए।
• GitHub CLI credentials: GitHub CLI authentication के लिए।

इन्हें बंद करने पर branch push या pull request बनाने जैसे काम sandbox के भीतर रुक सकते हैं। Filesystem policy और credential policy अलग सीमाएँ हैं: credentials बंद होने पर भी keys, configuration और sensitive data वाले folders को filesystem rules से सुरक्षित रखें।

Project, current session या एक operation कब बदलें

Future sessions को rule inherit कराना हो तो project settings बदलें; current session के लिए /sandbox on या /sandbox off इस्तेमाल करें; project policy बदलने के बाद active session में /restart-session चलाएँ।

Action	कब लागू होता है	दूसरे sessions पर असर
Project की Sandbox settings बदलना	नए या restarted session में	बाद के sessions द्वारा inherit किया गया default बदलता है
Active local session में /sandbox on	तुरंत, और उस session के लिए persistent override बनता है	दूसरे sessions का project default नहीं बदलता
Active local session में /sandbox off	उसी session में तुरंत sandbox बंद करता है	दूसरे sessions नहीं बदलते; commands को user account जितनी file, network और credential access मिलती है
Session शुरू होने से पहले /sandbox on या /sandbox off	नए sessions द्वारा inherit किया गया project default बदलता है	बाद में शुरू होने वाले sessions प्रभावित होते हैं
/restart-session	Current session restart करता है, history रखता है और policy reload करता है	Project policy खुद नहीं बदलता

किसी tool को policy से बाहर access चाहिए तो app Run outside the sandbox? दिखा सकता है। Effective policy के अनुसार आप operation cancel कर सकते हैं, उसे एक बार sandbox के बाहर चला सकते हैं, या बाकी current session के लिए sandbox बंद कर सकते हैं। Enterprise owner बाहर चलाने की अनुमति रोक सकता है।

इस prompt से sandbox बंद करने पर project default या existing session override rewrite नहीं होता। Temporary state session restart या reattach होने पर खत्म हो जाता है। Sandbox off for this session दिखने के बाद Re-enable sandbox से इसे फिर चालू किया जा सकता है।

सुरक्षित क्रम यह है: पहले cancel करें और समझें कि command को ज्यादा access क्यों चाहिए। Access बार-बार चाहिए तो project policy को सीमित रूप में बदलकर restart करें। Command, arguments और impact review करने के बाद ही one-time run outside sandbox चुनें। अनजान repository या Prompt से dynamically बने command के लिए convenience के कारण पूरा session un-sandbox न करें।

Host policy लागू न कर सके तो command रुकता है

Operating system requested rule enforce न कर सके तो safe result command failure है, automatic unsandboxed execution नहीं।

GitHub Copilot app settings को उस समय accept कर लेता है जब वह अभी नहीं जानता कि operating system पूरी policy enforce कर पाएगा या नहीं। Support check पहले sandboxed shell के शुरू होने पर होता है।

Host policy लागू न कर सके तो:

• Shell unsupported-platform या unsupported-policy message देता है।
• Command बिना sandbox के आगे नहीं चलता।
• App Sandbox unavailable दिखाए तो बताई गई समस्या ठीक करके Retry sandbox चुनें।

यह fail-closed behavior है, best-effort execution नहीं। Settings save हो जाना यह साबित नहीं करता कि policy current machine पर active है। कम-से-कम एक sandboxed shell शुरू करें, unsupported message न होने की पुष्टि करें और छोटी verification चलाएँ।

Dummy data से policy कैसे verify करें

GitHub expected policy behavior बताता है, लेकिन आपके operating system और चुनी policy का combination काम करता है या नहीं, यह local check से ही पता चलेगा। नीचे disposable folders और dummy files इस्तेमाल होते हैं, इसलिए real keys या production configuration छूने की जरूरत नहीं है।

Workspace के बाहर disposable test folders बनाएँ और उनमें केवल dummy files रखें। असली SSH keys, cloud credentials या production configuration का उपयोग न करें।

Check	सुरक्षित तरीका	Policy से अपेक्षित behavior
New-session inheritance	Sandbox new sessions चालू करके नया local session बनाएँ	नया session project policy लेता है; पुराना session अपने आप नहीं बदलता
Policy edit लागू करना	एक rule बदलकर /restart-session चलाएँ	Session history रखते हुए restart और policy reload करता है
Read-only folder	Disposable folder को Additional read-only में जोड़ें, dummy file पढ़ें और test file बनाने की कोशिश करें	Read होना चाहिए; modification block होना चाहिए
Denied folder	दूसरा disposable folder Denied में जोड़कर dummy file list या read करें	Access block होना चाहिए, भले बड़ा parent path allowed हो
Internet	Outbound internet बंद करके harmless connection check करें	External connection fail होना चाहिए; फिर switch चालू करके तुलना करें
Local network	Local network बंद करके disposable local test service से जुड़ें	Platform capabilities के अनुसार access सीमित होना चाहिए; Linux spawned-process सीमा ध्यान रखें
Git credentials	Git credentials बंद करके test repository में non-mutating authentication check करें	Authenticated HTTPS Git operations उपलब्ध न भी हों
GitHub CLI credentials	GitHub CLI credentials बंद करके gh auth status जैसा non-mutating check करें	GitHub CLI को पिछली authentication capability नहीं मिलनी चाहिए; exact error बदल सकता है
Fail-closed	unsupported-platform या unsupported-policy आने पर देखें कि target dummy file नहीं बनी	Command unsandboxed आगे नहीं चलना चाहिए और intended side effect नहीं होना चाहिए

जाँच के बाद test folders हटाएँ और project को केवल जरूरी न्यूनतम permissions दें। Deny rule साबित करने के लिए असली sensitive directory access करने की कोशिश न करें।

आपकी task के लिए कौन-सी starting policy सही है

Everyday development, unknown repository और offline analysis को एक policy नहीं मिलनी चाहिए। Normal work के लिए जरूरी capabilities रखें, unfamiliar code के लिए strict शुरू करें और offline work में पहले network तथा credentials बंद करें।

रोजमर्रा development

Sandbox चालू रखें, default network और credential capabilities रखें, केवल जरूरी external folders allow करें और पास के sensitive folders explicitly deny करें। यह dependencies install करने, local services चलाने, branches push करने और pull requests खोलने वाले सामान्य काम के लिए उपयुक्त है।

अनजान repository की review

केवल workspace को read/write दें, extra reference material read-only रखें, Git और GitHub CLI credentials default रूप से बंद करें और dependencies कहाँ से आती हैं, यह समझने तक outbound internet बंद रखें। Temporary access चाहिए तो तुरंत /sandbox off करने के बजाय एक specific capability खोलें।

Local offline analysis

Outbound internet और अनावश्यक credentials बंद रखें, केवल जरूरी file access दें। Local-network isolation भी जरूरी हो तो Linux पर spawned-process behavior अलग जाँचें; एक UI switch से हर process पर बिल्कुल एक जैसा नियंत्रण मान लेना ठीक नहीं।

ये GitHub द्वारा नामित presets नहीं हैं। ये GitHub द्वारा उपलब्ध permission dimensions से बनाए गए starting points हैं। Final policy repository, operating system, enterprise rules और actual task से मेल खानी चाहिए।

वे गलतियाँ जो policy को बेअसर या बहुत broad बनाती हैं

सबसे आम गलती “settings saved” को “policy enforced” मानना या पहले denial पर पूरा sandbox बंद करना है। नीचे की सात स्थितियाँ test को गलत या permissions को जरूरत से ज्यादा broad कर देती हैं।

1. Working tree को security boundary मानना। वह concurrent branches और files अलग करता है, machine के बाकी paths तक command access नहीं रोकता।
2. Policy बदलकर पुराने session में test जारी रखना। Changes retroactive नहीं हैं; नया session बनाएँ या /restart-session चलाएँ।
3. App और CLI को एक sandbox मानना। दोनों अलग configure होते हैं।
4. Successful save को host support का proof मानना। Support check पहले sandboxed shell के शुरू होने पर होता है।
5. /sandbox off का असर भूलना। Agent-run commands को user account जितनी access मिल जाती है।
6. हर platform पर network behavior समान मानना। Linux spawned processes के local network पर documented सीमा है।
7. Access denial पर broad bypass करना। जरूरत confirm करके minimum policy change और restart सामान्यतः अधिक सुरक्षित है।

अब आपको क्या करना चाहिए

पहले confirm करें कि आप local repository या local working-tree session में हैं, फिर Sandbox new sessions चालू करें। Everyday development में default policy से शुरू करके सिर्फ जरूरी directories, network और credentials रखें; unfamiliar repository या offline analysis में strict profile से शुरू करें और एक-एक capability जोड़ें।

Project policy बदलने के बाद नया session बनाएँ या /restart-session चलाएँ, फिर disposable data पर read-only, denied, network और credential boundaries जाँचें। unsupported-platform, unsupported-policy या Sandbox unavailable आए तो compatibility issue ठीक करें; /sandbox off से चला result sandbox verification नहीं है।

आधिकारिक संदर्भ

Configuration से पहले और बाद में current interface, scope और failure behavior इन GitHub pages पर जाँचें।

• Configuring local sandboxing in the GitHub Copilot app
• Local sandboxing in the GitHub Copilot app — GitHub Changelog, September 23, 2026