What changed
GitHub’s August 31 Copilot roundup describes a broader shift in VS Code’s agent experience: the editor can now organize sessions across applications, preserve context while work continues, and make agent-generated changes easier to inspect. The headline is less about one new model and more about making the session itself a durable product object.
The anchor is the Agent Host in Visual Studio Code 1.135. Its Sessions list can show recent Copilot or Claude sessions created in other applications, then let you continue one inside VS Code. The Agent Host can also connect multiple VS Code windows to the same session through a dedicated process and the Agent Host Protocol, aligning the experience with the Copilot CLI, the standalone Copilot app, and other Copilot surfaces.
The GitHub Copilot in VS Code August releases add more continuity around that core: /btw opens a side conversation that shares the primary chat’s context and prompt cache while the main session keeps running; external Copilot or Claude sessions can be continued; model providers can be switched in Claude sessions; and the experimental /rubber-duck command can ask a complementary model for a second opinion. The integrated browser also supports annotating several page elements so an agent can address UI feedback in one pass.
Why it matters
This is a product shift from “an assistant inside an editor” to “a work session that can travel across surfaces.” The value is continuity: a developer can start an agent task in one client, inspect or redirect it in another, and keep the relevant files, diffs, artifacts, and conversation attached to the same unit of work.
It also makes agent extensibility more portable. Agent plugins in VS Code describes Agent Plugins 1.0 as a shared package format for skills and MCP servers across compatible Copilot clients. Client-specific agents, commands, rules, and hooks can sit beside those portable pieces without forcing every client to understand the entire package.
That combination matters for teams: session portability reduces the cost of switching tools, while portable capabilities reduce the cost of rebuilding integrations for every agent client. The new usage details and second-opinion workflow point in the same direction—agent UX is becoming a review and coordination layer, not only a prompt box.
The builder takeaway
The practical design lesson is to treat an agent session as a durable, shareable object:
- Give every session a stable identity and a resumable event history.
- Keep orchestration separate from the UI so the same work can appear in a desktop editor, CLI, or web surface.
- Make files, diffs, browser state, artifacts, tool permissions, and approvals visible as session-level state.
- Package reusable skills and MCP connections in a portable format, with explicit client-specific extensions where needed.
- Show model, cached-input, output-token, and cost signals close to the work so users can make informed trade-offs.
The last two points are an architectural takeaway from the direction of these releases, not a claim that every agent product must copy GitHub’s implementation. The broader pattern is clear: the winning agent interface may be the one that preserves context while letting the user change where, how, and with which model the work continues.