Productivity | The .NET Blog

VS Code 1.119: OpenTelemetry for Agent Sessions, Browser Integration, and Security

Emiliano Montesdeoca — Fri, 15 May 2026 00:00:00 +0000

VS Code 1.119 shipped May 6, 2026 (with a 1.119.1 security patch shortly after). The release focuses on agent observability, browser interaction, and reducing interruptions.

OpenTelemetry tracing for agent sessions

This is the standout feature for anyone running agents in production or debugging agentic workflows. Enable it with two settings:

"github.copilot.chat.otel.enabled": true,
"github.copilot.chat.otel.otlpEndpoint": "http://localhost:4318"

Traces follow GenAI semantic conventions. Each agent request produces an invoke_agent root span with nested child spans: chat, execute_tool, and execute_hook. Token usage is reported per request — including cache read and cache creation counts.

Works with the local agent, Copilot CLI background agent, and the Claude agent. Any OTLP-compatible backend accepts the traces — the Aspire Dashboard standalone works well for local development.

Agents can now access browser tabs

Agents can request access to your integrated browser tabs — but it’s not automatic. You have to explicitly share a tab via the context picker, drag-and-drop, or suggested context. There’s a sharing button in the browser to revoke access. When an agent tries to open a new tab on the same domain as an already-open (unshared) tab, VS Code prompts you to reuse the existing tab instead.

Optimized token usage

An experimental lightweight model now handles agent todo-list management, keeping that housekeeping off the more expensive primary model. Reduces token burn on tasks that don’t need full reasoning capacity.

Trust & security

Fewer interruptions: VS Code 1.119 reduces prompts for network access requests and temp folder writes by agents. The 1.119.1 patch addresses specific security issues — worth updating if you haven’t.

Markdown preview quick-swap

Small but useful: you can now quickly swap the current editor to Markdown preview without navigating away.

VS Code Agents (Insiders preview)

The redesigned agent session UI — new repo picker (local/repos/remote), sub-session improvements, web + mobile polish, progress animations — is available in Insiders at insiders.vscode.dev/agents.

Full changelog: code.visualstudio.com/updates/v1_119.

Visual Studio 2026 April Update: Cloud Agent, Custom Agents, and Debugger Agent

Emiliano Montesdeoca — Thu, 14 May 2026 00:00:00 +0000

Visual Studio 2026 (18.5) April update ships cloud agent integration, user-level custom agents, C++ tools going GA, and a new Debugger Agent.

Cloud agent: offload work to a remote Copilot session

From the Chat window’s agent picker, selecting Cloud lets you hand off a task to a remote Copilot coding agent. You describe the work, the agent creates a GitHub issue in your repo, then opens a PR when done. You get a notification with “View PR” / “Open in browser” — the whole thing runs while you keep coding, or even with the IDE closed.

Custom agents now travel with you

User-level custom agents stored in %USERPROFILE%/.github/agents/ are no longer repo-scoped — they follow you across projects. The storage path is configurable under Tools > Options > GitHub > Copilot > Chat. The + button in the agent picker lets you create new agents directly. They get the same capabilities as repo-scoped agents: workspace awareness, tools, model selection, and MCP connections.

Built-in agents: Agent, Ask, Copilot CLI, Debugger, Modernize, Profiler.

C++ Code Editing Tools go GA

Two tools — get_symbol_call_hierarchy and get_symbol_class_hierarchy — are now on by default. They give Copilot language-aware navigation of C++ codebases, covering inheritance hierarchies and function call chains. Enable via the Tools icon in Copilot Chat. Works best with tool-calling models.

Debugger Agent: fixes validated against real runtime behavior

Start from a GitHub or Azure DevOps issue (or just a natural language description), switch to Debugger mode, and the agent:

Creates a minimal reproducer
Generates failure hypotheses
Instruments the app with tracepoints and conditional breakpoints
Runs an actual debug session
Analyzes live telemetry
Suggests a precise fix

You stay in the loop throughout — it’s interactive, not fully autonomous.

IntelliSense priority fix

VS now suppresses Copilot completions while the IntelliSense list is active. One suggestion at a time. This was a frequent friction point and it’s now on by default.

Full release notes and download at devblogs.microsoft.com.

