Thank you for writing/publishing this. I especially appreciate the prominent warning at the top not to mistake it for a production library and to suggest an alternative. (It’s surprising to me how often people forget to add disclaimers like that to their code.)
I agree with you, but I don't envy the maintainers. The problem is that it's really hard to tell if someone is skilled like you or just shoveling what an LLM wrote up to the maintainers to have them "figure it out." Honestly, getting a library hard forked and maintained by people that can keep up with the incoming PRs would be a relief to a lot of folks...
Oh, to be clear, there’s no way we’d want incoming code for these forks.
Incoming bug reports or design docs an LLM could implement? Sure.
Maybe something like the Linux approach (tree of well-tested, thematic branches from lieutenants) would work better. We’d be happy to be lieutenants that shepherded our forks back to upstream.
Thank you for matchlock! I’ve got Opus 4.6 red teaming it right now. ;)
I think a secure VM is a necessary baseline, and the days of env files with a big bundle of unscoped secrets are a thing of the past, so I like the base features you built in.
I’d love to hear more about the red team breakouts you’ve seen if you have time.
Ugh - yes. I’m seriously close to writing a chrome extension just to warn me or block pages that have that phrase…it’s irrational because there are so many legitimate uses, but they are dead to me.
I don't know man, I feel emboldened to keep using emdash exactly because I want to protest against people equating emdash with "AI reply" even though there are very legitimate uses for emdash.
This looks really cool and genuinely useful. I was about to submit this after seeing the mention in another thread!
Before I read your last line, I was about to ask about network sandboxing. I don’t know what the ideal feature set is, but I keep wanting a proxy or network filter that mitigates some of the “dumb” attack vectors for LLMs…
Thanks! For network sandboxing, I was thinking something like what Little Snitch can do, but more customized... maybe block POST requests and long GET request strings or anything that looks like too much code or secrets.
I’ll take a stab after just reading documentation. I’ve been waiting for a good open source “wrapper” for Claude Code that allows me to run it somewhere and expose it as an API to be driven by a thin client elsewhere, and this appears to be that.
Furthermore, it exposes both the main session manager API, allowing it to spawn new sessions, as well as the API to chat with any given session directly. (Many wrappers allow you to wrap a single Claude code session in an API, driven by tmux under the covers, but don’t expose the meta-API to manage the sessions themselves)
I would use it to write a mobile or web client for my “agents” running remotely, either on sprites.dev, or on my MacBook over tailscale. (I currently use a mobile terminal for this, and have a list of Claude Code wrappers to try, but this “feels” like a cleaner abstraction primitive to build around.)
The above might be wishful thinking on my part, but hopefully the OP will correct me.
For every dropbox that managed to build a business out of a feature, there are probably >1000 that didn't. But I guess this meme is a good way to kill off bad businesspeople.
reply