Docker Sandbox microVM stops after ~25-35 minutes despite Resource Saver being disabled

[ocstudio01012000-dot]

Bug report

Description

Docker Sandbox microVMs stop automatically after approximately 25-35 minutes of running, even with Resource Saver
disabled (useResourceSaver: false) and macOS App Nap disabled (NSAppSleepDisabled: YES). The sandbox runs a
long-lived Node.js process (detached via docker sandbox exec -d) with active network connections (Discord WebSocket,
API calls). PID 1 is sleep infinity.

Environment

• Docker Desktop: 29.2.1
• Docker Sandbox: v0.12.0
• macOS: 26.3.1 (25D771280a)
• Hardware: Apple M4 Max
• Virtualization Framework: enabled

Steps to Reproduce

1. Create a sandbox: docker sandbox create --name test -t <image> shell /path/to/workspace
2. Start a long-running detached process: docker sandbox exec -d test bash -c 'while true; do sleep 1; done'
3. Verify PID 1 is sleep infinity and detached process is running
4. Wait 25-35 minutes
5. docker sandbox ls shows stopped (or running with dead VM — see zombie state below)

Observed Behavior

The sandbox stops after 25-35 minutes. Two failure modes observed:

Mode 1: Clean stop

• docker sandbox ls shows stopped
• docker sandbox exec auto-restarts the VM but previous processes are gone

Mode 2: Zombie VM (more dangerous)

• docker sandbox ls shows running
• docker sandbox exec fails with: failed to start VM: create SDK client: socket path is empty
• The sandbox is stuck — only docker sandbox rm + recreate fixes it

What We've Ruled Out

Hypothesis	Tested	Result
Resource Saver	Disabled via Settings UI, confirmed useResourceSaver: false in Docker Desktop logs	Still stops

|
| macOS App Nap | defaults write com.docker.docker NSAppSleepDisabled -bool YES | Still stops |
| macOS sleep | pmset -g shows sleep 0, prevented by multiple processes | Mac never sleeps |
| No VM activity | Added keepalive writing to /tmp every 20s inside VM | Still stops |
| No host-side activity | Added docker sandbox exec ping every 25s from host | VM still dies (masked as zombie) |
| Gateway crash cascade | Sandbox stops even when gateway is healthy and serving requests | Not process-specific |

Timing Data

Watchdog script monitoring every 30 seconds. Crash intervals from a single overnight session (all times PDT):

00:21 → 00:56 (35 min)
00:56 → 01:31 (35 min)
01:31 → 02:06 (35 min)
02:06 → 02:40 (34 min)

After disabling Resource Saver, intervals varied (25-35 min) but crashes continued.

Expected Behavior

A sandbox with active processes should remain running indefinitely, especially with Resource Saver disabled. The
documentation states: "Sandboxes persist until you remove them."

Workaround

We run a watchdog script on the host that:

1. Detects the zombie state (socket path is empty error)
2. Runs docker sandbox rm + docker sandbox create from a saved template
3. Restarts the application inside the sandbox

This is disruptive (all in-flight connections drop, ~15s downtime) but functional.

Request

1. Is there a sandbox-specific idle timeout separate from Resource Saver? If so, can it be configured or disabled?
2. The zombie VM state (status: running but socket path is empty) should be detected and surfaced properly in
   docker sandbox ls.

Platform

macOS

Version information

Client:
 Version:           29.2.1
 API version:       1.53
 Go version:        go1.25.6
 Git commit:        a5c7197
 Built:             Mon Feb  2 17:16:37 2026
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.65.0 (221669)
 Engine:
  Version:          29.2.1
  API version:      1.53 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       6bc6209
  Built:            Mon Feb  2 17:16:47 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Client:
 Version:    29.2.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  agent: create or run AI agents (Docker Inc.)
    Version:  v1.29.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-agent
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.19.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.32.1-desktop.1
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.3.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-desktop
  dhi: CLI for managing Docker Hardened Images (Docker Inc.)
    Version:  v0.0.1
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-dhi
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.40.1
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.1.5
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.5.70
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-offload
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.0.24
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-pass
  sandbox: Docker Sandbox (Docker Inc.)
    Version:  v0.12.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-sandbox
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.20.1
    Path:     /Users/oc_studio/.docker/cli-plugins/docker-scout

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 12
 Server Version: 29.2.1
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.76-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 14
 Total Memory: 7.652GiB
 Name: docker-desktop
 ID: 3f9d6cf1-8d7a-4d0b-be26-36830a1fe411
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/oc_studio/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Diagnostics ID

