igorbark

the main thing i use it for that seems like a pain with other coding agents is my sandboxing workflow: i have a custom extension which allows the pi process to run on my laptop, keeping all my transcripts in one searchable place, while delegating all the bash and file system commands to a VM.

i haven't gotten around to it yet, but i'd also like to change how `Bash` functions on a basic level (and subagents), where rather than the agent picking a fixed timeout, it just gets notified with exponential backoff about commands that aren't done and then gets a turn to decide what to do with it.

having said that, i find it annoying and not empowering that basic things like subagents and web search aren't built in. the ideal to me seems to be an agent with polished extensions for all the common use cases that can be disabled if you do want to rewrite them. but i put up with the pain because i really want my pet feature ¯\_(ツ)_/¯

im not sure that there is a plug n play set up that will work for everyone, because as with any security boundary, each layer of hardening has a usability trade-off. i definitely feel you about the uncertainty of it all, how do you actually know everything is tight?

personally, i think either a VM or microVM is the way to go. these things are actually designed as security boundaries, as opposed to containers. and as compared to bubblewrap, you can just give the agent a whole FS to work with and run it in yolo mode, whereas with bubblewrap you have to manually bootstrap the availability of each individual dev tool and make sure its config dirs and package caches and etc are mounted in a secure way and still will probably hit perm errors all the time. and there's just way less isolation.

also, something that has limited support in harnesses but IMO would make a lot of sense is running the harness process in the host, but having all the tool calls and file system interactions delegated to the VM. that way you keep all your session data and auth keys on the main machine where it can never get into context. otoh it makes your harness part of the security boundary, so that's the trade-off.

there's also all the usability questions around how to actually get data in/out of the VM. i have a script which can push local git repos into the VM and then pull from them as a remote, so the VM can't initiate any connection with the host doesn't need to hold git credentials. but ig for someone who wants their agent to push straight to GitHub that's a waste of effort.

options i've tried or seen for the VM itself: - qemu + libvirt: takes some doing to wrangle it together, but very battle tested and configurable - crun-vm is a PoC of higher level integration layer between podman and qemu, which is a really cool way to go about it. seems maybe abandoned but i just think it's neat and very existing tools/standards oriented rather than starting a new project and brand so i mention - libkrun is a newer entrant, and several ppl have built wrappers around it: - microsandbox - smolvm (posted/discussed on here recently) - krunvm

this is all Linux oriented, it's all i know.

this logic does not hold up if the reason that labor is more expensive than parts is that the labor involved in creating those parts has been outsourced to a "shithole country"

if we're going to plug random puzzle games on this thread, IMO the most underdiscussed puzzle game of all time is Recursed, the only game i've played which properly explores recursion as a mechanic, and (MINOR SPOILER) the only game i've played which detects when you have created logical contradictions, and for each contradiction you achieve rewards you with a secret bonus level.

i definitely agree that it would've been nice to have images in the book as it was hard to get a sense of exactly how well Boquila was mimicking neighbouring plants!

but in reference to the linked article, i will say that the researchers interviewed in the book (and i got that sense for Zoe as well) were in agreement with you that the research didn't support a vision-based mechanism. but everyone agrees that the imitation is going on. the researchers in the book suggest a gene transfer-based mechanism instead! (mentioned briefly in your linked article)

i enjoy that i cannot tell whether this is written by an AI, or by a human pretending to be an AI. my guess is human pretender!

the biggest headache i had in particular was different ways of handling environment variables, but the different adapters at OpenNext have had a rolling list of caveats/unsupported features for as long as i've been following the project so i didn't want to outright say "full". hopefully the effort on Next's side to build a standardized adapter API will help with this!

that's great to hear, thank you for the update :)

probably adding a confirmation message the first time the alias is used for each command would be good, it would be nice to know when i'm invoking git and when i'm invoking a third party binary regardless of any exploit attempts!

culture war aside, there are many other more accurate ways to say "details omitted for brevity" than "obviously" and "it is easy to see that"

this is also something that makes me want a more interactive publishing format, though i understand the good reasons to stick to the static quo. if it's easy to see, it shouldn't be too hard to write out in a collapsible sidebar for those interested