Yes, that's how I am using it. However there is an experimental qemu microvm backend and a push for podman support if that is more interesting for you.
We use MCP when security and tight capability boundaries are important.
For example, even GitHub’s fine-grained tokens aren’t always fine-grained enough for our use cases. In those situations, it’s straightforward to build a small MCP server that exposes exactly the operations we want an agent to have access to.
That gives us a much smaller and more explicit attack surface, without having to manually audit every possible GitHub CLI invocation the agent might make.
I get this use-case, but what makes an MCP server better than a custom CLI tool that exposes those same operations? That's how I've solved similar things in the past.
Mcp just wraps the existing calls with a description of when to use them. Why would you write a cli for something like this? And clis generally have a help call but that doesn’t say when to use a tool just what it does
Eclipse Enclave does exactly that: There is an outbound firewall and secret injections, so that the agent never sees a real key. And it's fully open source: https://github.com/eclipse-enclave/enclave
What is missing in qemu + podman that we need rootful docker for this? Is there actual capability that is missing or is it more of a design choice by the eclipse enclave folks?
As soon as I tried Claude Code it was clear to me that I want it to run in yolo mode, but safely. I can very much recommend the Eclipse Enclave sandbox which is fully open source, see https://github.com/eclipse-enclave/enclave
Thanks for pointing to that project- I am glad there are more options out there and hope to discover more. Requiring a root docker setup is a non-starter for me though and I am otherwise taking some different design approaches that I think lead toward better security (perhaps at the cost of some convenience), but the concept is basically the same.
Isn't the main vulnerability the cache poisoning in GitHub Actions?
Yes, the agent installed a malicious package in its workflow. But if GitHub Actions had been properly isolated, the attack would not have been possible.
It's basically impossible to protect against malicious injections when consuming unknown inputs. So the safeguard is to prevent agents from doing harm when consuming such inputs. In this case, it seems nothing would have happened if GitHub Actions itself had not been vulnerable.
I have a question: Can your tool detect duplicates with lower resolution? A typical use case would be images received via chat apps, which are often downscaled to save bandwidth. If I have a higher quality version, I'd like to keep only the larger one.
I think it's worth mentioning that the Theia IDE is a fully open source VS Code-compatible IDE (not a fork of VS Code) that's actively adding AI features with a focus on transparency and hackability.
We considered Theia, and even building our own IDE, but obviously VSCode is just the most popular. Theia might be a good play if Microsoft gets more aggressive about VSCode forks, although it's not clear to us that people will be spending their time writing code in 1-2 years. Chances are definitely not 0 that we end up moving away from VSCode as things progress.
It's the most popular because the tech is decades old. You're all rushing to copy obsolete technology. Now we have 10 copies of an obsolete technology.
I mean I guess I should thank the 10 teams who forked VSCode for proving beyond all reasonable doubt that VSCode is architecturally obsolete. I was already trying to make that argument, but the 10 forks do it so much better.
reply