v0.10.4

[0.10.4] - 2026-07-27

Added

• Documented how to update winpodx (#734, thanks @realahmed7777). Users were reinstalling from scratch because there was no visible "how do I update" guidance. The homepage get-started page, README, and docs/INSTALL.md now spell out the update path per install method: re-running the curl one-liner upgrades an existing install in place (config and Windows VM untouched), including on Bazzite and other rpm-ostree hosts where the bare command now upgrades a prior venv install too; package installs update via the system package manager or a newer .deb/.rpm asset; AppImage users replace the file with the newer release asset.
• You can now expose only a chosen directory to the Windows guest instead of your whole home (#758, thanks @Graf-source). winpodx has always shared all of $HOME as \\tsclient\home, which means the guest can see your SSH keys, browser profiles, and everything else under it. The new pod.home_share setting lets you point that share at a single directory — winpodx config set pod.home_share ~/WinShare (or an absolute path outside your home, e.g. /data/windows-share) makes \\tsclient\home map to just that folder, and files outside it are no longer reachable from the guest. The default is unchanged (empty = the full home directory), so existing installs behave exactly as before; the setting takes effect on the next app launch, with no pod recreate needed.
• A "Windows Desktop" launcher entry now appears alongside your Windows apps (#769, thanks @jltorres60). It opens the full Windows desktop (the equivalent of winpodx app run desktop), so it's one click from the app menu instead of a terminal command. The entry lands in the same winpodx menu group as the per-app shortcuts, is installed by winpodx setup and winpodx app refresh, and is re-created by winpodx doctor --fix if it goes missing.
• Individual Windows apps can now carry their own RDP settings that override the global ones (#692, thanks @notnotno). Until now every app launched with the same rdp.* config, so a single misbehaving app forced a global compromise — e.g. dropping the whole session to software graphics to stop one heavy app from corrupting. You can now add an [rdp] table to an app's app.toml (under ~/.local/share/winpodx/apps/<slug>/ or discovered/<slug>/) and set scale, extra_flags, or multimon for that app alone. At launch the per-app values are merged over the global cfg.rdp (the app wins), and a per-app extra_flags is combined with the global one so an app flag overrides a global default on a FreeRDP duplicate-flag tie — for example extra_flags = "-gfx /gdi:sw" forces just one heavy app onto the legacy GDI path while everything else keeps the GFX pipeline. The same allowlist that guards the global extra_flags and the CLI --extra-args applies, scale is clamped to the usual 100–500 range, and unknown or invalid keys are ignored rather than failing the load. Overrides are preserved across discovery rescans, exactly like a hidden/shown choice.
• The telemetry / ads / widgets debloat presets cover more privacy surface (#696, thanks @GameSoul7Eugene). The three registry-tweak scripts pick up additional opt-outs, each with a matching restore in its undo sibling: activity history / timeline upload, handwriting and inking error/data collection, online speech recognition, typing-insights (implicit ink & text) collection, Windows feedback frequency (Siuf), cloud-search history (MSA / AAD / device), the "let websites access my language list" opt-out, and the Windows-10 taskbar Feeds (News and interests) keys alongside the existing Windows-11 widgets policy. The more aggressive entries from the original PR were intentionally left out of this subset — a CompatTelRunner.exe image-file-execution hijack, turning SafeSearch off, blocking Store app auto-updates, disabling the location sensor and the Connected Devices Platform service, and the cloud settings-sync toggles — as out of scope or an app-compat risk for a throwaway VM.

Fixed

• The winpodx provision path (what a fresh install.sh actually runs) now also defaults to 5 discovery retries. The earlier bump covered winpodx setup and the finish_provisioning default, but the provision CLI command kept its own --retries default of 2, so a fresh install still gave up after 2 attempts on a slow first boot. All the provisioning entrypoints (setup / provision / migrate / resume) are now consistent at 5.

• A --main upgrade or a purge + reinstall no longer silently keeps old code. winpodx's version string only changes at release, so the installer kept building winpodx-<same-version>; pip's wheel cache (~/.cache/pip/wheels) is keyed by name+version and survives uninstall.sh --purge (purge clears the install, not pip's cache), so pip would reuse a stale cached wheel and the freshly-cloned source never reached the venv. The installer now builds winpodx with --no-cache-dir, forcing a fresh build from the cloned source every time.

• Discovery retries up to 5 times on a slow first boot instead of 2. The guest's Start Menu enumeration can exceed the 180s-per-attempt timeout right after Sysprep (Defender scanning, heavy first-boot load), and two attempts weren't always enough, leaving the app menu empty until a manual winpodx app refresh. Each retry lands on a progressively idler guest, so more attempts turn a first-boot timeout into a populated menu; a normal boot still succeeds on the first attempt and never waits.

• The winpodx.org homepage now actually shows its non-English translations. The site loads a generated web/lang/translations.js bundle (not the per-language JSON), and there was no committed generator, so catalog edits (the recent --storage-dir/--storage-path clarification and this release's update note) never reached the live site in German/French/Italian/Japanese/Korean/Chinese. Added scripts/gen_web_i18n.py (run it after any web/lang/*.json edit) and regenerated the bundle.

• winpodx setup --storage-path / --win-iso were silently ignored when a leftover podman volume from an earlier attempt still existed (#767, thanks @realahmed7777). Deleting winpodx.toml does not remove the named volume, so setup found an existing install, kept the VM on the old disk, and skipped staging the custom ISO — and the only signal was a one-line note that scrolled off before the "Setup Complete" banner (dockur then logged a "BTRFS filesystem for /storage" warning on what the user expected to be their roomier ext4 path, and Windows downloaded anyway). Setup now surfaces a prominent, framed warning that names the requested path, the location still in use, and how to relocate (winpodx setup --migrate-storage --migrate-storage-target <path>) or start fresh (remove the old volume / winpodx uninstall --purge), and re-prints it right before the final banner so it survives scrollback. The storage-decision behaviour is unchanged — relocating an existing install still requires --migrate-storage; this only makes the ignore impossible to miss.

Contributors

Thanks to everyone who reported issues or contributed to this release: @realahmed7777 (#767, #734), @Graf-source (#758), @jltorres60 (#769), @notnotno (#692), and @GameSoul7Eugene (#696).