VS Code adds assisted tool approvals for agent workflows

• VS Code 1.130 is an agent-workflow release, with approvals, multi-file review, and chat visibility grouped in the VS Code release thread.
• Assisted tool approvals let the model evaluate tool-call risk before interrupting a run, so routine calls can proceed while other calls still ask, according to the assisted-approvals post.
• The Agents window preview now adds live insert/delete counts per file header, which the diff-review post frames as a faster way to size up multi-file changes.
• Chat now exposes sent times and response duration inline, the chat-timing post says.

The VS Code 1.130 release notes put the new approval mode behind chat.assistedPermissions.enabled, and only for agents running on the agent host. The Agent Host Protocol guide describes the deeper architecture: a standalone sessions server that keeps multiple clients synchronized on the same agent session. The existing approvals docs show where assisted approvals fit in VS Code's permission stack, alongside session-level permission levels, per-tool approvals, URL approvals, terminal approval rules, and sandboxing.

The most consequential change is approval triage moving into the model loop. The 1.130 release notes say assisted permissions evaluate each tool call's risk, then either allow the call to run or ask the developer for approval.

Mechanics in 1.130:

• Setting: chat.assistedPermissions.enabled.
• Scope: agents running on the agent host.
• UI: an Assisted permissions option in the permissions picker.
• Behavior: repeated approval prompts during long-running agent tasks are reduced by risk-scoring individual tool calls.

VS Code's approval documentation still describes the underlying safety model: tools can modify files, run commands, or access external resources, and URL responses get a separate review step because fetched content can carry prompt-injection attempts.

Assisted permissions ships on top of VS Code's agent host work. The 1.130 notes say agent sessions for harnesses such as Copilot, Claude, and Codex run in a dedicated process based on the Agent Host Protocol, with chat.agentHost.enabled as the opt-in setting.

The architecture matters because several new agent features are scoped to that host process:

• A session can be connected to and rendered from multiple VS Code windows.
• Copilot on the agent host is powered by the Copilot SDK, aligning it with Copilot CLI and the standalone GitHub Copilot app.
• Some features may appear only when an agent runs on the agent host.
• Claude can be steered toward the agent host with chat.agents.claude.preferAgentHost, according to the release notes.

The AHP guide calls the protocol agent-agnostic and under active development. It also says AHP uses immutable, Redux-like state trees, pure reducers, channels such as sessions and changesets, and write-ahead reconciliation for client/server state sync.

The review surface got more useful for multi-file agent output. The diff-review post shows the file-level insertion and deletion counts that now sit beside file paths in the Agents window preview.

The release notes add three related details:

• Compact multi-file diffs remove empty gutter space and align file headers, line numbers, and unchanged-region controls.
• Quick chats on the agent host use compact, single-line rows in the sessions list.
• Worktree isolation now applies across agent-host harnesses, so Claude and Codex sessions can use Git worktrees in addition to Copilot.

That last point is the sleeper feature for parallel agent runs: the worktree checkbox is no longer Copilot-only in the Agents window.

VS Code also added timing metadata to chat. The chat-timing post says each message now shows when it was sent and how long the reply took.

The 1.130 release notes put the control behind chat.verbose; hovering over the message toolbar shows the timestamp and elapsed time for a chat interaction.

Copilot Business and Enterprise users also get aggregate AI credit usage in the Copilot status menu for the current billing cycle. The same notes say usage was previously surfaced only when a user-level budget was configured, leaving many org-managed users without per-cycle visibility inside the editor.