Microsoft shipped VS Code 1.124 on June 10, 2026, with a change that will affect every developer who updates the editor without reading the release notes: Copilot Autopilot — the permission level that lets the AI agent take actions without asking for your approval at each step — is now enabled by default. For the overwhelming majority of VS Code's developer base, who research consistently shows do not change default settings, this is not a feature they will choose. It is the environment they will be working in the next time they open the editor.
That distinction matters because Autopilot is not simply a faster mode. It is a different accountability structure. When Autopilot runs, the agent writes files, executes terminal commands, calls tools, and auto-responds to any prompts tools raise — without stopping to confirm each action with you. Microsoft's own security documentation states plainly that Autopilot mode "reduces your ability to review intermediate steps." That warning has not changed. What changed today is that Autopilot is where every new chat session starts.
Three Permission Tiers: What Each One Actually Does
Understanding what moved from opt-in to default requires understanding the architecture behind it. VS Code's agentic permission model has three tiers, and the differences between them are more technically significant than their names suggest.
Default Approvals was previously the starting point. Under Default, the agent uses your configured approval settings and presents a confirmation dialog before running any tool that requires approval — file writes, terminal commands, external tool calls. You remain in the loop at each significant step.
Bypass Approvals removes those confirmation dialogs. All tool calls proceed automatically and errors are retried without prompting you, but questions that tools raise are still directed to you. It functions as a mute button on approval dialogs: the agent moves faster, but it still stops when it hits a question it cannot answer on its own.
Autopilot goes further. It combines Bypass Approvals with auto-responses to tool questions, so the agent never stalls waiting for a human reply. The mechanism is a continuous loop: the agent runs until it calls a specific task_complete signal, at which point it stops. Until that signal fires, it proceeds through whatever actions it deems necessary — writing code, running tests, installing packages, fixing errors — on its own judgment.
As of 1.124, Autopilot is the permission level your chat sessions start with. You can change it at any time using the permissions picker in the chat input box, and organizations can override the default system-wide via the chat.tools.global.autoApprove policy setting. Individual developers can revert to step-by-step approvals by changing the chat.permissions.default setting.
Advanced Autopilot: How the Loop Decides When Work Is Done
Knowing when a task is genuinely complete — not just apparently complete — has been the hardest engineering problem for autonomous agents. Stop too early and the output is incomplete. Loop too long and you waste tokens and risk compounding errors.
VS Code 1.124 addresses this with Advanced Autopilot, an opt-in enhancement to the standard mode. Instead of relying on fixed rules to determine when to call task_complete, Advanced Autopilot routes that decision to a secondary utility model. The utility model reads a transcript of the entire chat session and decides whether the objective has been achieved — Microsoft surfaces the agent's current goal in a tooltip above the chat so you can always see what it is working toward.
To prevent runaway loops, the system enforces a hard ceiling: Autopilot iterates a maximum of three times before stopping regardless of whether the utility model has determined the task is done. This cap applies to the Advanced mode specifically; standard Autopilot relies on the task_complete tool signal without the secondary check. Advanced Autopilot can be enabled via the chat.autopilot.advanced.enabled setting in VS Code.
The three-loop cap is an engineering constraint worth understanding explicitly. It prevents a misfiring agent from burning through API credits or mangling a codebase through recursive self-correction. But it also means that genuinely complex tasks may run out of runway at the third iteration and leave work incomplete without a clean failure signal. Developers running Advanced Autopilot on multi-step refactoring tasks should review the transcript if the result does not match expectations.
Background Sessions and Session Navigation
The rest of the 1.124 update is a set of workflow improvements designed for developers managing multiple concurrent agent tasks.
Background session sending removes a meaningful bottleneck. Previously, starting a new agent session meant waiting for the current one to load and commit before composing the next prompt. In 1.124, pressing Alt+Enter in the new session view sends a request in the background immediately — the view resets to accept the next prompt while the previous session processes. Each started session appears in the sessions list once it commits. For developers running parallel feature branches with separate agent sessions, this removes the serial dependency that made multi-agent workflows feel sequential.
Session navigation has been substantially improved. A new sessions picker (Ctrl+R on Windows/Linux, Cmd+R on macOS) opens a searchable quick-pick list of your sessions, grouped into recently opened and others. Back-and-forward navigation uses Ctrl+Tab and Ctrl+Shift+Tab. Position-based jumps — Ctrl+1 through Ctrl+9 — let you focus any of the first nine sessions in the grid directly from the keyboard. Reloading or reopening the Agents window now restores your previous layout automatically, including which sessions were open, their order, and per-session editor state.
Single-file diff view in the Changes panel is available in preview via sessions.changes.openSingleFileDiff. When enabled, selecting a file in the Changes view opens a focused single-file diff rather than the default multi-file editor — useful for reviewing one change at a time without the context of adjacent edits.
Integrated Browser History Now Persists Across Sessions
One smaller but practical addition: the integrated browser inside VS Code now retains history across sessions, surfacing previously visited pages as suggestions when you type in the URL bar. History is managed via Ctrl+H (Cmd+H on macOS) from within a browser tab, and the maximum number of stored entries is configurable via workbench.browser.maxHistoryEntries. For developers who frequently reference documentation pages, internal web apps, or API explorers inside VS Code, this eliminates the re-navigation loop that reset with every editor restart.
What VS Code Autopilot On by Default Means at Scale
The most significant change in 1.124 is not what Autopilot can do — it has been capable of these actions since VS Code 1.111 in March — but where it starts. Default settings in software are not neutral design choices. Research on software defaults consistently shows that users rarely change them; the default is, in practical terms, the product for most users. Making Autopilot the starting posture means Microsoft's entire developer base is now working in autonomous agent mode unless they actively choose otherwise.
Microsoft made the same calculation it is watching rivals make. Google shipped Auto Approve Mode for Gemini Code Assist on March 10, 2026. Anthropic launched Claude Code auto mode on March 24. The direction across the major AI coding tools is convergent: autonomous action is moving from opt-in to baseline.
That convergence should prompt developers to ask a question the release notes do not foreground: what is the attack surface of an editor running Autopilot by default? Security research points to a specific answer. Prompt injection — injecting malicious instructions into code files, commit messages, or configuration files that the agent reads and acts on — is the documented attack vector for autonomous VS Code sessions. Prompt Security demonstrated in December 2025 that a malicious AGENTS.MD file in a repository can silently redirect a Copilot agent to exfiltrate project data during an ordinary coding session. The agent reads the file as an instruction set, not documentation. With Autopilot on by default, that vector is active the first time a developer opens an unfamiliar repository and asks a routine question.
Microsoft's own security documentation recommends terminal sandboxing to restrict agent-executed commands at the OS level — but notes explicitly that this protection only works on macOS and Linux. Windows developers have no equivalent mitigation and are directed to run VS Code in a dev container instead.
👉 Read more: 317596 GitHub Copilot multi-agent VS Code Build 2026 317536 GitHub Copilot agentic billing 10x-50x increase
The co-author incident from May 2026 is the most recent precedent for how the developer community responds when a VS Code default change lands without sufficient communication. When VS Code 1.118 automatically started appending a Copilot co-author trailer to git commits, the community reaction was immediate and sharp — more than 800 GitHub issue comments in two days, compliance concerns from regulated-industry developers, and a revert in the following week's release. Microsoft appears to have built more opt-out infrastructure into the Autopilot default than it provided for the co-author change, including the organization-level policy setting. Whether that infrastructure reaches the developers who need it depends entirely on whether administrators know to configure it before their teams update.
Frequently Asked Questions
What is VS Code Autopilot mode and how does it work?
Copilot Autopilot is the highest autonomy tier in VS Code's three-level agent permission system. When active, it automatically approves all tool calls, retries errors, and auto-responds to any questions tools raise — letting the agent write code, run terminal commands, and iterate through a task without pausing for human confirmation. The agent runs until it calls a task_complete signal or, in Advanced Autopilot mode, until a secondary utility model reads the chat transcript and determines the objective has been met.
What is the difference between Bypass Approvals and Autopilot in VS Code?
Both modes skip manual approval dialogs for tool calls, but Autopilot goes one step further: it also auto-responds to questions that tools raise during execution, so the agent never stalls waiting for a human answer. Under Bypass Approvals, the agent still stops and waits if a tool asks a clarifying question. Under Autopilot, it answers and continues on its own judgment. As of VS Code 1.124, Autopilot is the default starting permission level for new chat sessions.
Is VS Code Autopilot safe to use for AI coding assistant workflows?
The mode carries documented security tradeoffs. Microsoft's own security documentation notes that Autopilot "reduces your ability to review intermediate steps," and security researchers have demonstrated that malicious instruction files in a repository can redirect an autonomous Copilot session to exfiltrate data — a risk that activates the first time a developer opens an unfamiliar project. Terminal sandboxing is available as an OS-level mitigation on macOS and Linux, but Windows developers have no equivalent protection. Organizations can restrict Autopilot behavior at the admin level via the chat.tools.global.autoApprove policy setting; individual developers can change the default in the chat permissions picker.
How do I disable Copilot Autopilot in VS Code and revert to step-by-step approvals?
Change the chat.permissions.default setting in VS Code preferences to your preferred level — either Default Approvals for confirmation dialogs at each significant step, or Bypass Approvals for tool-call automation without the full autonomous behavior of Autopilot. The permissions picker in the chat input box also lets you change the level for a specific session without modifying the global setting.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
