وبلاگ / راهنمای مسیر یادگیری و فناوری
راهنمای مسیر یادگیری و فناوری

GitHub Copilot CLI چیست؟ آموزش نصب، استفاده و تنظیم مجوزهای امن

راهنمای عملی GitHub Copilot CLI برای کار با عامل کدنویسی در ترمینال؛ نصب روی Windows، macOS و Linux، شروع امن، Plan Mode، مجوز ابزارها، دستورالعمل پروژه، تست و بازبینی تغییرات.

· ۲۹ بازدید

CLI یک عامل کدنویسی در خط فرمان است که می‌تواند مخزن را بررسی کند، درباره معماری پاسخ دهد، فایل‌ها را ویرایش کند، فرمان اجرا کند و نتیجه تست را تحلیل کند. تفاوت آن با تکمیل خودکار ساده این است که فقط یک خط پیشنهاد نمی‌دهد؛ برای یک هدف چندمرحله‌ای برنامه می‌ریزد و با ابزارهای ترمینال کار می‌کند.

همین توانایی، ارزش و ریسک را هم‌زمان بالا می‌برد. اگر ابزار از پوشه نامطمئن اجرا شود یا مجوز بیش از حد بگیرد، یک Prompt مبهم می‌تواند تغییر ناخواسته، اجرای فرمان خطرناک یا ارسال داده به سرویس خارجی ایجاد کند. در این راهنما نصب، شروع کار، Plan Mode، Custom Instructions، کنترل ابزارها و یک Workflow قابل بازبینی را قدم‌به‌قدم می‌بینید.

دقیقاً چه کارهایی انجام می‌دهد؟

  • ساختار Repository و فایل‌های مرتبط را برای پاسخ به سؤال بررسی می‌کند.
  • برای Feature یا Bug Fix برنامه مرحله‌ای می‌سازد.
  • فایل‌ها را با اجازه کاربر ایجاد یا ویرایش می‌کند.
  • فرمان‌های Build، Test، Lint و Git را پیشنهاد یا اجرا می‌کند.
  • Diff را توضیح می‌دهد و خطاهای تست را تحلیل می‌کند.
  • از Custom Instructions، Agentها، Skillها و MCP Serverها برای Context و ابزار بیشتر استفاده می‌کند.

خروجی مدل تضمین صحت نیست. نیز تأکید می‌کند فرمان پیشنهادی و تغییر فایل باید بازبینی شود. مسئولیت نهایی Merge، انتشار، Secretها و داده Production همچنان با تیم توسعه است.

با Copilot در IDE چه تفاوتی دارد؟

معیارCopilot در IDE
محیط اصلیترمینال و ShellEditor و فایل باز
نوع تعاملعامل چندمرحله‌ای و ابزارمحورChat، تکمیل کد و ویرایش
Context طبیعیRepository، فرمان‌ها، Log و Gitفایل‌ها، Selection و Workspace
ریسک عملیاتیاجرای Command و تغییر چند فایلبیشتر در محدوده Editor
کار مناسبتحقیق، Build، Test و Workflow مخزنکدنویسی روزمره داخل فایل
کنترل ضروریTrusted Directory و مجوز ابزاربازبینی Suggestion و Diff

این دو جایگزین کامل هم نیستند. CLI برای کارهای Repository-level و چرخه فرمان‌ها مفید است؛ IDE برای تغییر دقیق در فایل و مشاهده هم‌زمان کد مناسب‌تر است. انتخاب را بر اساس نوع کار انجام دهید.

پیش‌نیاز استفاده

  • یک حساب با Plan سازگار Copilot
  • فعال‌بودن سیاست در Organization، اگر حساب سازمانی است
  • Terminal استاندارد روی Windows، macOS یا Linux
  • یک Repository قابل اعتماد و Backup یا Git History سالم
  • دسترسی به Build و Test پروژه بدون Secret داخل Source Code

CLI را از Home Directory اجرا نکنید؛ آن پوشه معمولاً فایل‌های شخصی و Credentialهای بیشتری دارد. ابتدا وارد ریشه همان Repository شوید که واقعاً قصد بررسی آن را دارید.

نصب CLI

مستندات رسمی چند روش نصب ارائه می‌کند. فقط یک روش رسمی Package Manager سیستم، Update و Uninstall را قابل پیش‌بینی‌تر می‌کند.

