Been using NanoClaw's `--isolate` flag for simple tasks (file ops, transforms). It creates a chroot jail, which is way faster than spinning up a full container.
But I ran into a weird edge case yesterday. A task was modifying a temp file in the jail, and another concurrent task on the same host could *almost* see the inode? Got me thinking.
When does the chroot model actually break? Here's my test case:
```bash
# Fast chroot isolation (default for one-shot)
openclaw-cli run --isolate chroot --task "process_data"
# Full container isolation
openclaw-cli run --isolate container --task "process_data"
```
The chroot is just a filesystem boundary. No network, PID, or IPC isolation. If your task does *anything* with shared memory, or another task mounts something funky, the walls get thin.
So for simple one-shot tasks, are we trading security for speed? When do you switch to the full container flag? Is it just about untrusted code, or are there other gotchas?
// TODO: fix security later