That Visual Studio Floating Windows Setting You Didn't Know About (But Should)

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

If you use multiple monitors with Visual Studio (and honestly, who doesn’t these days), you’ve probably experienced the annoyance: floating tool windows disappear when you minimize the main IDE, they always stay on top of everything else, and they don’t show up as separate taskbar buttons. It works for some workflows, but for multi-monitor setups it’s frustrating.

Mads Kristensen from the Visual Studio team shared a little-known setting that completely changes how floating windows behave. One dropdown. That’s it.

The setting

Tools > Options > Environment > Windows > Floating Windows

The dropdown “These floating windows are owned by the main window” has three options:

None — full independence. Every floating window gets its own taskbar entry and behaves like a normal Windows window.
Tool Windows (default) — documents float freely, tool windows stay tied to the IDE.
Documents and Tool Windows — classic Visual Studio behavior, everything tied to the main window.

Why “None” is the move for multi-monitor setups

Set it to None and suddenly all your floating tool windows and documents behave like real Windows applications. They appear in the taskbar, stay visible when you minimize the main Visual Studio window, and stop forcing themselves to the front of everything.

Combine this with PowerToys FancyZones and it’s a game changer. Create custom layouts across your monitors, snap your Solution Explorer to one zone, debugger to another, and code files wherever you want. Everything stays put, everything is independently accessible, and your workspace feels organized instead of chaotic.

Quick recommendations

Multi-monitor power users: Set to None, pair with FancyZones
Occasional floaters: Tool Windows (default) is a solid middle ground
Traditional workflow: Documents and Tool Windows keeps everything classic

Pro tip: Ctrl + double-click on any tool window title bar to instantly float or dock it. No restart needed after changing the setting.

Wrapping up

It’s one of those “I can’t believe I didn’t know about this” settings. If floating windows in Visual Studio have ever annoyed you, go change this right now.

Read the full post for the details and screenshots.

Azure DevOps Finally Fixes the Markdown Editor UX Everyone Complained About

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

If you use Azure Boards, you’ve probably experienced this: you’re reading through a work item description, maybe reviewing acceptance criteria, and you accidentally double-click. Boom — you’re in edit mode. You didn’t want to edit anything. You were just reading.

Dan Hellem announced the fix, and it’s one of those changes that sounds tiny but actually removes real friction from your daily workflow.

What changed

The Markdown editor for work item text fields now opens in preview mode by default. You can read and interact with the content — follow links, review formatting — without worrying about accidentally entering edit mode.

When you actually want to edit, you click the edit icon at the top of the field. When you’re done, you exit back to preview mode explicitly. Simple, intentional, predictable.

That’s it. That’s the change.

Why this matters more than it sounds

The community feedback thread on this was long. The double-click-to-edit behavior was introduced with the Markdown editor back in July 2025, and the complaints started almost immediately. The problem wasn’t just accidental edits — it was that the whole interaction felt unpredictable. You never knew if clicking would read or edit.

For teams that do sprint planning, backlog grooming, or code review with Azure Boards, this kind of micro-friction compounds. Every accidental edit mode entry is a context switch. Every “wait, did I change something?” moment is wasted attention.

The new default respects the most common interaction pattern: you read work items far more often than you edit them.

Rollout status

This is already rolling out to a subset of customers and expanding to everyone over the next two to three weeks. If you’re not seeing it yet, you will soon.

Wrapping up

Not every improvement needs to be a headline feature. Sometimes the best update is just removing something annoying. This is one of those — a small UX fix that makes Azure Boards feel less hostile to people who just want to read their work items in peace.

Bookmark Studio Brings Slot-Based Navigation and Sharing to Visual Studio Bookmarks

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

Bookmarks in Visual Studio have always been… fine. You set one, you navigate to the next, you forget which bookmark is which. They work, but they’ve never been the kind of feature you’d call powerful.

Mads Kristensen just released Bookmark Studio, an experimental extension that fills in exactly the gaps you’ve probably run into if you use bookmarks regularly.

The core addition: bookmarks can now be assigned to slots 1–9 and jumped to directly with Alt+Shift+1 through Alt+Shift+9. New bookmarks automatically get the next available slot, so in most cases, fast navigation works without any setup.

