Define "MCP Sandbox Interface" and implement limactl mcp serve

[AkihiroSuda]

This PR allows AI agents such as Gemini CLI to wrap local file operations (read/write/execute) inside Lima VM.

It should work with Claude Code, Codex, etc. too, but they might need a modification to disable their built-in local file operation tools. (Help wanted for testing)

This feature will be available in Lima v2.0

• v2.0 planning (pluggable VM drivers, AI helpers, etc.) #3712

Preview of the documentation: https://deploy-preview-3744--lima-vm.netlify.app/docs/config/ai/

---

Interface

pkg/mcp/msi defines "MCP Sandbox Interface" (tentative) that should be reusable for other projects too.

MCP Sandbox Interface defines MCP (Model Context Protocol) tools that can be used for reading, writing, and executing local files with an appropriate sandboxing technology. The sandboxing technology can be more secure and/or efficient than the default tools provided by an AI agent.

MCP Sandbox Interface was inspired by Gemini CLI's built-in tools. https://github.com/google-gemini/gemini-cli/tree/v0.1.12/docs/tools

Implementation

limactl mcp serve INSTANCE launches an MCP server that implements the MCP Sandbox Interface.

Use https://github.com/modelcontextprotocol/inspector to play around with the server.

limactl start default brew install mcp-inspector mcp-inspector

In the web browser,

• Set Command to limactl
• Set Arguments to mcp serve default
• Click ▶️Connect

Usage with Gemni CLI

1. Create .gemini/extensions/lima/gemini-extension.json as follows:

{ "name": "lima", "version": "2.0.0", "mcpServers": { "lima": { "command": "limactl", "args": [ "mcp", "serve", "default" ] } } }

2. Modify .gemini/settings.json so as to disable Gemini CLI's built-in tools except ones that do not relate to local command execution and file I/O:

{ "coreTools": ["WebFetchTool", "WebSearchTool", "MemoryTool"] }

---

TODOs

• Support writing files
• Test

[jandubois]

I've only browsed the code, but if I understand this correctly, the "protection" relies just on the fact that the VM has mounted the filesystem readonly. AFAICT there is no sandboxing of the filesystem, so the ReadFile tool could still read e.g. credentials from ~/.aws/config on the host and is not restricted to subdirectories of the current directory. And since you run arbitrary commands, this would need some kind of chroot jail, and not a pre-filtering of the arguments.

Beyond that, I wonder if this isn't outside the scope of Lima itself. It is an application built on top of Lima, but for some reason compiled into it. It could just as well be built as a separate tool. Or as a limactl-mcp plugin.

So I wonder if it wouldn't be good to include it as an example on how to create plugins for Lima? The reason to keep it in the Lima repo would be that MCP is a hot topic, and having it bundled makes it easier to discover.

[AkihiroSuda]

I've only browsed the code, but if I understand this correctly, the "protection" relies just on the fact that the VM has mounted the filesystem readonly. AFAICT there is no sandboxing of the filesystem, so the ReadFile tool could still read e.g. credentials from ~/.aws/config on the host and is not restricted to subdirectories of the current directory. And since you run arbitrary commands, this would need some kind of chroot jail, and not a pre-filtering of the arguments.

The home directory except the pwd can be hidden with:

limactl start --mount-only "$(pwd)" 

• editflags: add --mount-only flag #3947

Beyond that, I wonder if this isn't outside the scope of Lima itself. It is an application built on top of Lima, but for some reason compiled into it. It could just as well be built as a separate tool. Or as a limactl-mcp plugin.

Maybe lima-mcp (or lima-mcpserver) so as to keep limac[TAB] shell completion working ?

[jandubois]

Maybe lima-mcp (or lima-mcpserver) so as to keep limac[TAB] shell completion working ?

limactl-mcp would be the naming scheme we have already implemented. Tab completion still works, but you have to type the space yourself:

$ cat ~/bin/limactl-hello #!/bin/bash echo "Hello world from $BASH_SOURCE" $ limactl hello Hello world from /Users/jan/bin/limactl-hello

We could also look for plugins in /usr/local/share/libexec/lima to have an option to install them outside the PATH by default (we already look for external drivers in that directory).

[AkihiroSuda]

Reimplemented as limactl-mcp CLI plugin

[jandubois]

It doesn't seem to be working for me:

❯ l mcp -v limactl-mcp version 2.0.0-alpha.0-39-gf71031e6 ❯ l ls default qemu NAME STATUS SSH VMTYPE ARCH CPUS MEMORY DISK DIR default Stopped 127.0.0.1:0 vz aarch64 4 4GiB 100GiB ~/.lima/default qemu Running 127.0.0.1:63754 qemu aarch64 4 4GiB 100GiB ~/.lima/qemu ❯ l mcp serve default FATA[0000] expected status of instance "default" to be "Running", got "" ❯ l mcp serve qemu FATA[0000] expected status of instance "qemu" to be "Running", got "" ❯ l shell qemu uname -a Linux lima-qemu 6.14.0-23-generic #23-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 13 22:12:54 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

[AkihiroSuda]

It doesn't seem to be working for me:

Works for me.
Maybe you have some "non-standard" config? (e.g., custom LIMA_HOME)

[jandubois]

Maybe you have some "non-standard" config? (e.g., custom LIMA_HOME)

No, I have the default setup. My suspicion is that store.Inspect does not work properly because limactl-mcp doesn't have the builtin drivers, and I don't have the drivers installed as external drivers. So loading of the driver-specific fields does not work.

I would have expected to see something like vmType "vz" is not registered or something like that, so don't know if the theory is correct.

Are you sure you don't have external qemu and vz drivers installed on your system, that might be responsible for making it work on your machine.

I think as a plugin the code has to call limactl ls INSTANCE --json as a subprocess instead of using store.Inspect.

[jandubois]

Confirmed: The error goes away after running

ADDITIONAL_DRIVERS="qemu vz" make native additional-drivers limactl-plugins install

[jandubois]

I would have expected to see something like vmType "vz" is not registered or something like that,

And it turns out to be #2668 once again wasting time. We really should fix this non-idiomatic interface.

When I add

@@ -151,6 +152,9 @@ func mcpServeAction(cmd *cobra.Command, args []string) error {	if err != nil {	return err	} +if len(inst.Errors) != 0 { +return errors.Join(inst.Errors...) +}	if err = ts.RegisterInstance(ctx, inst); err != nil {	return err	}

then I get a more meaningful error:

❯ l mcp serve default FATA[0000] failed to resolve vm for "/Users/jan/.lima/default/lima.yaml": vmType "vz" is not a registered driver

[jandubois]

Is it a bug that make uninstall does not remove external drivers?

[unsuman]

Is it a bug that make uninstall does not remove external drivers?

I guess for a dev env, make clean should remove the external drivers. Not sure how make uninstall works though?

[jandubois]

I guess for a dev env, make clean should remove the external drivers. Not sure how make uninstall works though?

You can just look it up in the Makefile. 😄

make clean just deletes _output with everything in it.

The install target actually runs uninstall first, to make sure it installs a consistent set of files. It tries do delete anything that has potentially been installed by make install before. I think we just forgot to add the external drivers to the uninstall target.

[unsuman]

Oh, got it, thanks! I've raised a fix for the same #4034

[AkihiroSuda]

Fixed the incompatibility with built-in drivers

[jandubois]

Thanks, LGTM

[jandubois]

Thanks, LGTM