install.shBash
# Windows with WinGetwinget install GitHub.Copilot # macOS or Linux with Homebrewbrew install --cask copilot-cli # Cross-platform with npmnpm_config_ignore_scripts=false npm install -g @github/copilot # Verify command availabilitycopilot --help
UTF-8Bash

فقط یکی از روش‌ها را انتخاب کنید. ترکیب نصب npm و WinGet ممکن است چند Executable با نسخه متفاوت در PATH بسازد. برای Update، همان Package Manager اولیه را به کار ببرید و قبل از استفاده در پروژه حساس، Release Notes را بخوانید.

اولین ورود و انتخاب Trusted Directory

  1. در Terminal وارد ریشه Repository شوید.
  2. فرمان copilot را اجرا کنید.
  3. در جلسه تعاملی /login را وارد و فرایند رسمی را کامل کنید.
  4. وقتی ابزار درباره اعتماد به پوشه می‌پرسد، مسیر را دقیق بخوانید.
  5. ابتدا یک سؤال فقط‌خواندنی درباره معماری یا فرمان‌های تست بپرسید.

اعتماد به Directory یعنی عامل ممکن است فایل‌های داخل آن و زیرپوشه‌ها را ببیند و با اجازه شما تغییر دهد. Repository دانلودشده از منبع ناشناس می‌تواند Script یا Instruction مخرب داشته باشد. قبل از Trust، محتوا، Git Remote و فایل‌های Instruction را بررسی کنید.

اول Plan، بعد Edit

Plan Mode کمک می‌کند عامل پیش از تغییر فایل، مسئله و مراحل را تحلیل کند. طبق مستندات ، در این حالت ویرایش مستقیم فایل‌های پروژه مسدود است و Plan برای بازبینی آماده می‌شود. می‌توانید با Shift+Tab حالت را تغییر دهید یا از /plan استفاده کنید.

prompt.txtPrompt
/plan Add rate limiting to the public login endpoint.Inspect the existing middleware and tests first.Do not change public API contracts.List security assumptions and rollback steps.Wait for approval before implementation.
UTF-8Prompt

Prompt خوب Outcome، محدوده، Constraint و معیار پذیرش را مشخص می‌کند. « را درست کن» مبهم است؛ «Rate Limit را فقط روی Login عمومی با تست 429 و بدون تغییر Contract اضافه کن» قابل بررسی است.

مجوز ابزارها؛ کمینه و موقت

برای خواندن، نوشتن، اجرای Shell و دسترسی URL ابزار دارد. عملیات تغییر‌دهنده معمولاً Approval می‌خواهند. گزینه‌های Allow و Deny را می‌توان برای جلسه تعیین کرد و Deny بر Allow اولویت دارد. مجوز گسترده سرعت را بالا می‌برد، اما دامنه خطا را نیز بزرگ می‌کند.

safe-session.shBash
# Allow git operations but always block pushingcopilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)' # Exclude web tools when the task needs only local codecopilot --excluded-tools='web_fetch,web_search' # Clear permissions granted during the session/reset-allowed-tools
UTF-8Bash

از --allow-all یا --yolo روی سیستم اصلی و Repository حساس استفاده نکنید. اگر یک Workflow واقعاً به مجوز وسیع نیاز دارد، آن را در Container، VM یا Sandbox محدود اجرا کنید. مجوز دائمی را فقط پس از شناخت دقیق Tool و Scope ذخیره کنید.

Sandbox چه کمکی می‌کند؟

Sandbox دامنه دسترسی فرمان‌های اجراشده را محدود می‌کند. در حالت محلی، پوشه کاری و Temp می‌توانند قابل نوشتن باشند و بخش‌های دیگر سیستم محدود شوند. Sandbox جای بازبینی نیست، اما لایه دفاعی مهمی است؛ به‌ویژه هنگام اجرای Test، Package Script یا Agent Autopilot.

  • Repository را به یک Workspace مشخص محدود کنید.
  • Secretهای Production را وارد محیط Agent نکنید.
  • شبکه را فقط برای Domainهای لازم باز کنید.
  • Mountهای نوشتنی را کمینه نگه دارید.
  • Git Push و ابزارهای Deployment را Deny کنید.
  • پس از پایان، Diff و فایل‌های جدید را خارج از Agent بررسی کنید.

