Same worker, different jobs. Monday they're badged for Tower A, third floor only — the badge won't open any other door. Tuesday they're at a different site, working out of a trailer instead of inside the building. The worker is the same; the where changes everything about what they can reach.
An agent has the same "where." It can run as a cloud agent (inside GitHub's own machinery), from the CLI (a terminal), or in the IDE (VS Code). And wherever it runs, it's badged to one repo and usually one branch — it can't wander off-site. "Evaluating the execution context" is reading that badge.
The idea, in plain English
Three official sub-skills, all about where and how an agent runs:
- Evaluate the execution context — recognize cloud vs CLI vs IDE and what each implies.
- Scope to a specific repository.
- Branch-based scope.
Execution context = the environment an agent runs in. It decides which tools even exist (recall 2.1: no ask_user or powershell in the cloud), how it's triggered, and what it can touch.
The three execution surfaces
| Surface | Where it runs | How you reach it |
|---|---|---|
| Cloud agent | inside GitHub Actions, in an isolated run | assign via an issue or prompt; works on a branch → opens a PR |
| CLI | your terminal (the copilot command) | interactive or scripted |
| IDE | VS Code agent mode | the editor's Copilot chat |
The cloud agent does NOT run on your local machine — it runs inside GitHub Actions, and every run gets its own isolated environment. The four non-negotiables: every agent's activity is scoped to a repo · permission-controlled · run through workflows · visible/reviewable. The target property pins a custom agent to vscode, github-copilot, or (omitted) both.
Repository + branch scope
Repository scope — an agent is scoped to a specific repo; it can't reach others by default. The cloud agent works in the source repo, and its token (and the out-of-box github MCP server) is scoped to that source repo. In Actions, the running repo is github.repository; actions/checkout's repository input controls which repo lands on the runner.
Branch scope (the subtle, exam-worthy one):
- The agent picks a base branch, creates a working branch, commits there, and opens a PR (the 5-step flow from B0.1). The base stays protected; review happens on the PR.
- Agent versions are tied to Git commit SHAs. A task uses the latest profile from that repo and branch at the moment it starts — so which branch you're on changes which version of the agent runs. Branch scope is also version scope.
- In Actions,
github.ref/github.head_refandactions/checkout'srefinput set which branch the run operates on.
"A cloud agent is assigned an issue in acme/web." Runs it: GitHub Actions (not your laptop), isolated. Scoped to: the acme/web repo; token limited to that source repo. Changes land: on a new working branch, surfaced as a PR — never a silent push to main. One-look: cloud = runs in Actions, issue-triggered, branch→PR · CLI = terminal · IDE = VS Code.
Authentication (how the context is established)
- Token types: fine-grained PAT (with Copilot Requests permission), OAuth, or
GITHUB_TOKEN. Classicghp_PATs do NOT work with Copilot CLI. - Token precedence (CLI):
COPILOT_GITHUB_TOKEN→GH_TOKEN→GITHUB_TOKEN(first found wins). - Enterprise:
copilot login --hosttargets a GitHub Enterprise Cloud (data-residency) instance. Config/state lives in~/.copilot/.
The cert-language version
An agent's execution context is the surface it runs on — cloud (inside GitHub Actions, isolated, not local), CLI (terminal), or IDE (VS Code). It is scoped to a repository (token + github MCP limited to the source repo) and works on a branch (changes surface as a PR; agent version = the profile's commit SHA on that branch). All activity is repo-scoped, permission-controlled, workflow-run, and reviewable.
Our summary · grounded in MS Learn — Agent tooling, MCP, and execution environments + GitHub Docs (custom-agents config, Copilot CLI, Actions contexts) · fetched 2026-05-30
Common confusions (read these or lose points)
- "The cloud agent runs on my machine." No — it runs in GitHub Actions, isolated per run. The CLI is the terminal one.
- "An agent can edit any repo." No — scoped to its source repo; token is repo-scoped.
- "The agent pushes straight to main." No — it works on a branch and opens a PR.
- "The agent version is fixed." No — it's the latest profile commit on the current branch when the task starts.
- "Any PAT works for the CLI." No — classic
ghp_PATs don't; use a fine-grained PAT (Copilot Requests), OAuth, orGITHUB_TOKEN.
Ticks this lesson done on the home roadmap. Saved in this browser.