--- title: Workflow & CLI description: Run single actions from GitHub Actions workflows and from the Copilot CLI. --- # Workflow & CLI You can run single actions in two ways: from a **GitHub Actions workflow** (for example, a scheduled job or manual trigger) or from the **`copilot` CLI** locally. ## Recommended: initialize with the CLI For a new repository, install the published package globally with `pnpm` and let `copilot setup` initialize the repository. This is the supported onboarding path: ```bash pnpm add --global @vypdev/copilot copilot --version cd /path/to/your/repository copilot setup ``` The wizard copies the selected workflows and templates, creates the required labels and issue types, and configures the Variables and Secrets required by the selected features. Use `copilot setup --dry-run` to review the plan first. See [How to use](/how-to-use) for the setup PAT, workflow PAT, and scope details. ## Manual: run the Action from a GitHub Actions workflow Add a job that sets `single-action` and any required inputs (`single-action-issue`, `single-action-version`, etc.): ```yaml jobs: run-check-progress: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 with: persist-credentials: false - uses: vypdev/copilot@v3 with: token: ${{ secrets.PAT }} single-action: check_progress_action single-action-issue: '123' ``` Use `workflow_dispatch` to run on demand, or trigger the workflow from another event. See [Single Actions Configuration](/single-actions/configuration) for the workflow inputs. ## Install or update the CLI The published package is `@vypdev/copilot` and exposes one global executable: **`copilot`**. Install it with pnpm, then run repository-dependent commands from the target repository. ### Install the published package ```bash pnpm add --global @vypdev/copilot copilot --version ``` The package requires Node.js 24 or newer. The npm scope does not change the executable name: the command remains `copilot`. ### Install from a checkout Use a repository checkout when testing unreleased changes or developing Copilot: ```bash git clone https://github.com/vypdev/copilot.git cd copilot corepack pnpm install . --global ``` The repository includes the generated `build/` directory. If you are installing from a checkout where `build/` is missing, build it first: ```bash corepack pnpm install corepack pnpm run build corepack pnpm install . --global --force ``` ### Update the global pnpm installation Update to the latest published version with: ```bash copilot upgrade copilot --version ``` Run `copilot upgrade` from any directory. It updates the published pnpm installation and does not require a target repository or GitHub token. If the installed version does not include this command, run `pnpm add --global @vypdev/copilot@latest` once. You can also update it directly with `pnpm update --global @vypdev/copilot`. Normal Copilot CLI commands also perform a lightweight update check against npm. It is informational only: the result is cached locally for 24 hours, the network request has a short timeout, and failures are ignored so the command continues normally. When a newer release is found, the CLI prints `A new version (x.y.z) is available. Run "copilot upgrade".` The check is skipped for `copilot upgrade`, `--version`, and help. Set `COPILOT_DISABLE_UPDATE_CHECK=1` to opt out. Verify the installed package and executable: ```bash command -v copilot copilot --version pnpm list --global --depth 0 @vypdev/copilot ``` ### Reinstall or update from a checkout Pull the version you want into the Copilot checkout, then reinstall the local package globally: ```bash cd /path/to/copilot git pull --ff-only origin master corepack pnpm install . --global --force ``` Verify that the executable is on `PATH` and that the installed package is the expected one: ```bash command -v copilot copilot --help copilot --version corepack pnpm list --global --depth 0 @vypdev/copilot ``` If the command is not found after installation, configure pnpm's global bin directory in your shell's `PATH` and open a new shell. Run `pnpm bin --global` or consult `pnpm setup` to locate the global executable directory when configuring `PATH`. ## Local CLI prerequisites Run repository-dependent commands from the **root of the target repository**, not necessarily from the Copilot checkout. `copilot upgrade`, `copilot --version`, and help can run from any directory. The target repository must: - be a Git worktree; - have an `origin` remote pointing to a GitHub repository; - have `PERSONAL_ACCESS_TOKEN` available through the environment, or pass `--token` to commands that support it; - have the selected agent runtime and credentials configured for AI commands. For local use, prefer the hidden prompt or an environment variable instead of putting a token in shell history. `copilot setup` and `copilot doctor` prompt for the setup PAT; other commands accept `-t, --token` or `PERSONAL_ACCESS_TOKEN`. `copilot do` does not use a GitHub PAT option and reads the configured agent environment instead. See [Authentication](/authentication) and [Agent CLI configuration](/agents/cli-configuration). ## Human-readable result output Repository-aware single actions render one semantic outcome in the configured `repository-locale`, which defaults to English. The terminal reports the status (`Succeeded`, `Partially completed`, `Failed`, or `No changes`) and bounded counts for completed, skipped, and failed operations. Semantic answers and errors are expanded because they help the operator decide what to do next. Internal `Result.steps` and reminder prose are not replayed into the terminal: they are operational evidence and may contain implementation-oriented English that would make localized output misleading. The terminal reports only the number of recorded operator reminders; use debug logs or structured results when that evidence is required. Error codes and references remain stable in every locale, and raw provider messages are never shown. ## Command reference All commands support `-h, --help`. The `-d, --debug` option enables additional diagnostics where listed below. ### `copilot setup` Initializes the current GitHub repository through an interactive English-language wizard. It can select the workflows and templates to install, route each Copilot task to Codex, OpenCode, or Cursor, configure repository behavior and AI policy, inspect and provision GitHub Actions Variables and Secrets at repository or organization scope, verify access, and create the configured labels and issue types. If the repository has no version tags, setup asks whether it should create `v1.0.0`. Setup is the profile-creation surface, so its questionnaire, plan, confirmation, and embedded readiness checks stay in authoritative English until the repository configuration is installed. The selected `repository-locale` governs subsequent repository-aware output, including `copilot doctor`; issue and pull-request overrides do not change setup or doctor language. | Option | Required | Description | | --- | --- | --- | | `-t, --token ` | No | Setup PAT override. Otherwise uses the hidden prompt interactively or `PERSONAL_ACCESS_TOKEN` from the environment. | | `-d, --debug` | No | Enables debug logging. | | `--agent ` | No | Preselect one runtime for every task: `codex`, `opencode`, or `cursor`. | | `--features ` | No | Preselect a comma-separated feature list, or `all`. Feature names are listed below. | | `--issue-workflows ` | No | Preselect enabled issue workflow kinds (`feature`, `bugfix`, `documentation`, `chore`, `help`, `hotfix`, `release`) or `all`. The interactive wizard offers the same list with Space/Enter multi-select. | | `--agent-guidance ` | No | Control generated repository guidance: `prompt` (interactive default or explicit pointer authorization), `create-if-missing`, or `disabled`. Unattended setup defaults safely to `create-if-missing`. | | `--config ` | No | Load non-secret YAML/JSON setup overrides. Interactive answers can still refine them. | | `--non-interactive` | No | Use defaults, flags, config-file values, and explicit credentials without creating a terminal or prompting. | | `--yes` | No | Approve only the final plan; it does not fill missing configuration or credentials. | | `--confirm-unverifiable-write-permissions` | No | Explicitly acknowledge, after inspecting the PAT settings, required write rows that safe read-only probes cannot verify. It never accepts missing access or unverifiable required reads. | | `--dry-run` | No | Print the complete plan without changing files or GitHub. A token is not required. | | `--skip-variables` | No | Copy files and provision metadata without changing Repository Variables. | | `--skip-secrets` | No | Do not validate or create/update repository Secrets. | | `--variables-scope ` | No | Default scope for Variables: `repository` or `organization`. | | `--secrets-scope ` | No | Default scope for Secrets: `repository` or `organization`. | | `--variables-visibility ` | No | Organization Variable visibility: `selected`, `private`, or `all`. | | `--secrets-visibility ` | No | Organization Secret visibility: `selected`, `private`, or `all`. | | `--variable-scope ` | No | Repeat to mix repository and organization scopes per Variable. | | `--secret-scope ` | No | Repeat to mix repository and organization scopes per Secret. | | `--update-workflows` | No | Approve updates to changed setup workflows already present in the repository. | | `--workflow-pat ` | No | Workflow PAT for non-interactive setup; prefer the hidden prompt. | | `--secret ` | No | Repeat for provider credentials in non-interactive setup; values can appear in shell history. | ```bash copilot setup ``` Run it from the target repository root. Existing setup files are not overwritten unless you approve the update prompt or pass `--update-workflows`. The interactive flow installs the selected workflows/templates, asks for agent routing and operational settings, inspects the repository's effective Actions resources, and asks separately where Secrets and Variables should live. Organization scope requires an organization-owned repository and the corresponding organization permissions on the setup PAT. Existing repository resources take precedence over organization resources; setup preserves an inherited organization resource unless you explicitly request a repository override. The questionnaire is forward-only and immutable. Its stable stages are capabilities, issue workflow multi-select, agent runtime, model defaults, optional role overrides, repository, deployment, Bugbot, optional Projects, provisioning, storage, review, and confirmation. The issue workflow selector uses the usual `Space` to toggle and `Enter` to confirm; `All` is selected by default. `Ctrl-C` or end-of-input closes the prompt once, exits 130, and writes nothing. Declining the final plan exits 0 and also writes nothing; rerun setup or edit the config file to change earlier answers. The wizard covers these features: `issues`, `pullRequests`, `commits`, `issueComments`, `pullRequestComments`, `release`, `hotfix`, `agentProvisioning`, `credentialHealth`, `inactiveIssueClosure`, `issueTemplates`, and `pullRequestTemplate`. It also asks whether to generate repository agent guidance; this is enabled by default. The agent tasks are `planner`, `findings`, `reviewer`, `fixer`, and `tester`; each can use any of the three supported runtimes independently. Model provider, model, effort, branch strategy, locales, AI ignore patterns, project columns, Bugbot policy, provisioning mode, and initial-tag creation are also configurable. Cursor is available as an experimental runtime and is called out in the review plan with its extra credential/checksum requirements. For automation, use the same defaults without prompts: ```bash copilot setup --non-interactive --yes copilot setup --dry-run copilot setup --non-interactive --yes --features issues,pullRequests,commits,issueComments,pullRequestComments --agent codex copilot setup --non-interactive --yes --issue-workflows feature,bugfix,help ``` Run these commands without a permission exception first. If the audit stops only because required write rows are `Unverifiable`, inspect the displayed requirements against both PATs' settings. Only after confirming every required row may you explicitly acknowledge that limitation. Repeat the same selections if the original run was interactive; for automation, append the flag to the original invocation with the same configuration file, flags, and credentials. For example, preserving the feature and agent flags from the command above: ```bash copilot setup --non-interactive --yes --features issues,pullRequests,commits,issueComments,pullRequestComments --agent codex --confirm-unverifiable-write-permissions ``` Without an explicit `--agent-guidance` or config value, non-interactive setup still generates the profile, guide, and skill, but it uses `create-if-missing`: an existing root `AGENTS.md` is not edited. Pass `--agent-guidance prompt` (and approve the final plan) to authorize the bounded marker insertion in unattended setup. For unattended credential provisioning, keep the setup PAT in a protected CI secret and pass credential values explicitly (never commit them): ```bash copilot setup --non-interactive --yes --update-workflows \ --token "$SETUP_PAT" \ --workflow-pat "$WORKFLOW_PAT" \ --secret "OPENAI_API_KEY=$OPENAI_API_KEY" \ --secrets-scope organization \ --secrets-visibility selected \ --variables-scope repository \ --variable-scope AGENT_PROVIDER=repository ``` The explicit `--workflow-pat` and `--secret` options are provided for automation and can appear in process listings or shell history. The interactive hidden prompt is safer for a human operator. The equivalent non-secret setup file fragment is: ```yaml issueWorkflows: enabled: [feature, bugfix, documentation, chore, help] repositoryAgentGuidance: enabled: true agentsPointer: prompt ``` `issueWorkflows.enabled` accepts only the seven catalog IDs. `All` exists only in the interactive/CLI selector and is persisted as the explicit ordered list. The `release` and `hotfix` entries are also constrained by their corresponding setup features. `repositoryAgentGuidance` never overwrites existing guidance; the setup manifest is the ownership record for artifacts it generated. When guidance is enabled, setup generates `.copilot/repository-profile.json`, `.copilot/AGENT_GUIDE.md`, `.copilot/setup-manifest.json`, and the Codex skill `.agents/skills/copilot-repository-workflow/SKILL.md`. The generated guidance is derived from the selected issue workflow profile and branch/deployment settings. It tells repository agents to create issues from enabled Issue Forms, work on the exact Action-managed remote branch, push normal commits, and use a linked pull request. Agents must not create, rename, delete, replace, or force-push managed remote branches. Existing guidance and skills are preserved; setup-managed artifacts are refreshed only when the manifest identifies them as owned. Use `--agent-guidance disabled` to opt out. The Action receives the same profile through the `issue-workflow-profile` input and the `COPILOT_ISSUE_WORKFLOW_PROFILE` Repository Variable. An empty input selects all seven workflows and still validates their required Issue Form fields. Admission is fail-closed: unknown, disabled, conflicting, or incomplete issue work is skipped or blocked before agent preparation and repository mutation; it never silently becomes Feature work. Release and hotfix bodies must retain the headings and semantic fields supplied by their forms. ### `copilot doctor` Checks the setup PAT, selected workflow templates, Repository Variables, Secret presence, remote credential health, and live merge-queue readiness for production and development targets. It combines classic branch protection with effective rulesets and emits stable, ordered checks with `pass`, `warn`, `fail`, or dependency-blocked `skipped` status. Active release branches are discovered and revalidated at hotfix runtime. A failed setup PAT does not hide independent local drift: local checks continue and remote dependants name the blocking check. Independent remote probes use a fixed maximum concurrency of four, but their completion order never changes report order. Doctor exits non-zero exactly when at least one check fails. The complete human-readable report uses the configured repository locale and defaults to English (`en-US`). English and Spanish use reviewed bundled catalogs with exact or compatible-base matching. Any other valid BCP-47 locale uses one schema-constrained planner/language-agent request for the complete report catalog. If that request is unavailable or invalid, the whole report falls back atomically to English—never a mixture of translated headings and English diagnostics. Check IDs, status enums, branch names, credential names, and other machine facts remain stable. Raw provider and credential-health messages are not echoed into the report. The same rule applies to semantic errors from repository-aware local commands: the terminal localizes impact, action, retained state, retryability, and labels as one catalog while leaving the error code and correlation reference stable. The original producer message is not displayed. Failures raised before repository configuration can be resolved use the safe English default. This reduced two-check fixture shows the default English shape: ```text Copilot Doctor ✓ PASS Configuration — Setup configuration is valid. ✗ FAIL Merge queue production — Target policy could not be inspected because the provider request failed. Action: Check the setup PAT permissions and target branch policy, then retry. Checks: 1 pass, 0 warn, 1 fail, 0 skipped. No repository configuration was changed. ``` Doctor's composition contains query ports only: it never creates, updates, deletes, or overwrites repository configuration. The credential health query may dispatch the already-installed `copilot_credential_health.yml` workflow, which creates an Actions run but does not modify repository configuration or expose Secret values. Only setup owns the separate temporary health-workflow bootstrap capability. ```bash copilot doctor copilot doctor --token "$SETUP_PAT" copilot doctor --config .copilot-setup.yml --non-interactive ``` Existing GitHub Secret values cannot be read through the GitHub API. `copilot doctor` therefore dispatches `.github/workflows/copilot_credential_health.yml` when it is installed on the repository default branch. Each requested credential runs in its own job, so one invalid key does not make unrelated valid keys appear invalid. A present Secret without that workflow is reported as present but unverifiable; custom provider credentials are also reported as unverifiable until a provider-specific health check is available. An override file can contain only non-secret values: ```yaml features: inactiveIssueClosure: true release: false hotfix: false agents: planner: provider: codex modelProvider: openai model: gpt-6-luna reviewer: provider: opencode modelProvider: anthropic model: claude-3-7-sonnet effort: high repository: mainBranch: main developmentBranch: develop inactivityThresholdHours: 168 projects: ids: PVT_kwDOExample issueCreatedColumn: Todo issueInProgressColumn: In Progress ai: bugbotSeverity: medium bugbotCommentLimit: 10 bugbotEffort: smart bugbotDryRun: false bugbotReviewDrafts: false bugbotTraceRules: false bugbotSuggestedChanges: true bugbotTelemetry: true bugbotOrganizationRules: |- Require authorization checks on tenant-scoped operations Treat payment idempotency regressions as high severity ignoreFiles: node_modules/*,build/*,dist/* pullRequestDescriptionMode: append createInitialTag: true manageRepositoryVariables: true # Secrets and Variables are configured independently. Organization resources # require an organization-owned repository and organization Actions permissions. storage: secrets: defaultScope: organization organizationVisibility: selected preserveExisting: true variables: defaultScope: repository preserveExisting: true overrides: OPENAI_API_KEY: organization ``` Run it with `copilot setup --config .copilot-setup.yml`. The wizard rejects values that look like tokens, API keys, passwords, or other credential material. Secret values are accepted only through the hidden prompt or explicit CLI inputs and are written directly to GitHub Secrets after validation; they are never written to repository files or Variables. The required secret names are shown in the final plan. They include `PAT` plus credentials that cannot be supplied by another approved mechanism; a Codex login already present on the target runner is an explicit alternative, so Codex API credentials remain optional fallbacks. When a repository already inherits an organization resource, `preserveExisting: true` avoids creating a repository shadow; use `storage.*.overrides` when one named resource needs a different scope. ### `copilot reconcile` Checks whether the setup-managed workflow files in the current repository match the installed Copilot contract. It is read-only by default and does not call GitHub or change remote configuration. Use `--apply` to update only the detected setup-managed workflow files; those updates go through the same local backup/reconciliation path as setup. ```bash copilot reconcile copilot reconcile --json copilot reconcile --apply ``` The first version deliberately scopes reconciliation to workflow templates. Branches, labels, Repository Variables, and Secrets remain under `copilot setup`/`copilot doctor` until their remote diff and approval contracts are added. ### `copilot check-progress` Checks the progress of an issue from the selected branch and updates the progress label on the issue and its related open pull requests. The command sends the current workspace object ID, verifies that it matches the selected remote branch `HEAD` before agent analysis, then revalidates that remote snapshot before changing labels. The shared publisher performs the same check before each progress-card mutation in GitHub Actions. If the branch advances, the run succeeds as **No changes**, the stale result is suppressed, and newer state remains untouched. The selected branch must therefore exist on the configured GitHub remote. | Option | Required | Default | Description | | --- | --- | --- | --- | | `-i, --issue ` | Yes | — | Positive issue number. | | `-b, --branch ` | No | Resolved from the issue | Branch to analyze. | | `-t, --token ` | No | `PERSONAL_ACCESS_TOKEN` | PAT override. | | `-d, --debug` | No | `false` | Enables debug logging. | | `--dry-run` | No | `false` | Analyze and reconcile in memory without SCM mutations. | | `--output ` | No | `text` | Human-readable or machine-readable result. | | `--effort ` | No | `smart` | Review depth policy. | | `--trace-rules` | No | `false` | Include ordered rule sources. | | `--no-suggestions` | No | suggestions enabled | Disable native suggested changes. | ```bash copilot check-progress -i 123 copilot check-progress -i 123 -b feature/123-add-login ``` ### `copilot detect-potential-problems` Runs Bugbot against an issue and branch. Findings are published as issue comments when no PR exists, or as one summarized pull-request review when a PR is available. | Option | Required | Default | Description | | --- | --- | --- | --- | | `-i, --issue ` | Yes | — | Positive issue number. | | `-b, --branch ` | No | Current Git branch | Branch to analyze. | | `-t, --token ` | No | `PERSONAL_ACCESS_TOKEN` | PAT override. | | `-d, --debug` | No | `false` | Enables debug logging. | The selected agent runtime, model, credentials, and Bugbot policy must be configured. See [Bugbot detection](/bugbot/detection). ```bash copilot detect-potential-problems -i 456 copilot detect-potential-problems -i 456 -b feature/456-fix-bug --debug copilot detect-potential-problems -i 456 --dry-run --output json --effort high ``` ### Bugbot quality and analytics `copilot bugbot-benchmark` runs the real configured findings agent sequentially against a versioned synthetic corpus and writes predictions. `copilot bugbot-eval` scores prediction files without calling a provider. `copilot bugbot-analytics` aggregates content-free Action telemetry from JSON, JSONL, or logs. See [Quality and observability](/bugbot/quality-observability). ### `copilot recommend-steps` Uses the configured analysis agent to create or update one bounded implementation-plan card from an issue. The agent returns structured content: three to eight ordered steps, zero to two details per step, and one verifiable acceptance criterion. Copilot owns the Markdown layout, so model-generated headings or generic “Automatic Actions” wrappers cannot become the presentation. The plan uses the effective issue locale, defaulting to English (`en-US`). Paths, commands, refs, and code identifiers remain unchanged. A mismatched locale or malformed plan fails before publication. Re-running against an unchanged issue reconciles the existing card without creating a new comment; a material issue edit updates that card. Stored state accepts only the current closed structured plan shape and its exact canonical locale; removed free-form or missing-locale state is invalid. When the effective issue locale changes, the next agent-backed run must return a complete replacement in that locale and cannot answer `unchanged`. If no agent is configured, Copilot fails closed, so it cannot knowingly republish mixed-language UI. | Option | Required | Description | | --- | --- | --- | | `-i, --issue ` | Yes | Positive issue number. | | `-t, --token ` | No | PAT override; otherwise uses `PERSONAL_ACCESS_TOKEN`. | | `-d, --debug` | No | Enables debug logging. | ```bash copilot recommend-steps -i 789 ``` ### `copilot think` Runs deep code analysis and prints the configured agent's semantic response under a localized `Answer` label. The question is required; issue and branch options provide optional repository context. This local command does not create or update a GitHub comment. | Option | Required | Default | Description | | --- | --- | --- | --- | | `-q, --question ` | Yes | — | Question or prompt. Multiple words may be supplied without shell quoting each word. | | `-i, --issue ` | No | none | Optional issue whose description is added to the analysis context. Omitting it never probes or requires issue `#1`. | | `-b, --branch ` | No | `master` | Branch to use for the analysis context. | | `-t, --token ` | No | `PERSONAL_ACCESS_TOKEN` | PAT override. | | `--ai-ignore-files ` | No | `node_modules/*,build/*` | Comma-separated file patterns excluded from AI context. | | `--include-reasoning ` | No | `false` | Include the agent's reasoning when supported by the configured flow. | | `-d, --debug` | No | `false` | Enables debug logging. | ```bash copilot think -q "Where is authentication validated?" copilot think -i 123 -b feature/123-auth -q "Review the authentication flow" ``` ### `copilot do` Runs the configured **fixer/build agent** locally with a prompt. This is the CLI-only development assistant: it may edit files directly in the current workspace. It does not have a single-action equivalent and does not accept a GitHub PAT option. | Option | Required | Default | Description | | --- | --- | --- | --- | | `-p, --prompt ` | Yes | — | Request to execute in the current repository. | | `--output ` | No | `text` | Select human-readable or JSON output. | | `--agent-provider ` | No | `AGENT_PROVIDER` / `codex` | Runtime CLI override. | | `--agent-model-provider ` | No | `AGENT_MODEL_PROVIDER` | Model provider override. | | `--agent-model ` | No | `AGENT_MODEL` | Model override. | | `--agent-effort ` | No | `AGENT_EFFORT` | Reasoning effort or provider-specific variant. | | `--agent-executable ` | No | `AGENT_EXECUTABLE` | Exact provider basename or absolute executable path; no arguments. | | `--findings-provider ` | No | `FINDINGS_PROVIDER` | Findings task runtime override. | | `--findings-model-provider ` | No | `FINDINGS_MODEL_PROVIDER` | Findings model provider override. | | `--findings-model ` | No | `FINDINGS_MODEL` | Findings model override. | | `--findings-effort ` | No | `FINDINGS_EFFORT` | Findings effort override. | | `--findings-executable ` | No | `FINDINGS_EXECUTABLE` | Findings executable selection. | | `--fixer-provider ` | No | `FIXER_PROVIDER` | Fixer task runtime override. | | `--fixer-model-provider ` | No | `FIXER_MODEL_PROVIDER` | Fixer model provider override. | | `--fixer-model ` | No | `FIXER_MODEL` | Fixer model override. | | `--fixer-effort ` | No | `FIXER_EFFORT` | Fixer effort override. | | `--fixer-executable ` | No | `FIXER_EXECUTABLE` | Fixer executable selection. | | `-d, --debug` | No | `false` | Enables debug logging. | The primary agent values fall back to `AGENT_*` variables; task-specific values fall back to `FINDINGS_*` and `FIXER_*`. Credentials remain in the provider's supported environment or local credential store. Do not put credentials in command arguments or custom command values. ```bash copilot do -p "Add tests for the authentication flow" copilot do --output json -p "Explain the current release flow" ``` ## Quick command summary | CLI command | GitHub access | Required option | Main effect | | --- | --- | --- | --- | | `copilot setup` | PAT | — | Provision repository labels, types, templates, and workflows. | | `copilot check-progress` | PAT | `-i, --issue` | Update progress from issue and branch changes. | | `copilot detect-potential-problems` | PAT and agent | `-i, --issue` | Publish Bugbot findings. | | `copilot bugbot-benchmark` | Agent | `--corpus`, `--predictions` | Generate real-agent corpus predictions. | | `copilot bugbot-eval` | None | `--corpus`, `--predictions` | Score quality metrics and gates. | | `copilot bugbot-analytics` | None | `--input` | Aggregate content-free telemetry. | | `copilot recommend-steps` | PAT and agent | `-i, --issue` | Comment implementation recommendations. | | `copilot think` | PAT and agent | `-q, --question` | Return analysis and change proposals. | | `copilot do` | Agent only | `-p, --prompt` | Analyze or modify the local workspace. | For the corresponding GitHub Action inputs, see [Available actions](/single-actions/available-actions). For provider credentials and model policy, see [Agent CLI configuration](/agents/cli-configuration).