Copilot में फ़ाइल छिपाई? App और CLI अब मानेंगे, पर दो रास्ते बाकी

GitHub ने 2 सितंबर 2026 को GitHub Copilot app और Copilot CLI में सामग्री-बहिष्करण नीतियों का पालन सामान्य रूप से उपलब्ध कर दिया। GitHub की रिलीज घोषणा के मुताबिक, दोनों ग्राहक अब उद्यम, संगठन और रिपॉज़िटरी प्रशासकों की तय नीतियाँ मानते हैं; यह सुविधा Copilot Business और Copilot Enterprise ग्राहकों के लिए है।

इस बदलाव के बाद बहिष्कृत फ़ाइल को app या CLI सत्र में प्रत्यक्ष संदर्भ के रूप में इस्तेमाल नहीं किया जाना चाहिए। हालांकि, GitHub की सामग्री-बहिष्करण दस्तावेज़ीकरण के अनुसार यह नियंत्रण सिमलिंक और दूरस्थ फ़ाइल तंत्र वाली रिपॉज़िटरी पर लागू नहीं होता; कुछ संपादकों के Edit और Agent मोड भी असमर्थित हैं तथा IDE से मिली अप्रत्यक्ष अर्थ-सूचना इस्तेमाल हो सकती है।

App और CLI में क्या बदला

यह किसी स्थानीय अनदेखी-सूची की शुरुआत नहीं है। बदलाव का आशय यह है कि GitHub Copilot app और Copilot CLI अब पहले से प्रशासित सामग्री-बहिष्करण नीति प्राप्त करके उसे अपने संदर्भ-चयन में लागू करते हैं। नीति रिपॉज़िटरी, संगठन या उद्यम स्तर पर निर्धारित हो सकती है, इसलिए उसका प्रभाव नीति बनाने वाले स्तर और उपयोगकर्ता को मिली Copilot सीट पर निर्भर करता है।

बहिष्करण के अंतर्गत प्रभावित फ़ाइल में इनलाइन सुझाव उपलब्ध नहीं होने चाहिए। उस फ़ाइल का पाठ दूसरी फ़ाइलों के सुझावों या Copilot के उत्तरों को सूचित नहीं करना चाहिए और वह Copilot कोड समीक्षा में शामिल नहीं होनी चाहिए। नई रिलीज का खास महत्व यह है कि app और टर्मिनल में चलने वाला CLI भी अब इसी प्रशासनिक सीमा के भीतर आ गया है।

सामान्य उपलब्धता का दर्जा केवल घोषणा में नामित app और CLI के लिए है। इससे हर Copilot सतह को समान समर्थन नहीं मिल जाता: GitHub वेबसाइट और GitHub Mobile पर सामग्री-बहिष्करण अभी सार्वजनिक पूर्वावलोकन में है, जबकि संपादक के कुछ कार्यप्रवाह अलग अपवाद बने हुए हैं। इसलिए एक ही रिपॉज़िटरी पर अलग ग्राहकों के परिणाम समान मानना ठीक नहीं होगा।

सिमलिंक और दूरस्थ संग्रह क्यों अलग जोखिम हैं

पहला बचा रास्ता सिमलिंक है। यदि बहिष्कृत स्थान की सामग्री किसी प्रतीकात्मक कड़ी के जरिये उपलब्ध है, तो मूल पथ पर लागू नियम को उस वैकल्पिक प्रवेश पर प्रभावी मानने का आधार नहीं है। नाम या पथ बदलने के बाद भी लक्ष्य फ़ाइल वही हो सकती है, लेकिन प्रकाशित सीमा के अनुसार सामग्री-बहिष्करण उस कड़ी को अपने दायरे में नहीं लेता।

दूसरा रास्ता दूरस्थ फ़ाइल तंत्र है। नेटवर्क माउंट या किसी अन्य दूरस्थ फ़ाइल तंत्र में रखी रिपॉज़िटरी इस नियंत्रण के दायरे से बाहर है। स्थानीय रिपॉज़िटरी में सफल जाँच इसलिए दूरस्थ रूप से खोली गई उसी परियोजना के व्यवहार का प्रमाण नहीं बनती।

इन अपवादों के कारण सामग्री-बहिष्करण को फ़ाइल-अनुमति, रहस्य प्रबंधन या उपकरण तक पहुँच रोकने का विकल्प नहीं माना जा सकता। यह तय करता है कि समर्थित Copilot ग्राहक किसी पथ को संदर्भ में ले या नहीं; यह उपयोगकर्ता, मशीन अथवा प्रक्रिया की मूल फ़ाइल तक पहुँच समाप्त नहीं करता। जिस गोपनीय सामग्री की कार्यस्थान में आवश्यकता नहीं है, उसे मूल पहुँच-नियंत्रण से अलग रखना अब भी जरूरी है।

संपादक मोड और अप्रत्यक्ष जानकारी की सीमा

Visual Studio Code और अन्य संपादकों में Copilot Chat के Edit तथा Agent मोड फिलहाल सामग्री-बहिष्करण का समर्थन नहीं करते। ये GitHub Copilot app और Copilot CLI से अलग उत्पाद-सतहें हैं। लिहाजा CLI में बहिष्कृत फ़ाइल न मिलने का परिणाम उसी रिपॉज़िटरी पर संपादक के Agent मोड की सुरक्षा साबित नहीं करता।

