4.89.0: "requires privileged access to apply configuration" prompt at every boot — the set-docker-socket privileged step re-runs on every backend start #651

Bug report

• I have tried with the latest version of Docker Desktop (4.89.0 is current)
• I have tried disabling enabled experimental features (none enabled; stock settings apart from the flags listed below)
• I have uploaded Diagnostics
• Diagnostics ID: available on request — the evidence below was pulled directly from the host logs and system state, and I'm happy to run specific commands or upload a bundle if useful.

Expected behavior

After the privileged-access grant succeeds once, subsequent boots and backend starts are silent — the privileged configuration has been applied and nothing about it has changed. This is exactly how 4.88.x behaves on the same machines.

Actual behavior

Since updating to 4.89.0 (238018), macOS shows the osascript admin prompt — "Docker Desktop requires privileged access to apply configuration. Enter your password to allow this." — at every boot and every backend start (a quit + relaunch prompts too). Entering the password succeeds and everything works normally; the next start prompts again, indefinitely.

Two identically configured machines were updated to 4.89.0 and both show the loop (2/2). A third identical machine still on 4.88.1 (237512) remains silent (0/1). All three were silent on 4.88.x before the update.

What the recurring prompt actually runs (host-log osascript, decoded)

~/Library/Containers/com.docker.docker/Data/log/host/ retains the generated do shell script ... with administrator privileges sources. Base64-decoding the arguments of the recurring "apply configuration" entries gives, in every instance:

/tmp/docker-desktop-privileged<N>/cmd --errfile /var/folders/.../T/errors<N> config --user <user> set-docker-socket

— the default-docker-socket step alone. By contrast, entries carrying set-vmnetd set-docker-socket appear only at install/update time, under the different prompt text "Docker Desktop requires privileged access to configure privileged port mapping" — those are one-time and behave correctly. (The embedded cmd binary's md5 in the log entries also differs between the 4.88.x-era install entry and the 4.89.0 entries — 8177df56… vs 44d2c73f… — as you'd expect across versions.) Full raw osascript blocks are preserved and available.

The applied state is correct after every grant — the re-check is what fails

• /Library/LaunchDaemons/com.docker.socket.plist and /Library/PrivilegedHelperTools/com.docker.socket refresh their mtimes at each granted prompt (most recently at that morning's boot), i.e. the apply genuinely runs and succeeds.
• /var/run/docker.sock -> ~/.docker/run/docker.sock exists and is correct after every boot.
• sudo launchctl print system/com.docker.socket shows the daemon registered with the correct program/arguments (state "not running / active count 0" between runs, consistent with its run-once-at-boot design).
• com.docker.vmnetd is registered and healthy — state = running, active count = 1 — and its plist/binary mtimes remain at install time, consistent with the recurring run not including set-vmnetd.
  So each grant applies successfully, yet on the next backend start 4.89.0 again concludes the docker-socket configuration needs privileged (re)application. It looks like the already-configured / idempotency check for that component regressed in 4.89.0 — either the success marker isn't being recorded, or the comparison can never match.

Isolation tests already done

• settings-store.json is intact and standard on both affected machines: AutoStart: true, EnableDefaultDockerSocket: true, DockerBinInstallPath: "system", OpenUIOnStartupDisabled: true, RequireVmnetd: true.
• Removing RequireVmnetd (Docker fully quit, key deleted, two reboots): no change — the loop is not vmnetd-related. Key restored afterwards.
• 4.89.0 landed via a clean brew reinstall --cask docker-desktop on both affected machines (not an in-place delta update), so a dirty upgrade is unlikely.
• Unmanaged personal machines; no proxies or MDM policies; recommended (admin) install flow; System CLI install location.

Steps to reproduce

1. Docker Desktop 4.89.0 on Apple Silicon macOS, "Allow the default Docker socket to be used" enabled, System CLI install.
2. Reboot (or quit and relaunch Docker Desktop).
3. Admin prompt appears; enter password; Docker runs normally.
4. Reboot again → the same prompt appears again. Repeats on every start.

Information

• Docker Desktop 4.89.0 (238018) — loop present on 2/2 machines; 4.88.1 (237512) — silent on the same hardware/config
• macOS: 26.6.2 (build 25G83) — Apple Silicon (arm64), two machines
• Install: Homebrew cask docker-desktop; Docker autostarts at login; AutoStart: true

Platform

macOS

Version information

Client:
 Version:           29.7.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        a7dcaa6
 Built:             Wed Aug  5 18:27:50 2026
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.89.0 (238018)
 Engine:
  Version:          29.7.2
  API version:      1.55 (minimum version 1.40)
  Go version:       go1.26.5
  Git commit:       6a43e3d
  Built:            Wed Aug  5 18:28:35 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.3.3
  GitCommit:        aad11006b869517fcd3009450b6f82da282e1a9b
 runc:
  Version:          1.4.3
  GitCommit:        v1.4.3-0-gbb14dabe
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Client:
 Version:    29.7.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  agent: Docker AI Agent Runner (Docker Inc.)
    Version:  v1.127.0
    Path:     /Users/stephensams/.docker/cli-plugins/docker-agent
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.30.0
    Path:     /Users/stephensams/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.36.1-desktop.1
    Path:     /Users/stephensams/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.5.0
    Path:     /Users/stephensams/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     /Users/stephensams/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.4.3
    Path:     /Users/stephensams/.docker/cli-plugins/docker-desktop
  dhi: CLI for managing Docker Hardened Images (Docker Inc.)
    Version:  v0.0.7
    Path:     /Users/stephensams/.docker/cli-plugins/docker-dhi
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/stephensams/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/stephensams/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.43.3
    Path:     /Users/stephensams/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.2.6
    Path:     /Users/stephensams/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.6.13
    Path:     /Users/stephensams/.docker/cli-plugins/docker-offload
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.2.2
    Path:     /Users/stephensams/.docker/cli-plugins/docker-pass
  sandbox: "docker sandbox" is deprecated, use Docker Sandboxes instead (Docker Inc.)
    Version:  v0.13.0
    Path:     /Users/stephensams/.docker/cli-plugins/docker-sandbox
  scout: Docker Scout (Docker Inc.)
    Version:  v1.24.0
    Path:     /Users/stephensams/.docker/cli-plugins/docker-scout

Server:
 Containers: 4
  Running: 4
  Paused: 0
  Stopped: 0
 Images: 7
 Server Version: 29.7.2
 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: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: aad11006b869517fcd3009450b6f82da282e1a9b
 runc version: v1.4.3-0-gbb14dabe
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 7.0.12-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 10
 Total Memory: 7.651GiB
 Name: docker-desktop
 ID: be0c0147-9282-4c4b-8685-919a82f9507b
 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/stephensams/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