Evidence note: This article rests almost entirely on GitHub’s own published record — a beginner-oriented guide on The GitHub Blog, two product announcements, an engineering write-up, and four changelog entries. Those are primary sources for what GitHub says it built and when, and they are treated as settled on that narrow point: the company announced it. They are not independent verification of how the software performs, and none of the capability or performance claims below have been corroborated by a third party or tested here. Where a figure comes only from GitHub, that is marked on the claim itself.
What GitHub published
GitHub published a beginner-oriented guide titled "GitHub Copilot app for Beginners: Using the diff, terminal, and browser" on The GitHub Blog. According to that guide, the lesson teaches three things done side by side inside a single application window: viewing diffs, running terminal commands, and previewing a running web app (source: GitHub’s own guide; no independent review of the walkthrough exists).
The piece is not standalone. GitHub presents it as part of a "GitHub Copilot app for Beginners" series that also includes a getting-started installment and an installment on building custom workflows with canvases. Three installments, in other words, with this one sitting in the middle: install and open the thing, then inspect what it produced, then compose repeatable workflows.
The stated premise: three tabs to check one change
The guide’s framing is worth quoting on its own terms, because it is an argument about workflow rather than about model quality. Its stated premise is that checking agent-generated code usually means hopping between tabs — the diff in one place, a shell in another, the running application in a third (as characterized in GitHub’s own guide).
That premise is a claim about developer behavior, and GitHub offers it as motivation rather than as a measured finding. No survey, telemetry figure, or sample size accompanies it in the published guide. Readers evaluating whether the pitch applies to them are, at present, left comparing it against their own habits; sources do not confirm how widespread the pattern is.
The underlying problem it points at is real enough to state without borrowing GitHub’s authority: when an agent writes the change, the human’s job shifts from authoring to verification, and verification is exactly the activity that fragments across windows. Reading a diff tells you what changed. Running the code tells you whether it works. Loading the page tells you whether it works the way a person would want. Those are three different questions, and historically three different surfaces.
What the app actually is
The product this lesson sits on top of is not an editor plugin. GitHub introduced the Copilot app as an agent-native desktop experience — a surface for finding work, running it, steering it, and landing it across repositories, rather than a single-project workspace. Its source repository is published on GitHub.
The distinction matters for reading the beginner lesson correctly. A diff pane inside an editor is a review tool for code you are about to write. A diff pane inside an agent-native shell is a review tool for code something else already wrote, possibly in several repositories at once, possibly while you were doing something else. The terminal and browser panes exist for the same reason: they close the loop on work you did not type.
Developers who have followed this product line may recognize the trajectory from our earlier look at Copilot operating as an agent across the software lifecycle, and from our walkthrough of the app’s 2026 record and the Dependabot triage workflow built on it.
A diff surface rebuilt for a million-line pull request
The most concrete engineering claim in the public record concerns the diff pane specifically. GitHub says it rebuilt that surface so it can open a pull request of a million lines carrying hundreds of inline review comments, and published an engineering account of rendering huge pull requests in the Copilot app describing the work.
That figure — one million lines, hundreds of inline comments — comes from GitHub’s own engineering write-up and has not been independently reproduced or benchmarked; no third-party timing, memory, or scroll-latency measurement of the rebuilt surface is available in the public record, and none was produced here. What the write-up establishes is the design target GitHub chose to build against, which is itself informative: a million-line diff is not a human-authored pull request. It is the shape of machine-generated change, and the headroom is an admission of what the company expects agents to produce.
The shipping record so far
Two changelog entries fix the app’s release timeline. GitHub announced that the Copilot app entered technical preview on 14 May 2026, and that it became generally available on 17 June 2026. Both dates are from GitHub’s own changelog.
Thirty-four days from preview to general availability is a short run for a desktop application, though the public record does not say what changed between those two dates or what preview feedback drove it.
Local sandboxing lands in the releases dated 21 September
The newer fact reframes the beginner lesson. GitHub announced on 25 September 2026 that local sandboxing was added to the Copilot app in the Copilot weekly releases dated 21 September. That is GitHub’s own changelog entry; the announcement establishes that the capability shipped, and the entry itself is the only public description of its scope. What exactly the sandbox isolates, whether it is on by default, and which operations it constrains are not established by any independently verifiable source.
Count the interval: general availability on 17 June, local sandboxing announced on 25 September. That is 100 days during which the application shipped a terminal pane to general-availability users without the sandboxing boundary that arrived in September — as far as the published changelog record shows. GitHub has not stated that the two are related, and the changelog does not frame the sandbox as a response to the terminal.
Why the ordering matters to developers
Read the beginner lesson against that timeline and a pattern appears that GitHub does not comment on: the capability was taught first, and the boundary landed later.
A guide that instructs newcomers to run terminal commands inside an agent-native application is teaching them to execute code in the same window where an agent proposes it. That is convenient, and it is also the exact point where the question "what is this command allowed to touch?" becomes load-bearing. Local sandboxing is the kind of answer that question wants. It arrived after the general-availability release, and the public record does not establish whether the beginner guide has been revised to reflect it, nor whether the walkthrough’s terminal steps now run inside the sandbox by default. Readers following the lesson today should check the current in-app behavior rather than assume the guide’s screenshots reflect the post-21-September build.
This is an observation about publication order, not an allegation of negligence. Shipping a boundary after a capability is ordinary in software. It is worth naming only because the audience for a beginner guide is precisely the audience least equipped to notice that a safety-relevant layer was added after the tutorial was written.
Where the terminal lesson does not apply
One clarification prevents a predictable confusion. The terminal in the beginner lesson is a pane inside the Copilot app. It is not the same thing as GitHub’s separate command-line product, which has its own repository.
Reporting suggests that GitHub Copilot CLI brings the Copilot coding agent directly into a developer’s own shell, as a product distinct from the Copilot app — but this has not been independently cross-checked here, and the relationship between the two products, including whether they share the same sandboxing behavior, should be treated as unconfirmed. Developers who work primarily in a terminal multiplexer rather than a desktop window will want to establish which of the two the beginner lesson’s instructions actually apply to before following them; on present evidence, it is the app.
What the metrics expansion counts, and what it does not
There is one more dated entry relevant to teams rather than individuals. GitHub announced that Copilot app usage metrics were expanded across report rollups on 28 July 2026, per its own changelog.
What that gives an engineering manager is visibility into app usage appearing in aggregate reporting. What the public record does not establish is whether those rollups distinguish the activities the beginner lesson teaches — a diff opened, a terminal command run, a preview loaded — or whether they count app sessions in bulk. Nor is there any published indication that the metrics separate sandboxed terminal execution from unsandboxed execution, which would be the natural way to measure whether the September boundary is actually in the path. This mirrors a gap seen elsewhere in Copilot’s reporting surface, where new usage metrics arrived without counting the mechanism that had just been introduced.
Developer takeaway
For a developer deciding whether to spend time here, the published record supports a short answer.
The three installments form a coherent sequence and are worth reading in order: getting started, then the diff, terminal, and browser lesson, then custom workflows with canvases. The middle installment is the one that teaches verification, and verification is the skill that agent-generated change actually demands.
Two practical checks before adopting the workflow it describes. First, confirm which build is installed and whether the terminal pane in that build runs under the local sandboxing announced on 25 September, since the guide predates it and the changelog is the only description of its scope. Second, if usage reporting matters to the team, verify empirically what the 28 July rollups record, because the announcement does not specify the granularity.
The follow-up question the public record cannot answer is narrower than it first appears: it is not whether the Copilot app collapses three tabs into one — GitHub’s guide asserts that, and the engineering write-up describes real work toward it. It is whether the sandbox added in the releases dated 21 September governs the terminal steps the beginner lesson teaches, and whether the metrics expanded on 28 July would show anyone if it did not. Answering that requires either a documentation update from GitHub or a controlled test of the shipping build against a known-restricted operation — an experiment not performed here, and a reasonable one to propose.