Summary
After a successful clean installation on Windows 11, stopping the Podman WSL machine and relaunching the v0.10.0-alpha.2 CLI does not recover the runtime. The CLI enters environment preparation, fails to start Podman's user-mode networking, and cannot recreate the Omnideck container without manual changes inside the Podman WSL environment.
This is a non-blocking recovery edge case when the saved Podman machine is deliberately stopped. Normal clean installation, application use, and stable-to-alpha upgrade succeeded.
Tested environment
- Omnideck CLI: v0.10.0-alpha.2 (
c36d248d69e5)
- Windows 11 Pro 25H2, build 26200, x64
- WSL 2.7.11
- Podman 6.0.2
- Podman machine:
omnideck-runtime, rootless WSL machine
- Initial host state: WSL and Podman absent; both installed through the candidate's clean-host flow
Reproduction
- Start from a clean Windows 11 VM with WSL and Podman absent.
- Run bare
omnideck v0.10.0-alpha.2 and complete the recommended setup, including restart/resume.
- Verify the
omnideck container is running and http://localhost:2337 returns HTTP 200.
- Stop the runtime with
podman machine stop omnideck-runtime.
- Run bare
omnideck again.
Actual behavior
- The CLI routes into environment preparation instead of completing a stable runtime-repair flow.
- Starting the machine fails with exit status 125.
- The nested
podman-net-usermode WSL command exits 3.
- A subsequent manual
podman machine start omnideck-runtime succeeds, but host.containers.internal is absent inside the machine and getent ahostsv4 host.containers.internal exits 2.
- The CLI cannot recreate the Windows container until the VM is manually given a
192.168.127.254 host.containers.internal entry and WSL host-file regeneration is disabled.
Expected behavior
Bare relaunch should recognize the stopped saved runtime, present an actionable repair path, start or repair the Podman machine and its networking, and return the existing Omnideck instance to HTTP 200 without undocumented manual commands or configuration edits.
The existing application configuration and omnideck-home / omnideck-state volumes must remain intact, and the repair must not create a second machine or application instance.
Acceptance criteria
- Reproduce the stopped-machine state on a clean Windows 11 VM using the released Windows binary.
- Bare relaunch completes runtime repair without manual WSL or hosts-file changes.
host.containers.internal resolves from a recreated Omnideck container after repair.
- The original instance returns HTTP 200 with both persistent volumes and their data intact.
- Final inventory contains exactly one intended Podman machine, instance, container, and volume pair.
- Add or update Windows regression coverage for the stopped-machine path.
Release impact
Non-blocking Windows recovery edge case. Track it for improved self-repair behavior; do not treat it as a release blocker. The portable Windows contract, clean installation, and v0.8.0-to-alpha upgrade passed.
Summary
After a successful clean installation on Windows 11, stopping the Podman WSL machine and relaunching the v0.10.0-alpha.2 CLI does not recover the runtime. The CLI enters environment preparation, fails to start Podman's user-mode networking, and cannot recreate the Omnideck container without manual changes inside the Podman WSL environment.
This is a non-blocking recovery edge case when the saved Podman machine is deliberately stopped. Normal clean installation, application use, and stable-to-alpha upgrade succeeded.
Tested environment
c36d248d69e5)omnideck-runtime, rootless WSL machineReproduction
omnideckv0.10.0-alpha.2 and complete the recommended setup, including restart/resume.omnideckcontainer is running andhttp://localhost:2337returns HTTP 200.podman machine stop omnideck-runtime.omnideckagain.Actual behavior
podman-net-usermodeWSL command exits 3.podman machine start omnideck-runtimesucceeds, buthost.containers.internalis absent inside the machine andgetent ahostsv4 host.containers.internalexits 2.192.168.127.254 host.containers.internalentry and WSL host-file regeneration is disabled.Expected behavior
Bare relaunch should recognize the stopped saved runtime, present an actionable repair path, start or repair the Podman machine and its networking, and return the existing Omnideck instance to HTTP 200 without undocumented manual commands or configuration edits.
The existing application configuration and
omnideck-home/omnideck-statevolumes must remain intact, and the repair must not create a second machine or application instance.Acceptance criteria
host.containers.internalresolves from a recreated Omnideck container after repair.Release impact
Non-blocking Windows recovery edge case. Track it for improved self-repair behavior; do not treat it as a release blocker. The portable Windows contract, clean installation, and v0.8.0-to-alpha upgrade passed.