This sounds simple, but it changes bookmarks from “I have some bookmarks somewhere” to “Slot 3 is my API controller, Slot 5 is the service layer, Slot 7 is the test.” That kind of spatial memory makes navigation nearly instant during focused work sessions.

The Bookmark Manager

A new tool window shows all your bookmarks in one place with filtering by name, file, location, color, or slot. Double-click or keyboard-navigate to jump to any bookmark.

If you’ve ever had more than five or six bookmarks and lost track of which was which, this alone is worth installing the extension.

Organization with labels, colors, and folders

Bookmarks can optionally have labels, colors, and be grouped into folders. None of it is required — your current bookmark workflow keeps working. But when you’re debugging a complex issue or exploring an unfamiliar codebase, being able to color-code and label your bookmarks adds useful context.

All metadata is stored per solution, so your bookmark organization persists across sessions.

This is the feature I didn’t know I wanted. Bookmark Studio lets you export bookmarks as plain text, Markdown, or CSV. That means you can:

Include bookmark paths in pull request descriptions
Share investigation breadcrumbs with teammates
Move bookmark sets between repos or branches

Bookmarks stop being a solo navigation tool and start being a way to communicate “here’s the path through this code.”

Bookmarks that track code movement

Bookmark Studio tracks bookmarks relative to the text they’re anchored to, so they don’t drift to wrong lines as you edit. If you’ve ever set bookmarks during a debugging session and had them all point to the wrong lines after a refactor — this fixes that.

Wrapping up

Bookmark Studio doesn’t reinvent anything. It takes a feature that’s been “good enough” for years and makes it genuinely useful for focused development. Slot navigation, the Bookmark Manager, and export capabilities are the highlights.

Grab it from the Visual Studio Marketplace and give it a try.

VS Code 1.112: What .NET Developers Should Actually Care About

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

VS Code 1.112 just landed, and honestly? This one hits different if you’re spending your days in .NET land. There’s a lot in the official release notes, but let me save you some scrolling and focus on what actually matters for us.

Copilot CLI just got way more useful

The big theme this release is agent autonomy — giving Copilot more room to do its thing without you babysitting every step.

Message steering and queueing

You know that moment when Copilot CLI is halfway through a task and you realize you forgot to mention something? Before, you had to wait. Now you can just send messages while a request is still running — either to steer the current response or queue up follow-up instructions.

This is huge for those longer dotnet scaffolding tasks where you’re watching Copilot set up a project and think “oh wait, I also need MassTransit in there.”

Permission levels

This is the one I’m most excited about. Copilot CLI sessions now support three permission levels:

Default Permissions — the usual flow where tools ask for confirmation before running
Bypass Approvals — auto-approves everything and retries on errors
Autopilot — goes fully autonomous: approves tools, answers its own questions, and keeps going until the task is done

If you’re doing something like scaffolding a new ASP.NET Core API with Entity Framework, migrations, and a Docker setup — Autopilot mode means you describe what you want and go grab a coffee. It’ll figure it out.

You can enable Autopilot with the chat.autopilot.enabled setting.

Preview changes before delegation

When you delegate a task to Copilot CLI, it creates a worktree. Before, if you had uncommitted changes, you had to check Source Control to see what would be affected. Now the Chat view shows pending changes right there before you decide whether to copy, move, or ignore them.

Small thing, but it saves you from that “wait, what did I have staged?” moment.

Debug web apps without leaving VS Code

The integrated browser now supports full debugging. You can set breakpoints, step through code, and inspect variables — all inside VS Code. No more switching to Edge DevTools.

There’s a new editor-browser debug type, and if you already have existing msedge or chrome launch configurations, migrating is as simple as changing the type field in your launch.json:

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

For Blazor developers, this is a game changer. You’re already running dotnet watch in the terminal — now your debugging stays in the same window too.

The browser also got independent zoom levels (finally), proper right-click context menus, and the zoom is remembered per website.

MCP server sandboxing

This one matters more than you might think. If you’re using MCP servers — maybe you’ve set up a custom one for your Azure resources or database queries — they’ve been running with the same permissions as your VS Code process. That means full access to your filesystem, network, everything.

