It seems that the focus is on sandboxing file system access. This is great if you already know that “stateful disk access” is the only thing the command does!

It seems that the focus is on sandboxing file system access. This is great if you already know that “stateful disk access” is the only thing the command does! It would be interesting to think about how/whether to extend this to stateful network access. What would happen if I used try on a command that does something like create a GitHub pull request? Right now I believe the pull request gets created regardless of whether I commit the file system changes at the end. Some alternatives: 1. Block all network access, because the tool can’t reliably reason about what could be happening. 2. Block all network access, except accesses that look like HTTP GET requests (and maybe HEAD/OPTIONS requests). 3. Attempt to build some sort of request replay mechanism, so that if a command’s results aren’t committed, but the command is ~immediately re-run with slightly different options, HTTP responses for requests identical to those from the previous attempt are re-used without making the request a second time. Obviously all three have downsides in terms of how useful/complex/brittle they make the command. But maybe worth pondering at the least.