No response

[ocstudio01012000-dot]

Root Cause Found

After deeper investigation, I found the exact cause in Docker's own sandbox daemon logs.

The Log Entry

In ~/Library/Containers/com.docker.docker/Data/log/host/docker-sandbox.log*:

{
  "time": "2026-03-22T01:30:53.61471-07:00",
  "level": "INFO",
  "msg": "stopping idle VM (exceeded idle timeout)",
  "vm_name": "openclaw-prod",
  "idle_duration": 2068977483792,
  "idle_timeout": 1800000000000
}

idle_timeout: 1800000000000 nanoseconds = exactly 30 minutes. This matches the ~30-35 minute crash window I reported.

The Flag Exists But Is Inaccessible

Running strings on the sandbox plugin binary (~/.docker/cli-plugins/docker-sandbox) reveals:

--vm-idle-timeout
Idle timeout for VMs, if 0 VMs will not be stopped due to idling (e.g., 5m, 10m, 1h)

And the Go source path: github.com/docker/sandboxes/sandboxd/pkg/server.WithVMIdleTimeout

This flag is passed to the internal sandboxd daemon but is not exposed through:

• docker sandbox create CLI
• docker sandbox global options
• Docker Desktop settings (settings-store.json)
• The Docker Desktop UI

What Doesn't Reset the Idle Timer

• Non-interactive docker sandbox exec calls (e.g. docker sandbox exec $NAME echo alive) — these do NOT count as activity
• In-VM processes — running servers, active network connections, keepalive loops writing to files
• NSAppSleepDisabled / macOS power settings
• UseResourceSaver: False in Docker Desktop settings — this is a separate mechanism

What DOES Reset the Idle Timer

• Persistent interactive exec sessions (docker sandbox exec -i) — an open -i session prevents the idle timeout from firing

What Counts as "Idle"

Docker's sandbox daemon tracks activity at the host-level session layer. It appears to only consider persistent TTY/interactive sessions as "active." All other sandbox usage — including programmatic exec calls, active network traffic inside the VM, and running processes — is invisible to the idle detector.

Workaround

Keep a persistent interactive exec session open from the host:

docker sandbox exec -i $SANDBOX bash -c 'while true; do sleep 60; echo keepalive; done' < /dev/null > /dev/null 2>&1 &

This is hacky but prevents the idle timeout from firing. The in-VM keepalive loop (writing to /tmp/.keepalive every 20s) that the sandbox docs suggest does NOT work.

Request

1. Expose --vm-idle-timeout — either as a docker sandbox create flag, a global docker sandbox config, or a Docker Desktop setting. The flag already exists internally; it just needs a UI.
2. Allow --vm-idle-timeout 0 to fully disable idle stopping, as the flag description already suggests ("if 0 VMs will not be stopped due to idling").
3. UseResourceSaver: False should disable this — users who explicitly turn off Resource Saver expect Docker to stop shutting things down. Having a separate, undocumented idle timeout undermines that setting.
4. Non-interactive exec should count as activity — if a host process is actively running docker sandbox exec commands every 30 seconds, the VM is clearly not idle.
5. Document this behavior — the current docs say sandboxes "persist until you remove them," which is misleading when there's a hidden 30-minute idle kill.

Zombie VM Explained

This also explains the "zombie VM" failure mode (status: running, but exec fails with "socket path is empty"). It's likely a race condition: the idle timeout fires and begins stopping the VM while a concurrent exec or reconnect attempt sees it as still "running" in the registry. The VM's socket gets torn down mid-operation, leaving an inconsistent state.