Now you can sandbox them. In your mcp.json:

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

When a sandboxed server needs access to something it doesn’t have, VS Code prompts you to grant permission. Much better than the “hope nobody does anything weird” approach.

Note: Sandboxing is available on macOS and Linux for now. Windows support is coming — remote scenarios like WSL do work though.

Monorepo customizations discovery

If you’re working in a monorepo (and let’s be honest, many enterprise .NET solutions end up as one), this solves a real pain point.

Previously, if you opened a subfolder of your repo, VS Code wouldn’t find your copilot-instructions.md, AGENTS.md, or custom skills sitting at the repository root. Now with the chat.useCustomizationsInParentRepositories setting, it walks up to the .git root and discovers everything.

This means your team can share agent instructions, prompt files, and custom tools across all projects in a monorepo without everyone having to open the root folder.

/troubleshoot for agent debugging

Ever set up custom instructions or skills and wonder why they’re not being picked up? The new /troubleshoot skill reads agent debug logs and tells you what happened — which tools were used or skipped, why instructions didn’t load, and what’s causing slow responses.

Enable it with:

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

Then just type /troubleshoot why is my custom skill not loading? in chat.

You can also export and import these debug logs now, which is great for sharing with your team when something isn’t working as expected.

Image and binary file support

Agents can now read image files from disk and binary files natively. The binary files are presented in hexdump format, and image outputs (like screenshots from the integrated browser) show up in a carousel view.

For .NET developers, think: paste a screenshot of a UI bug into chat and have the agent understand what’s wrong, or have it analyze the output of a Blazor component rendering.

Automatic symbol references

Small quality-of-life improvement: when you copy a symbol name (a class, method, etc.) and paste it into chat, VS Code now automatically converts it to a #sym:Name reference. This gives the agent full context about that symbol without you having to manually add it.

If you want plain text instead, use Ctrl+Shift+V.

Plugins can now be enabled/disabled

Previously, disabling an MCP server or plugin meant uninstalling it. Now you can toggle them on and off — both globally and per-workspace. Right-click in the Extensions view or the Customizations view and you’re done.

Plugins from npm and pypi can also auto-update now, though they’ll ask for approval first since updates mean running new code on your machine.

Wrapping up

VS Code 1.112 is clearly pushing hard on the agent experience — more autonomy, better debugging, tighter security. For .NET developers, the integrated browser debugging and Copilot CLI improvements are the standout features.

If you haven’t tried running a full Copilot CLI session in Autopilot mode for a .NET project yet, this release is a good time to start. Just remember to set your permissions and let it cook.

Download VS Code 1.112 or update from within VS Code via Help > Check for Updates.

Productivity | The .NET Blog

VS Code 1.119: OpenTelemetry for Agent Sessions, Browser Integration, and Security

OpenTelemetry tracing for agent sessions

Agents can now access browser tabs

Optimized token usage

Trust & security

Markdown preview quick-swap

VS Code Agents (Insiders preview)

Visual Studio 2026 April Update: Cloud Agent, Custom Agents, and Debugger Agent

Cloud agent: offload work to a remote Copilot session

Custom agents now travel with you

C++ Code Editing Tools go GA

Debugger Agent: fixes validated against real runtime behavior

IntelliSense priority fix

That Visual Studio Floating Windows Setting You Didn't Know About (But Should)

The setting

Why “None” is the move for multi-monitor setups

Quick recommendations

Wrapping up

Azure DevOps Finally Fixes the Markdown Editor UX Everyone Complained About

What changed

Why this matters more than it sounds

Rollout status

Wrapping up

Bookmark Studio Brings Slot-Based Navigation and Sharing to Visual Studio Bookmarks

Slot-based navigation

The Bookmark Manager

Organization with labels, colors, and folders

Export and share

Bookmarks that track code movement

Wrapping up

VS Code 1.112: What .NET Developers Should Actually Care About

Copilot CLI just got way more useful

Message steering and queueing

Permission levels

Preview changes before delegation

Debug web apps without leaving VS Code

MCP server sandboxing

Monorepo customizations discovery

/troubleshoot for agent debugging

Image and binary file support

Automatic symbol references

Plugins can now be enabled/disabled

Wrapping up