The first era of AI coding tools looked like autocomplete with a chat box attached. That was useful, but it also made agents feel like visitors inside tools built for a different job. They could suggest code, explain errors, or draft a function, but the real work still lived in scattered windows: the issue tracker, the IDE, the terminal, the browser, CI, the pull request, and the mental stack of what the agent just tried.

GitHub's new Copilot app preview points to the next layer. The interesting part is not that Copilot now has another interface. It is that GitHub is trying to give coding agents a place to work that looks less like a conversation and more like a desk: active sessions, isolated worktrees, visible plans, diffs, terminal output, browser state, review controls, and handoff paths into pull requests.

That matters because agentic coding is no longer a single prompt followed by a patch. It is parallel, stateful, review-heavy work. One agent investigates a bug. Another builds a backlog item. A third fixes review comments. The developer is not only typing instructions. The developer is managing a small system of software workers, each with its own context, evidence, and blast radius.

issue -> agent session -> worktree -> tests -> pull request
        |                 |            |        |
        plan              diff         logs     review gate
The new unit of work is not a chat message. It is an inspectable session.

The app is a control plane

On June 2, GitHub said the Copilot app technical preview is available to existing Copilot Pro, Pro+, Business, and Enterprise customers on Windows, macOS, and Linux. Its My Work view is meant to gather connected repositories, active sessions, issues, pull requests, and background automations into one desktop surface. Sessions can start from a prompt, an issue, a pull request, a local folder, or previous work.

The detail that deserves attention is the worktree model. GitHub says each parallel agent session runs on its own git worktree and branch, with isolated files, conversation, and task state. That is a practical answer to a real problem. If agents are allowed to run multiple lines of inquiry at once, they need filesystem separation that maps back to Git. Otherwise every experiment becomes a merge conflict factory.

This is also why the desktop shape makes sense. A code agent is not just a model response. It is a loop around a repo. It needs context, a shell, a browser, tests, diffs, tool permissions, and a way to turn finished work into a pull request. Cramming that into a chat transcript makes the transcript do too many jobs. It becomes command log, planning document, review surface, and audit trail at once.

Canvases turn chatter into state

The most important interface idea in the release is the canvas. GitHub describes canvases as bidirectional work surfaces for people and agents. A canvas can represent a plan, pull request, browser session, terminal, release checklist, migration board, dashboard, cloud console, or workflow state. The agent can update it while working. The developer can inspect, reorder, approve, edit, or redirect from the same surface.

That sounds like interface polish until you think about what breaks in real agent sessions. Chat is good for ambiguity. It is bad at durable state. A long transcript hides the one line that matters. A model says it ran tests, but the developer still has to find the output. A plan changes halfway through, but the old plan remains in the scrollback. A browser check happened, but there is no stable surface tying that evidence to the patch.

A canvas gives agent work a place to land. It makes intent visible. It lets progress become a structured artifact instead of a pile of prose. For teams, that is the difference between trusting an assistant because it sounds confident and trusting a workflow because the checks, files, decisions, and pending human calls are visible.

The user interface for agents cannot just be a better prompt box. It has to show what the agent knows, what it changed, what it proved, and where it needs judgment.

Isolation becomes normal plumbing

The app announcement also sits next to GitHub's public preview of cloud and local sandboxes for Copilot. Local sandboxing restricts shell command execution initiated by Copilot, including access to filesystem, network, and system capabilities. Cloud sandboxes run in isolated, ephemeral Linux environments hosted by GitHub and inherit organization policies.

This is the right direction. The more useful a coding agent becomes, the less acceptable it is to run it as an all-powerful helper inside a developer machine. Agents need to execute tests, run commands, inspect output, and sometimes drive browsers. They also need boundaries. Sandboxing is not a compliance accessory. It is part of the runtime model for agentic development.

There is a cultural shift here too. Developers are used to thinking of isolation as something for production, CI, or suspicious dependencies. Agentic development pulls isolation into the inner loop. The question becomes: what can this session touch, what network calls are allowed, what secrets are visible, what writes require approval, and what evidence proves it stayed inside the lane?

Review is the bottleneck

If agents make it easier to produce pull requests, review becomes the pressure point. GitHub is treating that as part of the same system. The Build-era Copilot updates include Agent Merge, code review features, a medium tier review option, the /security-review skill, and the generally available /rubberduck skill for multi-model critique.

The important lesson is that agent output needs different review ergonomics. A human colleague can explain intent, remember prior conversations, and notice when a suggested shortcut violates team taste. An agent can produce a lot of plausible code quickly, but the reviewer still needs to know what was tried, what failed, what tests passed, and which assumptions are weak.

Better code review for agents should not mean letting another model rubber-stamp the first model. It should mean turning review into a staged filter: cheap checks for low-risk changes, deeper reasoning for high-impact code, explicit security passes when needed, and repository-specific rules that encode local standards. The win is not fewer humans. The win is humans spending less time reconstructing context and more time making the calls only they can make.

A runtime across surfaces

GitHub is also making the Copilot SDK generally available across Node.js and TypeScript, Python, Go, .NET, Rust, and Java. Its pitch is that teams can build internal tools on the same agentic runtime that powers the app. The Copilot CLI is getting a redesigned terminal UI, voice input with on-device speech-to-text, scheduled prompts, cloud sessions, and shared session history through /chronicle.

Put together, the message is clear: GitHub does not want Copilot to be one product inside one editor. It wants the agent runtime to stretch across desktop, terminal, cloud, GitHub.com, pull requests, partner apps, internal tools, and scheduled automations. That is ambitious, and it creates the usual platform questions about lock-in, governance, billing, and how much of the workflow should live inside one vendor's system.

Still, the architecture is directionally right. Agents need continuity. A task that starts in a terminal may need a browser check, a PR review, a cloud sandbox, and a scheduled follow-up. If every surface has a separate memory and permission model, the workflow becomes brittle. If one runtime can carry context with clear boundaries, the agent becomes less like a toy and more like infrastructure.

The desk changes the job

The best way to read the Copilot app is as an early agent operations console. It is not just a place to ask for code. It is a place to supervise work in progress. That changes the developer's job at the margin. More time goes into writing precise issues, setting policy, choosing the right execution environment, reviewing evidence, and deciding when an agent may proceed.

That is not a demotion. It is closer to the normal arc of automation. When a tool gets stronger, the valuable work moves toward framing, verification, taste, and systems thinking. The person still owns the software. The interface finally starts admitting that the agent needs its own workspace, not just a corner of the chat pane.

The takeaway is simple: coding agents are becoming team infrastructure. They need desks, task queues, sandboxes, memory, inspection surfaces, and review gates. GitHub's Copilot app is one version of that future, and it will have to prove itself under real engineering pressure. But the shape is right. The agent era will not be won by the best chatbot. It will be won by the systems that make agent work visible, bounded, reviewable, and shippable.

Sources