I'm somewhat surprised that this is not open source (from what I can tell). Compare to Mimo Code https://github.com/XiaomiMiMo/MiMo-Code (which is a CLI, while this is a desktop app).
I don't even know what I would do with a desktop app. I'm running these things in headless VMs, so I can run them with `--dangerously-skip-permissions` or whatever. I don't trust them, even without that flag, on my desktop/laptop.
But, it's still running on my desktop/laptop. I don't trust them to run on my machine. But, I guess I could run one VM with a desktop to contain the desktop app. Or, just keep using CLI agents.
For local tasks you can only give agents delegated that execute your deterministic read or write on an allowed set of files(e.g pi does this) and execute rights only on containers with no network access. That should get you 95% unblocked for most tasks you want to do with an LLM pretty safely.
You can do a brainstorming with web on a remote container prototyping based on that brainstorm on another container with no network access.
The one thing that is less trustworthy is using local agents for service management, you definitely want to have them scoped to dev/testing. I would never trust an agent to execute any command in production or sensitive data at all
Is the trust concern for the agent running in any form on your machine? Like in a VM on your machine as well or do you mean on the host itself?
I have read about people giving an agent full access to their main system saying they have nothing of value. To me, that's a strange opinion to have with the distinction between what's private and what's secret.
I don't run agents directly on my desktop/laptop machine. I run them in VMs or containers (sometimes in containers on VMs). There have been too many credentials stealing exploits via prompt injection and the like for me to be willing to let an agent roam around on my personal system.
I've also started creating new github deploy keys for each repo in use on a VM, so the blast area for any given agent disaster is "a couple/few github repos and whatever credentials were needed for the agent/model".
I wouldn't let a coworker, even one I know pretty well, log into my personal account on my machines...why would I let an agent that can be tricked into uploading all my credentials to an attackers web server?
The agents have sandboxes, but those are loose. Not enforced by anything outside of the agent harness itself.
> The agents have sandboxes, but those are loose. Not enforced by anything outside of the agent harness itself.
You might want to check out Ant's open source srt [0], I use it to contain my local coding agents. It's strict by default and enforced at the OS layer.
What benefit does running it locally have over parents solution of running it in a container in a VM?
I do the same: my agents run in a hardened VM on a hardened Linux machines in a separated network in my basement. The magic of ssh makes this setup transparent for me on my desktop. But extremely hard for my agent to do nasty things.
I'm working on a credential broker that would keep credentials vaulted and parcel out access on a per-grant basis. Is that something you'd find useful or is your setup comprehensive enough? We would be allowing people to draft access policies with natural language, I figured it would be useful for things like vercel, stripe access etc.
Not at all would i ever within the current technology constraints trust a "natural language model" to secure access to my own credentials, i will always keep it as completely isolated from anything at all i would consider 'risky' and pre-define before it begins what it could possibly access through a brand new VM with only the absolute minimal access to any git repo's and completely restrict to the extent that is allowable, it's ability to do anything outside of it's own playground. The playground is disposable, the potential for the LLM to access any of my own accounts and wreak havoc on the trust in my network is unacceptable under any rules....
fwiw, i built something simple like this into my harness thing (github.com/0gsd/enough). may not be complicated enough to do per application nowadays vs. needing a modularized outside solution, but it is certainly a good idea that seems to work!
Oh yeah, that sounds wise to me. Some people don't run the agents on a VM on their own machine and opt for a VPS somewhere. And I was wondering if privacy and security had anything to do with their decision.
It's all fun and games until the model is smart enough to figure out privilege escalation, i.e. a lot of people don't realize Docker enabled on a regular user is enough for privilege escalation if you "follow the tutorials."
When I was in university in 2009, the student union I was in had set up their Linux computers with a small program that one of the members wrote, that had the suid bit set and would exec apt-get install passing the arguments along.
This way, all members of the student union were able to install any software they wanted to on the student union computers without having to give out blanket root access to the members. Only a select few members had full root access.
There’s other ways to achieve the same too.
And you can do this exact same sort of thing for the user that your agent runs as too, without having to give it access to do everything that root can.
The student union mainly kept the full root privileges restricted to a select few students to avoid accidental destruction rather than as a measure against maliciousness.
After you had been a member for a while and demonstrated that you mostly knew what you were doing, they’d give you full root access if you had some reason to want it that they agreed with.
And thanks to the dedicated suid program that exec’d into apt, wanting to install additional software was not a reason to be granted full root privileges since everyone could already install packages from the apt repositories this way without full root privileges.
Along with full root access came basically just a couple of simple rules, one of which was:
Do not abuse your root access to walk into other members home directories.
That rule was put in place after a previous member with root access had used the root privileges to copy the homework of another member into his own home directory without asking the other member for permission to see his work.
Aside from that one thing happening that one time, there hadn’t really been anyone doing anything malicious AFAIK. We were a rather small group of members in this student union, and it was a pretty chill and nice place. People came there to hang out, drink beer and tinker with electronics and computers.
There wasn’t much that root privileges could be abused for anyway. Regular members could already use all of the machines via graphical login at the desks, and remotely over ssh. Really the main two things anyone could have done maliciously would be to steal other people’s homework (like that one guy was kicked out for doing), or to steal credentials from others (no known cases of that happening there).
And if someone had started acting really maliciously, using the student union computers to attack the wider network, the university would have been on top of that real fast. The computer network of the student union was a subnet of the university network, and this university had a very competent crew of people watching over the university computer network as a whole.
A friend of mine once wondered how many computers were on the university computer network in total and did a port scan from one of the university computers (not from the student union computers). It did not take long from he started the port scan until university employees contacted him and gave him a stern talking to, and also told him the proper way find the answer to how many computers were on the university network.
I mean, if the execution happen on the VM then the problem is trust on the programs and then you can't trust any program by that logic? That or you think AI-companies software is serious slop.
I do, in fact, think the AI companies software is serious slop. I've read some of the Claude Code source.
And, we're not talking about hypothetical attacks here. Prompt injection attacks have happened. Supply chain attacks that agents fell for have happened.
I don't run anything but the agent and the project it's working on and the tools it needs to work on the project in the VM.
You can't see how the agent having no access to anything other than what it's working on is safer than the agent having access to my home directory with all of my credentials?
Look, you do whatever you want to do with your agents and your computer. I'm going to...contain them.
Seriously, you dont see any difference? A agent is non deterministic and may delete or change you data as a normal matter of operations. A browser, barring bugs or security issues, would not delete or modify the data you have outside the browser.
That's also true if you're running the agent directly on your laptop OS.
In that case, maybe you want VMs at hosting providers. There are companies building ephemeral VM and container orchestration layers for this kind of thing, I haven't played with them, though. It seems like a reasonable idea, though. One isolated environment per project or repo. Only the secrets needed for that one project and an agent that can't reach outside of it.
I've considered building something along those lines, and actually do run my security auditing benchmarks in containers automatically (that was originally to prevent the models from cheating, because you can disable network, but it has other pleasant side effects).
It's actually not that big of a lift these days to spin up containers on-demand and put just what's needed inside it (including the authentication info for the agent). I probably should automate it..right now I just have four permanent VMs setup for my various types of work: My day job, my open source projects, my benchmark and security work, and some side projects. Plus some temporary ones for experiments.
No, it actually continues running headless on the host, and you can reconnect from another laptop or mobile phone, or even ssh to the host and attach to the session. At least Codex desktop app works this way.
I've contributed to https://github.com/0xferrous/agent-box which allows you to bind-mount git repositories into containers that agents operate in, preventing the agents from accessing files that aren't bind-mounted. Your usual .gitignore can then be used to also ignore files within the repo to be bind-mounted, which prevents agents from accessing them at all, essentially working as a sandbox.
I also maintain https://github.com/nothingnesses/agent-images which allows you to use Nix to reproducibly spin up OCI container images containing agents and any other tools you need for development and use these with agent-box.
I use both at the moment to work on some personal projects with agents, where I set up multiple separate git worktrees for the agents to work in, preventing them from accessing anything outside of the worktrees and from trampling over each other's work.
In case anyone is interested, I'm also using bash scripts to run my agents in containers. It's simple, but has only bash and docker as dependency: https://github.com/asfaload/agents_container
a well-design IDE should abstract that away, i.e. run the agent in the headless VMs while give you an abstraction that you would feel like you are running the agent locally with all the benefits (editor, browser, diffs, debugger, etc)
I shared your fear some weeks/months ago so I was always using my harness in the cloud. However, latency started to become an issue when I traveled to other countries where I needed a VPN... so I ended up cooking skynot to be able to trust running my harness in my own computer: https://github.com/tarsgate/skynot (PRs welcome if you want to add support for another harness different than Pi)
What's your setup like and what do you use it for?
I have a M2 Max MBP with plenty of ram and I use VSCode + Zoo Code plugin with Qwen3-Coder-Next-GGUF:UD-Q4_K_XL to run local agentic coding sessions, but I'm intrigued by being able to run headless as I could probably run multiple instances in parallel to do stuff?
Like are you using UTM with some pre-built VM and a local LLM?
It's only a cli because they yanked out the opencode desktop code. (As well as the opencode go/zen model provider)
Edit: my theory is they wanted to mimic being the primary provider in a quick way with a lot of string replace. Though they could have added opencode back as a regular provider.
MiMo Code adds a lot of cool orchestration features to OpenCode! It definitely is NOT a quick find-replace job, it's genuinely someone's research project to create a better agent harness building on top of free software, and that's awesome. See https://mimo.xiaomi.com/blog/mimo-code-long-horizon
They did remove the opencode provider though and the desktop and web interfaces. I was trying to be charitable.
By the way, their repo was a bit weird with no changelogs at all. It seems to be picking up speed now with their communication. I actually read in the changelog just now that their Compose (plan/executre/review etc. something like that) flow is now deterministic with software instead of just prompts. That could be really good.
You're surprised? I think harnesses are almost as important as the underlying model. Folks have been able to improve benchmark results by nearly 2x based on harness alone.
Harnesses are quickly becoming critical components of the "model" itself imo. Not shocking to me at all that a company that spots a revenue opportunity is keeping its harness closed source.
I'm a neophyte. What makes a harness special or all that unique from another? I've had a reasonable experience with Zed and local models, but could be persuaded to put something else in the mix if there is a measurable benefit to be had.
Simple example: a while back LLMs would trip over questions like "how many Rs are in strawberry". Now, the system prompts have a line like "when a user asks for a count, actually count the value by calling a tool if needed". The LLMs cannot get smarter in this regard, next token predictors will hallucinate here.
A harness is that covering every blind spot or sub-optimal but probable output people have hit in the wild, and a lot of problems just have better solutions if you say "break problem A into subproblem B and subproblem C, then solve".
They might be sending some user requests to Anthropic to gather trading data for their own models. If they do so, perhaps they need to add some tracer to request that they prefer to hide.
Everyone should distrust them equally. Only local agents in a detached network namespace are safe from data leaks. It is perfectly reasonable to assume they are using our sessions to train on, since everything else short of nuclear launch codes is already there, and they need to keep feeding it.
The request would need to be done from their service, so as not to expose the API key, and because it just makes sense. They could probably directly proxy it and Wireshark couldn't catch it, due to everything being HTTPS. But people could probably catch it by decompiling, so it would make more sense to have the server make the request as part of a GLM request. Not that I think this is plausible - I'm not sure.
Verbally minimising potential threats is not a valid approach to managing risk. We have seen mass misuse of tokens acquired through nefarious means to distill models and enhance training as a way of catching up recently, among other related issues. It is quite appropriate to wonder what else might be going on.
Chinese Communist party? it would be funny if China didn't have laws related to companies in China exfiltrating foreign data and giving it to the government for espionage purposes, z.ai is a chinese company, based in the capital Beijing. The likelihood that they work with the government hand in glove is pretty high. I wouldn't run that binary on any machine I was doing anything serious with. If you ran it on a corporate network, I would hope security escorts you out of the building.
snowden's book, "Permanent Record" talks about the mass surveillance that he released in 2013. it makes no mention of AI companies sending data to the government. unless you can quote the exact language you're talking about in the book, I call BS on that.
secondly, you're claiming that it is the same in the US. there is no laws in the US requiring private companies to exfiltrate data and send it to the government en masse, like there is in China. these laws just don't exist, and if they did exist they would be ruled unconstitutional in violation of the Fourth amendment. As a matter of fact, last week Supreme Court decision in Chatrie v. United States came out on Monday, June 29, 2026 that affirmed that general warrants are a violation of the Fourth amendment, related to sweeping geofence warrants. so what you're talking about just does not exist. Yeah, I'm sure some companies, like Facebook, Google, etc have private agreements with government agencies to release data privately, these rules eventually are a violation of the Fourth amendment without a warrant.
to avoid any of this, I use open models with small providers that are very unlikely to be having private agreements with government agencies specifically to avoid that conflict. it's up to you to protect your own privacy. but to claim that the US government is doing this with AI companies, it's just flat wrong.
> "Permanent Record" talks about the mass surveillance that he released in 2013. it makes no mention of AI companies sending data to the government. unless you can quote the exact language you're talking about in the book, I call BS on that.
"Just after I arrived in Japan, Perot Systems was bought by Dell, the personal computer maker, which was trying to expand its business into IT support and corporate and government services. Overnight, my ID badges and paystubs changed, and I became a Dell employee. This meant that the US government was paying Dell for my services, and Dell was taking a cut of that money and passing the rest along to me."
It establishes a clear pattern of embedding US security apparatus within US businesses. I know the quote does not say "Anthropic" or "OpenAI", but I trust you can extrapolate the pattern.
Given that there's such severe concern being expressed by Anthropic about Claude being distilled, and the idea that the harness is part of the the moat, it doesn't seem super surprising that the other side of that would try to also make it harder for them to tell how well they're doing and what their approach is.
Why don't the major players open source their harnesses then? As far as I'm aware, the only time the source code for the Claude harness became available, it was due to a mistake (which is it's own whole thing).
I'm not saying you're wrong necessarily, but I do think that when the actions and words of a company conflict, it's a pretty safe bet that the words are just posturing and the actions better reflect their actual belief. In this case, regardless of what they're saying about software being easily writable now, they clearly seem to at least think there's something valuable in the harness if they're not open sourcing it.
I don't find a closed-source Chinese agent system trustworthy.
It is essentially a black box with full user permissions, meaning you are just handing over your entire system to a Chinese-owned server. With OpenCode and its GLM provider, at least I can monitor which files were read, which were edited, and what commands were executed.
Not to mention that Chinese national security laws legally obligate companies to cooperate with state intelligence and counter-espionage efforts [0]. If you have this installed on a corporate workstation, and your company is large enough, the possibility of them spying on you is not just a risk—it's almost a certainty.
I am not surprised it is not open source. These harnesses are hard to build - they are not just wrappers - and often they contain business logic that is not suitable for public distribution for all kinds of reasons.
Maybe they’re not “hard” to build, but some are sufficiently complex because they’re tailored to a model. If Z thinks their harness can improve on GLM’s shortcomings, that can give them a tiny edge, I guess?
Dunno. I’ve moved to Pi for most of my work and it’s finally better than Claude Code for me; BUT the Anthropic models are definitely better in CC itself.
