fix(#558): write Docker Desktop autostart for a provisioned daily user - #623
Merged
Merged
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit de1634c. Configure here.
Set-DailyUserProvisioning only wrote the HKCU Run key when the provisioned user was the account running the installer ($user -eq $env:USERNAME). For a provisioned DIFFERENT daily user (the hospital IT-installs-elevated case), their registry hive isn't loaded, so no autostart was written and the code relied on --always-run-service. On the WSL2 backend dockerd runs inside the docker-desktop distro that the Docker Desktop GUI boots, so without the GUI autostarting on that user's login the engine isn't up after a reboot and the k3d containers have no daemon to restart into — the client is down until someone opens Docker Desktop manually. For the provisioned different user, drop a "Docker Desktop.lnk" into their Startup folder (same launch-at-logon mechanism as the Run key, no hive load needed). When they have no profile yet, name the one-click GUI setting to flip after first sign-in. The current-user Run-key path is unchanged. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…#558) scripts/install-k8s.ps1 changed in this branch; regenerate the signed integrity manifest via scripts/gen-manifest.sh so the "Static analysis" gate (gen-manifest.sh --check) passes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The cross-user Docker Desktop autostart path (Startup-folder shortcut for a
provisioned DIFFERENT daily user) can fail on Startup-dir creation, the
WScript.Shell COM object, or saving the .lnk. It was caught by the outer
`catch { Log ... }`, which logged but added nothing to $did. With docker-users
succeeding, the summary then printed a green "Configured for '$user'" with no
autostart note -- so IT left the elevated window thinking #558 was handled while
the daily user still had no autostart and the client is down after every reboot.
Append a manual-step note to $did on failure, mirroring the .wslconfig catch in
the same function, and name the one-click GUI remediation. Add source-guard
Pester tests for the Startup-shortcut feature and the new failure-note path;
refresh manifest.sha256.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
divyasinghds
force-pushed
the
fix/558-provisioned-user-docker-autostart
branch
from
August 6, 2026 11:04
de1634c to
2dd9e6c
Compare
Contributor
Author
|
Redundancy check vs develop's existing autostart machinery: verdict (a) — still needed and additive. Rebased onto current develop (now carrying #418 daily-user provisioning, #419
So the #558 cross-user Startup-folder shortcut fills a real gap that no merged develop machinery covers. No recommendation to close — keep the PR. The Bugbot silent-failure finding (autostart failing behind a green summary) is fixed in this push. |
saadqbal
approved these changes
Aug 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #558.
Fix
For a provisioned, different daily user, write a Docker Desktop Startup-folder shortcut in that user profile (the Run key can't reach their hive), closing the autostart gap that left the client down after reboot.
Files
scripts/install-k8s.ps1Validation
pwshunavailable in this env — please run on a Windows runner before merge.🤖 Generated with Claude Code
Note
Low Risk
Scoped to Windows install-script daily-user provisioning and summary strings; no auth, cluster, or runtime API changes.
Overview
Fixes #558: when IT runs the elevated installer for a different day-to-day user, Docker Desktop no longer relied only on the current user’s Run key or
--always-run-service, so after reboot the WSL2 engine and k3d stack could stay down until someone opened Docker Desktop manually.Set-DailyUserProvisioningnow branches on who the daily user is: same as the installer still uses the HKCU Run entry; a provisioned other user with a loaded profile gets a Startup folder.lnkviaWScript.Shell(hive-free logon autostart). Missing Docker Desktop, no profile yet, or COM/path failures are logged and reflected in$didwith explicit manual steps (mirror the existing.wslconfighonesty). Comments document why WSL2 needs the GUI path for the second user.scripts/manifest.sha256is updated forinstall-k8s.ps1. Pester tests assert the shortcut path strings and the “couldn’t set Docker Desktop autostart” fallback text.Reviewed by Cursor Bugbot for commit 2dd9e6c. Bugbot is set up for automated code reviews on this repo. Configure here.