دستورالعمل پروژه را یک‌بار، دقیق بنویسید

فایل .github/copilot-instructions.md Context ثابت Repository را به درخواست‌ها اضافه می‌کند. دستورها باید کوتاه، قابل اجرا و بدون تعارض باشند. معماری، فرمان Build و Test، محدودیت امنیتی و Definition of Done از بهترین محتواها هستند.

./copilot-instructions.mdMarkdown
# Repository instructions- Read existing tests before changing behavior.- Keep public API contracts backward compatible.- Never print, copy, or commit secrets.- Run: dotnet test --no-restore- Run: dotnet format --verify-no-changes- Summarize changed files, tests, and remaining risks.- Do not push, deploy, or alter production resources.
UTF-8Markdown

Docs می‌گوید علاوه بر فایل Repository-wide، از فایل‌های Path-specific، AGENTS.md و برخی فایل‌های Instruction دیگر پشتیبانی می‌کند. اگر چند فایل هم‌زمان اعمال شوند، دستورهای متناقض نتیجه را نامطمئن می‌کنند؛ مالکیت و Scope هر فایل را مستند کنید.

Workflow امن برای یک Bug Fix واقعی

  1. Baseline: وضعیت Git، Branch و تست‌های فعلی را ثبت کنید.
  2. Read-only discovery: از عامل بخواهید مسیر اجرای Bug و فایل‌های مرتبط را توضیح دهد.
  3. Plan: Plan Mode را فعال و معیار پذیرش را صریح کنید.
  4. Scope: فایل‌های مجاز و عملیات ممنوع مانند Push یا Migration را بنویسید.
  5. Implement: تغییر کوچک و مرحله‌ای بخواهید.
  6. Verify: تست هدفمند، سپس Suite مرتبط و Lint را اجرا کنید.
  7. Review: Diff را خط‌به‌خط بخوانید؛ فقط Summary مدل کافی نیست.
  8. Commit: Commit را پس از بازبینی انسان و با پیام روشن انجام دهید.

اگر تست از ابتدا Fail بوده، آن را با شکست جدید مخلوط نکنید. Baseline کمک می‌کند بدانید Agent چه چیزی را خراب کرده یا چه مسئله‌ای از قبل وجود داشته است. تغییر بزرگ را به چند Patch کوچک تقسیم کنید تا Rollback آسان بماند.

نمونه Promptهای بهتر

برای شناخت Repository

«فقط بخوان. مسیر Request از Controller تا Database را توضیح بده، پنج فایل کلیدی را نام ببر و هیچ فایل یا تنظیمی را تغییر نده.»

برای رفع خطا

«این Stack Trace در تست X دیده می‌شود. ابتدا علت را با شواهد پیدا کن، سه فرضیه را رتبه‌بندی کن، سپس کوچک‌ترین Fix را پیشنهاد بده. قبل از Edit منتظر تأیید بمان.»

برای بازبینی

«Diff فعلی را از نظر ، Race Condition، Breaking Change و پوشش تست بررسی کن. فقط یافته‌های دارای مسیر فایل و دلیل فنی را گزارش کن؛ تغییری اعمال نکن.»

Prompt دقیق تعداد رفت‌وبرگشت را کم می‌کند. نقش مبهم مانند «Senior Developer باش» به‌اندازه Context واقعی، فایل هدف، Constraint و Test Command مفید نیست.

MCP، Skill و Plugin را بی‌محابا اضافه نکنید

می‌تواند با MCP Serverها به سرویس‌های بیرونی دسترسی پیدا کند و MCP Server را به‌صورت داخلی دارد. هر Server تازه مجموعه Tool و داده جدیدی وارد مرز اعتماد می‌کند. قبل از اتصال، ناشر، Transport، Permission، داده ورودی و عملیات تغییر‌دهنده را بررسی کنید.

پرسشدلیلتصمیم امن
چه داده‌ای خوانده می‌شود؟ممکن است کد یا Ticket محرمانه باشدکمینه‌سازی Scope
آیا Tool می‌نویسد یا حذف می‌کند؟اثر خارجی و برگشت‌پذیری مهم استApproval موردی
Credential کجا ذخیره می‌شود؟Token بلندعمر هدف حمله استSecret Store و Rotation
Server مورد اعتماد است؟Tool Output می‌تواند آلوده باشدناشر رسمی و نسخه Pinشده
Log چه چیزی ثبت می‌کند؟احتمال نشت Prompt و SecretRedaction و Retention محدود

