The design decision I find most interesting here is ephemeral-by-default with opt-in checkpointing, that inversion of the usual "persist everything, clean up manually" model fits agent code execution well. Most sandboxing approaches I've seen treat isolation as the hard problem, but state leakage across runs is the subtler foot-gun when you're executing LLM-generated code repeatedly.
One thing I ran into building agent infrastructure: the boundary between "sandbox that runs code" and "agent that decides what code to run" wants to be a clean HTTP interface, not a library call. Makes it easier to audit what crossed the boundary. Does Shuru expose any hook for streaming stdout back to the caller during execution, or is it strictly "wait for exit, get result"?
Comments
The design decision I find most interesting here is ephemeral-by-default with opt-in checkpointing, that inversion of the usual "persist everything, clean up manually" model fits agent code execution well. Most sandboxing approaches I've seen treat isolation as the hard problem, but state leakage across runs is the subtler foot-gun when you're executing LLM-generated code repeatedly.
One thing I ran into building agent infrastructure: the boundary between "sandbox that runs code" and "agent that decides what code to run" wants to be a clean HTTP interface, not a library call. Makes it easier to audit what crossed the boundary. Does Shuru expose any hook for streaming stdout back to the caller during execution, or is it strictly "wait for exit, get result"?