To me, there are more annoyances in V2, so many that I've switched harnesses to Pi (for now?). I think the hot-reload is another security misalignment. An agent should not be able to modify plugins and have that immediately reloaded for availability.
I switched to Pi last week, have not seen anything about self modification, but have seen a lot about security, the minimalism and customization by user are closest in common selling points from exiting users
you cannot have both and be serious about security
to be clear, I'm talking about hot reload, agent can manipulate its own environment in real time, that's asking for trouble, put some controls on that or reap the consequences from loss of control
Unless I’m out of the loop, Pi can self modify in the sense that plugins are just code it can edit. It doesn’t live reload that I’m aware of.
Pi’s whole UI is customizable, so a lot of people were having their agents build their own interfaces.
The distinction is probably irrelevant for most people. I secure the whole thing in a container, because I lack the willpower to audit a bajillion lines of LLM code just inside the harness.
Pi notably ships without MCP support (or it did, I can't remember if they're adding it to Pi main or just the durable one). From a vanilla Pi perspective, I'm pretty sure but not positive that it can't. It would have to install an MCP plugin, and you would have to re-launch Pi to load that plugin.
It does have native tools, but they're also in plugins that aren't hot-reloaded. The LLM would have to write the tool, you close Pi and re-open it before it was available.
> Would you consider that a gap in security posturing?
Honestly, I think trying to secure the harness is a lost cause for the same reasons SELinux never really took off. They solve a real problem in a way so painful people would rather just live dangerously.
I actually wrote a thing to implement my security posture https://github.com/SethCurry/abyss TLDR it pretends to be an ACP agent, but runs the agent inside Docker (with optional bind mounts) and proxies the ACP connection into the container.
I'm also tinkering with WASM-based plugins in the ACP proxy to add some additional security and compliance posturing at the protocol layer (ie agnostic to what the underlying agent is). E.g. I slapped together a plugin that will automatically cancel a prompt mid-turn if an OpenRouter API token shows up in a) the prompt, b) agent output/thinking, c) agent tool calls. ([1], [2], [3]). The grand vision is slapping centralized management on that so security and compliance teams get a "firewall" of sorts to prevent leaking secrets, filter bash commands, censor PII, yada, yada.
Hey, I agree that trying to secure the harness with bubblewrap or other case-by-case limitations is inherently unsatisfactory, and I also wrote an open-source agent container tool (on top of gVisor + Kubernetes, since it can run pretty much anywhere at the cost of some performance). In case you're interested, I'd love your feedback, and obviously feel free to take any pieces that are helpful. The transparent egress proxy in particular was a pain to figure out: https://yaac.dev/
I looked and will give it a try, but haven’t had a chance yet because life.
I had debated building something like this, and I really want to see what the other fork in the path looks like.
One of the core tenants of mine is to not impose a workflow or set of tooling on the user. I specifically opted not to go with k8s because access to local files is going to be a pain, and I think people will still expect that. There’s all sorts of “I need this binary that’s not in APT”, or “you need this cert to test, and we can’t commit it” stumbling blocks.
Yours feels like it’s pushing me into an unfamiliar workflow, but opinionated tools are often better so it’s worth a try.
My only direct criticism is that I think k8s is a bad way to go for this (but is probably what people expect). For personal use, k8s is more than I want to deal with. For work use, I suspect lambdas would be cheaper and avoid a ton of maintenance junk. We tend to think of agents as a persistent process, but they’re sort of not. They’re a stateless process that is effectively dead until a new message comes in, let it be dead until something else comes down the pipe.
Yes — it is currently a downside that idle sessions are taking up resources. However, you can currently stop and restart them and it saves your active workspace, even untracked files in git. And there is active kubernetes work to make saving memory state to disk and restarting significantly easier, which would significantly reduce the resource burden: https://github.com/kubernetes/kubernetes/pull/140186
I was talking about how I was looking for something like this earlier.
1. I can feel the claudisms coming through, a turnoff for me personally
2. You're shaving yourself short on a good pun
I'll still give it a look since I am in the market for a kubernetes based platform for dealing with lots of agents across harnesses. Scion was my goto, but I'm not so keen on that project anymore.
My ideal solution does not require a running server (CRDs should be sufficient) nor a UI, I want to start new agents in my existing automations.
Hey, thanks! Probably the way I’d handle your use case would be to run the automations themselves inside yaac containers, which is admittedly a bit heavyweight, but on the plus side you always have an agent available to monitor or edit them if you want.
Also, which lines on the website are the claudiest? I tried to edit out the tone, especially too many one-two punches, but to be honest couldn’t be bothered to write every word myself still
It's not one thing in particular, it's woven throughout from the structure and phrasing to the design and color choices, there is this general vibe to claude produced artifacts. Part of the problem is that so many people are using claude, we just see this more and it's become tiring, so even a modest amount carries more impact than average.
If you want humans to spend time reading and evaluating, put the human time into writing and editing.
More than fair —- I’m already a bit tired of the glitched out aesthetic that people are using to get away from LLM smell, so I was trying to avoid being too weird or non-standard with it. But I’ll try to give the aesthetics and wording another pass based on your feedback, I appreciate it
I'm using a number of @gotgene's plugins, they are really nice
I'm looking at porting my Dagger based env to Pi, mainly because it allows me to fork / time-travel the complete environment. One thing I really like about Pi is that /tree command and friends. It aligns really well with how container layer based env can be realized with the Dagger SDK.
> you cannot have both and be serious about security
Why not? I think DSH does this pretty well with an agent preset that exposes the tools required for the agent to modify the harness.
It's kind of like how the kernel can expose interfaces to allow userspace to load kernel modules at runtime: you "just" have to control which processes can use them.
Between that, and a couple of extra injected bwrap args to make my SSH keys and LLM API credentials unreadable from the agent's shell by default, I'm pretty comfortable using the harness outside of a VM for most things.
If an agent can change the harness it is running in, in real-time, all bets are off
There is semantic ambiguity here. An agent being able to write plugin code for the harness it runs in is related, but orthogonal, to the real-time or not availability of that plugin to the current session.
When I have my agents assist with plugins, I pay closer attention and either do the testing myself or have them run the altered harness in another instance.
Part of this is because they have borked themselves and it can be super annoying to undo their f-ups. Little qwen did this once, breaking its own connection to vllm.
I guess for me there is a distinction between an agent I am using interactively and walking through step-by-step, vs an agent that is running unattended, doing web search, communicating with subagents etc. I am ok with giving greater privilege to the former. But yes Qwen-chan accidentally committing suicide, or OOMing its own inference machine is a canon event.
It was more I let the agent work on my homelab setup and it wrote a bad config value, but I had to actually look at what it had done to figure it out...
I tried switching to Pi twice. Both times it seemed agents go crazy with tools on Pi and do stupid things right out of the gate, (like get `find` syntax wrong, seriously who [what] does that??). Plus things I appreciate in opencode (even if they were buggy in 1.x) like "prompt for perms tool-by-tool in this session" seem to only be available in Pi by writing your own extension, and now I'm wasting time debugging my extension with an AI that gets tools wrong and constantly wants to search `/` for no good reason.
Then I upgraded OpenCode to 2.0 and pretty much all the bugs vanished. I still wish there was a happy medium between "parse tool calls for perms" (which fails all the time if the tool call is long/complex enough) and a full-on sandbox, but otherwise 2.0 is really solid.
DeepSeek Harness allows the user/agent to build its own plug-ins and run them without restart, mostly. Pi and OpenCode were then influenced to do the same in their respective new versions. I don't know which has the better implementation.
DeepSeek does. The entire thing is composed on plugins, using a framework called Cordis. Everything is a plugin. All the tools, the models, plan mode, file system access, everything. You can change anything anywhere, even reconfiguring active plugins deep internally. Cordis provides an effect system so everything can be rewound on uninstall time. This is how people run local models or just other major models, just by writing a new plugin to talk to whatever instead of the deepseek api. The agent loop itself is a plugin and can be swapped out.
From what I read, OpenCode V2’s design is similar. It’s built around Effect, which seems to be gaining steam as a framework for building correct software.
Cordis also looks interesting as an alternative, but appears more bound to DSH rather than a more general thing (which I prefer).
Yes, that’s the thing I had mainly been looking at as an alternative. It probably has a better culture around extensions, but also seemed a good bit more DIY, especially to get it working with a good UI.
I do not see where Pi does any automatic hot-reloading, though I believe there is a /reload command one has to run that can do this. Still new to Pi, if you have a link, I'd be appreciative.
This is all a stopgap until I have some time to go back to my personal/custom harness.
1. Running background code on my machine is something that gets an immediate removal from me.
2. opencode 2.0 does not exists. I mean it: there is no release[1] and per their own instructions, `npm i -g @opencode/cli@latest` does not install opencode 2.0.
3. `Error: @opencode/cli's postinstall script was not run.` Not even running postinstall.js can fix that, neither on linux nor macos. And even if it works, in a couple of days or on the next upgrade it will fail again.
