[Bug]: Windows desktop updater can corrupt embedded runtime on locked file and survive reinstall

[Daevalus]

Summary

On Windows desktop v0.0.20, Open WebUI can corrupt its own embedded runtime under C:\Users\<user>\AppData\Roaming\open-webui\python when it updates that runtime in place while files are still in use.

After the failed update, the desktop app continued startup with a partially updated environment, causing import failures such as:

• ModuleNotFoundError: No module named 'pydantic_core'
• ModuleNotFoundError: No module named 'uvicorn._subprocess'
• open-webui package is not installed

A normal uninstall/reinstall of the desktop app did not fix it because the broken runtime persisted under the roaming data directory.

Environment

• Open WebUI Desktop: 0.0.20
• OS: Windows 11 (10.0.26200)
• Embedded Python downloaded by the app: 3.12.13
• App install dir: C:\Users\gizmo\AppData\Local\Programs\open-webui
• Runtime/data dir: C:\Users\gizmo\AppData\Roaming\open-webui

What happened

The desktop app:

1. Downloaded and installed its embedded Python runtime successfully.
2. Installed open-webui and dependencies successfully.
3. Then attempted another package update against that same live runtime.
4. That update failed on a locked file.
5. The app then continued with a partially corrupted runtime.

Evidence from logs

From C:\Users\gizmo\AppData\Roaming\open-webui\logs\main.log:

Initial install succeeded:

• Installed 263 packages in 10.94s
• Included:
  • pydantic==2.12.5
  • pydantic-core==2.41.5
  • open-webui==0.9.5

Then a later update attempted to mutate the same runtime and failed:

[2026-06-01 04:43:19.855] [info]  error: failed to remove file `C:\Users\gizmo\AppData\Roaming\open-webui\python\Lib\site-packages\uvicorn\logging.py`: The process cannot access the file because it is being used by another process. (os error 32)
[2026-06-01 04:43:19.872] [info]  Package install exited with code 2
[2026-06-01 04:43:19.872] [warn]  [server] Auto-update failed, starting existing version: Error: error: failed to remove file `C:\Users\gizmo\AppData\Roaming\open-webui\python\Lib\site-packages\uvicorn\logging.py`: The process cannot access the file because it is being used by another process. (os error 32)

After that, helper components were already broken:

ModuleNotFoundError: No module named 'uvicorn._subprocess'

And the main server failed with:

ModuleNotFoundError: No module named 'pydantic_core'

I also verified from the bundled Python environment that pydantic was present while pydantic-core was not.

Actual behavior

• The updater can leave the embedded runtime in a partially updated/broken state if a package file is locked.
• Startup continues instead of rolling back or rebuilding.
• Reinstalling the desktop app binary does not necessarily fix it because the broken runtime under AppData\Roaming\open-webui remains.

Expected behavior

If the runtime update fails because files are locked, the desktop app should:

• not continue with a partially mutated runtime
• either roll back to a last known-good runtime
• or wipe/rebuild the embedded runtime automatically
• or update a new runtime directory and switch over atomically after validation

Recovery that worked

The reliable recovery path here was:

1. Fully stop all Open WebUI desktop processes.
2. Disable desktop auto-update in C:\Users\gizmo\AppData\Roaming\open-webui\config.json.
3. Delete C:\Users\gizmo\AppData\Roaming\open-webui\python.
4. Let the app rebuild the runtime.
5. Reinstall the missing open-webui==0.9.5 package into the bundled runtime manually.

After that, the desktop app started correctly and served HTTP 200 on the local backend.

Suggested fixes

1. Do not mutate the currently running embedded runtime in place.
2. Preflight-check for locked files/processes before package updates.
3. If update fails, do not continue startup with partial state.
4. Validate critical imports after update, for example:
   • open_webui
   • pydantic_core
   • uvicorn._subprocess
5. Offer a clean runtime rebuild path on reinstall or startup repair.
6. Consider making uninstall/reinstall optionally wipe or rebuild the roaming runtime tree.

Why I think this belongs in the Desktop repo

The failure path appears to be in the desktop app's embedded-runtime lifecycle and updater behavior on Windows, not just in open-webui package dependency resolution by itself.