The tmpfs overlay approach is smart — writes never touch the host. We've been solving a related but different problem: running AI agent workloads (not just coding agents) in production Kubernetes clusters where the agents can't make outbound calls at all. Air-gapped environments where the LLM inference runs on-cluster via Ollama or vLLM.
The isolation model is different — instead of protecting the developer's machine, we're protecting the enterprise's network from the agent. NetworkPolicies + FQDN egress control per agent namespace.
Question: how do you handle persistent state across sessions? If the agent needs to remember what it learned from a previous run, does the tmpfs model break that?
Comments
The tmpfs overlay approach is smart — writes never touch the host. We've been solving a related but different problem: running AI agent workloads (not just coding agents) in production Kubernetes clusters where the agents can't make outbound calls at all. Air-gapped environments where the LLM inference runs on-cluster via Ollama or vLLM.
The isolation model is different — instead of protecting the developer's machine, we're protecting the enterprise's network from the agent. NetworkPolicies + FQDN egress control per agent namespace.
Question: how do you handle persistent state across sessions? If the agent needs to remember what it learned from a previous run, does the tmpfs model break that?
thanks! we have checkpoints for that, you can checkpoint a sandbox and fork it to start a new session (checkpointing is a terminal state)