दूसरी सीमा प्रत्यक्ष फ़ाइल-पाठ और उससे निकली अर्थ-सूचना के बीच है। IDE किसी बहिष्कृत फ़ाइल से जुड़ी प्रकार-सूचना, कोड में प्रयुक्त प्रतीकों की होवर परिभाषाएँ या परियोजना की बिल्ड संरचना Copilot को अप्रत्यक्ष रूप से दे सकता है। ऐसी स्थिति में मूल फ़ाइल संदर्भ में न आने पर भी उससे संबंधित संकेत उत्तर को प्रभावित कर सकते हैं।

इसलिए सटीक सुरक्षा दावा सीमित होना चाहिए: किसी खास ग्राहक और मोड ने जाँच के दौरान बहिष्कृत पथ का प्रत्यक्ष पाठ इस्तेमाल नहीं किया। इससे यह व्यापक निष्कर्ष नहीं निकलता कि Copilot उस घटक के बारे में कोई जानकारी प्राप्त नहीं कर सकता। प्रकारों, प्रतीकों और परियोजना विन्यास से मिलने वाले संकेतों को अलग जोखिम मानना होगा।

सीमा की जाँच में दोनों परिणाम जरूरी हैं

जाँच के लिए वास्तविक ग्राहक आँकड़े या उत्पादन रहस्य इस्तेमाल करने की जरूरत नहीं है। BaristaLabs की स्वतंत्र समीक्षा एक बहिष्कृत कृत्रिम फ़ाइल और पास की अनुमत फ़ाइल में अलग निरर्थक पहचान-चिह्न रखकर प्रत्येक स्वीकृत Copilot सतह पर समान प्रश्न चलाने की पद्धति सुझाती है। समीक्षा साफ करती है कि यह संचालन-संबंधी जाँच है, GitHub की प्रमाणन प्रक्रिया नहीं।

1. उत्पादन नीति वाले पथ-नियम से मेल खाती कृत्रिम फ़ाइल बनाएँ और उसमें कोई असली रहस्य न रखें।
2. उस फ़ाइल में एक निरर्थक पहचान-चिह्न तथा पास की अनुमत फ़ाइल में दूसरा चिह्न रखें। बहिष्कृत चिह्न उत्तर में नहीं आना चाहिए, जबकि अनुमत चिह्न उपलब्ध रहना चाहिए।
3. GitHub Copilot app और Copilot CLI के परिणाम अलग दर्ज करें। दल जिस संपादक और मोड का उपयोग करता है, उसकी भी अलग जाँच करें।
4. सिमलिंक और दूरस्थ रिपॉज़िटरी को स्थानीय पथ की सफलता में शामिल न करें, क्योंकि वे घोषित अपवाद हैं।
5. कृत्रिम प्रकार, प्रतीक या बिल्ड गुण रखकर देखें कि मूल पाठ के बिना भी उनसे जुड़ी जानकारी उत्तर को प्रभावित करती है या नहीं।

बहिष्कृत और अनुमत दोनों फ़ाइलों का परिणाम साथ रखना जरूरी है। केवल बहिष्कृत पहचान-चिह्न न मिलने से यह भी संभव है कि ग्राहक को रिपॉज़िटरी का कोई संदर्भ ही न मिला हो। अनुमत फ़ाइल का सही परिणाम दिखाता है कि ग्राहक ने संदर्भ प्राप्त किया और नीति ने अपेक्षित सीमा पर उसे रोका।

रिकॉर्ड में योजना, नीति का स्तर, रिपॉज़िटरी, सटीक पथ-पैटर्न, ग्राहक और उसका संस्करण, संपादक मोड, अपेक्षित परिणाम तथा देखा गया परिणाम शामिल होना चाहिए। किसी एक CLI विन्यास की सफलता app, IDE Agent मोड, दूसरी रिपॉज़िटरी या दूरस्थ फ़ाइल तंत्र पर अपने-आप लागू नहीं होती।

अभी समर्थन की सीमा यहीं है

पुष्ट स्थिति यह है कि Copilot Business और Copilot Enterprise के लिए GitHub Copilot app तथा Copilot CLI प्रशासक-निर्धारित सामग्री-बहिष्करण नीतियाँ मानते हैं। फिर भी सिमलिंक और दूरस्थ फ़ाइल तंत्र दो खुले फ़ाइल-रास्ते हैं; असमर्थित संपादक मोड और अप्रत्यक्ष अर्थ-सूचना इस नियंत्रण को सार्वभौमिक गोपनीयता-सीमा बनने से रोकते हैं।

GitHub ने इन अपवादों के लिए कोई सार्वजनिक समय-सारणी नहीं दी है। आगे स्थिति तभी बदलेगी जब समर्थन-सारणी में सिमलिंक, दूरस्थ रिपॉज़िटरी या Edit और Agent मोड का दर्जा बदले; तब तक किसी संगठन की वास्तविक सीमा उसके इस्तेमाल किए गए ग्राहक, मोड और फ़ाइल तंत्र के अनुसार ही तय होगी।

यह भी पढ़ें:

• Claude Code या GitHub Copilot: टर्मिनल, संपादक और बड़े कोडबेस के लिए क्या चुनें
• Copilot AI: Windows 11 में कुंजी बंद और रीमैप करने का नया विकल्प
• ONDC पर दुकान जोड़ें—Seller App चुनने के बाद भी काम बाकी है