I’d like to let you know of a tool I’m building as a “developer convenience” to better leverage agents, totally built on top of Incus: https://isx.run/
As many developers in my bubble, we were introduced last year to Claude Code and were blown away - but didn’t know Incus, most of the developers in my circle tried to use “devcontainers” or other forms of encapsulating Claude Code (and then also Codex and Pi, Bob,..) often into docker/podman containers - but that’s very limiting and definitely lacks on usability perks, such as nice integration with git, proper secrets handling, and much more .. I’m not here to sell you the tool (it’s OSS, Apache licensed), just to share my perspective on how this started to grow and how I found Incus. It’s great!
Many thanks to all for your work on Incus - and if you’d like to try my tool or have any questions / suggestions, I’d be very keen to hear about that as well.
If I understand this correctly, isx will prepare the system to use Incus (install it if it is not already installed) and install in instances the AI agents of our choice.
The big feature is that those AI agents do not get to be aware of any API key, because isx creates a transparent proxy with MITM capabilities to rewrite any HTTPS requests from the AI agents to add those API keys in the requests.
Yes, isx prepares Incus instances to be a good home for agents. I do this via a series of features - the MITM proxy is just one of them. My preferred one is the nice integration with git: I setup a management remote for your local projects so you can push/pull directly into the containers, while keeping strong isolation.
This combined with the ability to quickly “branch” an entire machine’s state via COW in a shared BTRFS pool, it gives a similar experience than using git worktrees - except the entire environment is contained, and any agent can install whatever they need autonomously to research complex issues.
There’s nothing here you couldn’t do with Incus directly, yet there’s a lot of practical benefits in having it all managed and setup to be more appealing to users needing a quick, isolated instance for some experiments. Also - while I’m using Linux myself, had several requests to have this work nicely on Mac; that was very hard to make it work reliably but it’s nice to have now.
I don’t have OpenCode support OOB at the moment - the people who tried this project so far have been using Claude Code, Codex, Bob and Pi. I’m happy to add OpenCode as well as an OOB option too - makes sense and shouldn’t be hard at all. I’m also adding gemini-cli this week as Gemini 4 seems worth a try. I’m doing about 2 releases per week so it won’t take long
Incidentally - adding tools like OpenCode could potentially be done simply by defining a tool via yaml file. But I’ll look into this myself soon, I’m not entirely sure a yaml definition would suffice in this particular case.
