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

[stephensams]

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

[jo23sh]

Also on 4.90.0 (238679), macOS 26.6.2, Apple Silicon, DMG install.

Looks like a startup race, not a broken idempotency marker:

• Only happens on the first start after a boot. Quit + relaunch never prompts for me.
• macOS seems to clear /var/run at boot, so the symlink is actually gone.
• The backend checks ~3.5s after start, finds it missing, and prompts.
• com.docker.socket then creates the symlink 8-9s later anyway.

boot 09-05 16:08   prompt 16:09:35.5   LaunchDaemon 16:09:43.3   (+7.8s)
boot 09-07 16:57   prompt 16:58:15.6   LaunchDaemon 16:58:23.7   (+8.1s)
boot 09-08 07:39   prompt 07:42:55.1   LaunchDaemon 07:43:03.9   (+9.1s)

The prompt also seems to be unnecessary. I cancelled it this morning, never entered a password, and /var/run/docker.sock appeared 9s later regardless — so Escape may work as a workaround.

Waiting for com.docker.socket before escalating would presumably avoid it.

[stephensams]

Thanks — confirming your findings from this side, on three more machines (all 4.89.0 / 238018, Apple Silicon, macOS 26.6.2):

Cancelling works, 3/3. At the boot prompt, pressing Esc instead of entering the password: /var/run/docker.sock appears on its own seconds later and docker ps is healthy on all three. No password ever entered.

Correction to my issue text: plain quit + relaunch does NOT prompt here either (3/3). My original "a quit + relaunch prompts too" observation immediately followed a hand-edit of settings-store.json (during the RequireVmnetd isolation test), which evidently triggered a config apply of its own. With settings untouched, relaunch is silent — consistent with your boot-only race.

So across the two reports: brew-cask installs of 4.89.0 and DMG delta updates to 4.90.0 behave identically — boot-only prompting, redundant escalation, safe to dismiss. That fits the startup race, not a broken marker.

[louis-lau]

I have the same issue. I would like to note that copying and pasting LLM generated responses into an issue tracker, or having an "agent" automatically create issues, is a bit insulting towards the maintainers and other readers of this issue. Try and have the decency to at least write something yourself.

[jo23sh]

@louis-lau You are right, my Claude Code generated reply was way too verbose. I've cut it to the essentials now. Still, I believe it‘s valuable to add additional details and insights to an issue, regardless of the tool they were compiled with. 😉 That‘s also a way of respecting the maintainer‘s time.

Cheers to the Netherlands. 👋🏻