داده برگشتی از Web یا Issue نیز دستور معتبر کاربر نیست. Agent باید آن را به‌عنوان Context نامطمئن ببیند. اگر متن بیرونی درخواست اجرای فرمان یا افشای Secret کرد، توقف و بازبینی انسانی لازم است.

چه کارهایی را به نسپاریم؟

  • Push مستقیم به Branch محافظت‌شده
  • Deploy Production بدون Gate انسانی
  • Migration مخرب دیتابیس با داده واقعی
  • چرخاندن Secret، ساخت کلید یا تغییر Permission سازمانی
  • حذف انبوه فایل بدون Backup و فهرست دقیق
  • تصمیم معماری پرهزینه فقط بر اساس یک پاسخ
  • کپی‌کردن کد دارای License نامشخص
  • بازکردن Repository محرمانه با MCP یا URL غیرضروری

عامل برای تهیه Draft، تحقیق در Codebase، ساخت Test و اجرای Workflow تکراری عالی است؛ تصمیم‌های پرریسک باید Approval، Audit و Rollback مستقل داشته باشند.

چک‌لیست قبل از پذیرش تغییر

  • آیا Diff فقط فایل‌های مورد انتظار را تغییر داده است؟
  • آیا فایل Generated یا Lockfile ناخواسته اضافه نشده؟
  • آیا Secret، Token یا مسیر محلی وارد Commit نشده است؟
  • آیا Test جدید واقعاً قبل از Fix شکست می‌خورد؟
  • آیا همه تست‌های مرتبط و Lint عبور کرده‌اند؟
  • آیا API عمومی، Schema یا Migration تغییر کرده است؟
  • آیا Dependency جدید منبع و License معتبر دارد؟
  • آیا فرمان خطرناک یا Network Call در Script اضافه شده است؟
  • آیا Rollback مشخص و قابل اجراست؟
  • آیا انسان مسئول، نتیجه را مستقل از Summary مدل خوانده است؟

خطاهای رایج

شروع از پوشه Home

این کار دامنه Context و فایل‌های در معرض دسترسی را بزرگ می‌کند. همیشه از ریشه Repository مشخص و مورد اعتماد شروع کنید.

مجوز دائمی برای Shell

یک Allow کلی می‌تواند در همان Session برای فرمانی کاملاً متفاوت استفاده شود. مجوز را تا حد Subcommand محدود و Deny صریح برای Push یا حذف تعریف کنید.

اعتماد به تست تولیدشده توسط همان Agent

Agent ممکن است Test را طوری بنویسد که Implementation خودش را تأیید کند. معیار پذیرش را قبل از تغییر بنویسید و Edge Caseها را مستقل مرور کنید.

نادیده‌گرفتن فایل‌های Instruction

Repository می‌تواند فایل‌های Instruction داشته باشد که رفتار عامل را تغییر می‌دهد. قبل از Trust، آن‌ها را مانند Script اجراشونده بررسی کنید.

جمع‌بندی

CLI عامل کدنویسی را به محیطی می‌آورد که Build، Test، Git و Log در آن حاضرند. بیشترین ارزش زمانی ایجاد می‌شود که کار به مراحل روشن تقسیم شود: شناخت فقط‌خواندنی، Plan، Edit محدود، Test و Diff Review. بیشترین خطر نیز از Trusted Directory اشتباه، Permission گسترده و اتصال بی‌رویه Toolها می‌آید.

برای مقایسه یک عامل ترمینالی دیگر، راهنمای OpenCode و تنظیم مجوزهای امن را بخوانید. اگر می‌خواهید منطق Agent و Tool Use را در یک پروژه پایتون بفهمید، آموزش ساخت AI Agent امن با Python ادامه مناسبی است.

برای یادگیری عملی برنامه‌نویسی، Git و ابزارهای هوش مصنوعی در پروژه‌های واقعی، مسیرهای آموزشی خانه برنامه‌نویسان البرز را بررسی کنید.