The central additions are Automations, Voice Mode, a richer Agents window for GitHub work, and a small reactive VS Code pet. They are all tied to the editor’s expanding agent experience. Of those headline features, Automations is in Preview, while Voice Mode, GitHub issue and pull-request details in the Agents window, and the pet are Experimental. That distinction matters, but so does the shared implication: neither Preview nor Experimental is the same as Stable. Preview features may still receive stability and polish iterations; Experimental features may change or be removed.
Four prominent features are still pre-stable
It would be misleading to describe only three of the highlighted additions as “not stable.” Microsoft’s own lifecycle labels put four in pre-Stable categories:
- Automations is a Preview feature.
- Voice Mode is Experimental.
- GitHub issue and pull-request details in the Agents window is Experimental.
- The VS Code pet is Experimental.
The labels are not merely cosmetic. A Stable feature is described as fully supported, whereas Experimental work is aimed at early adopters and can change or disappear. Preview sits between those poles: the functionality may be close to its intended shape, but still subject to stability and refinement work.
That framing should guide deployment decisions. An individual Windows user who wants to test a spoken agent conversation or recurring code-review prompt may reasonably enable the settings and evaluate the experience. A development organization should be more cautious about standardizing an Experimental workflow, especially where it may touch repositories, local files, commands, or hosted issue data. The available material does not establish reliability, production suitability, adoption levels, or user satisfaction for these features. Their labels and gradual release status are the clearest signals currently available.
Automations turn saved agent prompts into recurring work
Automations is the most consequential addition because it changes an agent interaction from a one-off chat into a saved recurring task. A user can run an automation manually or schedule it on an hourly, daily, or weekly basis through the Agents window. The feature requires chat to be enabled and the chat.automations.enabled setting to be switched on.
The intended appeal is straightforward. Developers often repeat the same broad requests: review a change, inspect a branch, look for unfinished work, or perform another recurring check. Saving such a task could eliminate the need to recreate the prompt each time. It also provides a more visible route to recurring agent activity inside VS Code rather than forcing the user to treat every request as an isolated conversation.
But “scheduled” should not be read as an unattended cloud service that runs regardless of what happens to a PC. Automations execute locally. Depending on the schedule type, they need either an active Agent Host process or a running VS Code window. The machine must remain awake. If the device is off, asleep, or the needed host is not running, the schedule cannot operate normally; a missed run may only result in a catch-up run. The same automation also does not run parallel sessions.
For Windows laptop users, this creates an immediate operational boundary. A daily task due while a notebook is closed in a bag is not equivalent to an always-on server job. Users wanting a dependable cadence will need to consider power settings, sleep behavior, whether VS Code is open, and whether the relevant Agent Host process is actually active. The feature may still be useful for work performed on a desktop that remains available during the day, but its local execution model limits how much it can substitute for dedicated scheduling infrastructure.
Permissions are the more important caution. Microsoft warns that an automation can read files, execute commands, and make changes according to the permissions of its chosen agent. Scheduling a task does not bypass organization policy, and saving it does not guarantee that future runs will proceed without approval. That is a useful safeguard, but it also means users must review a recurring task as something with real local consequences, not just as a calendar reminder.
Before turning a broad prompt into a schedule, it is sensible to ask what directories the agent could access, which commands it could propose or run, what changes it might make, and whether repeated execution is actually desirable. A narrowly scoped inspection task is a materially different risk from a task that is permitted to modify a workspace. Teams with policy controls should confirm that the agent configuration, approvals, and repository practices fit their governance rules before treating Automations as part of a regular workflow.
Availability itself is qualified. Automations are rolling out gradually, are off by default in Stable builds, and are on by default in Insiders. Consequently, two Windows developers on nominally similar VS Code installations may not see the same result. The right expectation is an opt-in Preview rollout, not universal availability on day one.
Voice Mode brings spoken agent sessions, with major eligibility limits
Voice Mode lets a user conduct a spoken conversation with the active agent or session after enabling agents.voice.enabled. A spoken response can be interrupted either by speaking or by using the push-to-talk shortcut. This makes agent chat potentially more conversational: rather than waiting for a long response to finish, a developer can stop it and redirect the interaction.
For accessibility and hands-busy moments, this could be meaningful. Spoken interaction may be more convenient when someone is reading output, thinking through a task, or unable to type comfortably. It could also make agent work feel less like issuing static prompts and more like maintaining an active technical discussion.
Yet this feature has tighter availability conditions than a release-note headline may suggest. Voice Mode is gradually rolling out, requires an eligible individual GitHub Copilot plan, and is not available with GitHub Copilot Business or GitHub Copilot Enterprise. Organizations can also disable Copilot preview features through policy.
That means many Windows users in managed workplace environments may be unable to use it even if they update to VS Code 1.137 and enable the setting. This is not necessarily a technical fault or a missing installation step; it can be a plan or policy limitation. Since Voice Mode is Experimental and explicitly may change or be removed, teams should avoid building process assumptions around it until its availability and lifecycle status become clearer.
There is also a privacy and workplace-practicality angle, even though the available release material does not make claims about transcription handling or data retention. Speaking project context aloud can be unsuitable in shared offices, classrooms, or public spaces. Users should treat the feature as a convenience layer over an agent interaction, not presume that voice is appropriate for every coding environment.
The Agents window becomes more connected to GitHub work
VS Code 1.137 adds an Experimental ability for the Agents window to open GitHub issue and pull-request details without going out to a browser. It can work even when the relevant repository workspace is not open. This can reduce context switching for developers who move frequently between code, requests, and issue discussions.
The capability has explicit setup requirements: the GitHub Pull Requests extension must be installed in the default profile, and extensions.experimental.enableAgentsWindowCapability must be enabled. It is another example of a feature that may not be available simply because the editor has been updated.
A related change appears in the Markdown editor. Experimental GitHub rich links can display the current title and state for issue and pull-request links, and update when the linked item’s state changes, including CI updates. For release notes, planning documents, and pull-request descriptions maintained in Markdown, that can make links more informative at a glance.
Both GitHub-oriented additions are useful examples of VS Code pushing agent and repository context toward the same surface. The benefit is fewer browser detours and richer status visibility. The counterargument is that experimental integrations can create a fragmented support picture: the feature requires particular settings and extension configuration, and the experience is not yet Stable. Developers who depend on a browser-based GitHub workflow do not need to replace it; the new view is best treated as an optional in-editor supplement.
Quick chats can become workspace sessions
Another workflow refinement addresses a common agent-chat problem: an initially lightweight question can become work that needs repository context. In the Agents window, a quick chat can be converted into a workspace session after the user confirms a folder or worktree choice. The session retains its title, conversation history, and current request.
That continuity could spare users from restating the task after deciding that a question now requires access to a workspace. It is a modest feature on paper, but it aligns with a broader design direction in this release: move from disconnected chat prompts toward sessions that carry context across stages of work.
There is a key limitation. This continuation is currently available only in the Copilot harness. Users of other agent setups should not assume the same handoff behavior exists for them. The conversion also requires a confirmation step for the folder or worktree, which is appropriate given the difference between an initially context-light exchange and an agent session that may interact with a local workspace.
The pet is a deliberate experiment, not a productivity feature
The release’s least conventional addition is the Experimental VS Code pet. It sits above the chat input, reacts to agent and chat activity, and can be invoked with /vscode-pet. Microsoft is also running an official naming contest from September 10 through September 17, 2026, subject to entry restrictions including age, geography, and a one-entry limit.
The pet is not a core developer capability, and it should not be presented as one. Its value is experiential: it gives the agent surface a more playful, visible presence. For some users that may make the interface feel more engaging; for others, it may be an unnecessary distraction in a professional workspace. Its Experimental label is especially important here because Microsoft says Experimental features might change or be removed.
What Windows developers should do now
VS Code 1.137 is a release worth exploring for users interested in agent-centered development, but it rewards deliberate testing rather than blanket enablement. First, check whether the gradual rollout has made the desired feature available, then enable only the relevant setting. For Automations, begin with a low-risk, read-oriented task and verify the Windows machine’s wake and VS Code or Agent Host behavior before relying on a schedule. Review the agent’s permissions before allowing any recurring task to work with files, commands, or changes.
For Voice Mode, confirm plan eligibility and organization policy before troubleshooting an apparent absence. For GitHub details in the Agents window, verify the extension and experimental setting requirements. And for all four pre-Stable capabilities, keep a conventional workflow available: normal chat, standard repository tools, browser-based GitHub pages, and existing scheduled systems remain important fallbacks.
The larger story is not that VS Code 1.137 has delivered a finished autonomous development environment. It is that Microsoft is testing how recurring tasks, spoken exchanges, workspace handoffs, and GitHub context might converge around agents inside the editor. That direction may prove useful, but the current release asks Windows users to separate promising workflow experiments from stable, universally available tools.