open-webui/desktop

Fork 0

mirror of https://github.com/open-webui/desktop.git synced 2026-11-05 01:27:46 +00:00

[GH-ISSUE #220] [Bug]: Windows desktop updater can corrupt embedded runtime on locked file and survive reinstall #136

New issue

Open

opened 2026-10-18 14:06:26 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-18 14:06:26 +00:00

Owner

Originally created by @Daevalus on GitHub (Jun 1, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/220

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\<user>\AppData\Local\Programs\open-webui
Runtime/data dir: C:\Users\<user>\AppData\Roaming\open-webui

What happened

The desktop app:

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

Evidence from logs

From C:\Users\<user>\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\<user>\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\<user>\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:

Fully stop all Open WebUI desktop processes.
Disable desktop auto-update in C:\Users\<user>\AppData\Roaming\open-webui\config.json.
Delete C:\Users\<user>\AppData\Roaming\open-webui\python.
Let the app rebuild the runtime.
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

Do not mutate the currently running embedded runtime in place.
Preflight-check for locked files/processes before package updates.
If update fails, do not continue startup with partial state.
Validate critical imports after update, for example:
- open_webui
- pydantic_core
- uvicorn._subprocess
Offer a clean runtime rebuild path on reinstall or startup repair.
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.

Originally created by @Daevalus on GitHub (Jun 1, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/220 ## 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\<user>\AppData\Local\Programs\open-webui` - Runtime/data dir: `C:\Users\<user>\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\<user>\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: ```text [2026-06-01 04:43:19.855] [info] error: failed to remove file `C:\Users\<user>\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\<user>\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: ```text ModuleNotFoundError: No module named 'uvicorn._subprocess' ``` And the main server failed with: ```text 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\<user>\AppData\Roaming\open-webui\config.json`. 3. Delete `C:\Users\<user>\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.

bsakaguchi commented

2026-10-18 14:06:27 +00:00

Author

Owner

@Werve commented on GitHub (Aug 21, 2026):

Offer a clean runtime rebuild path on reinstall or startup repair.

I encountered a similar issue after trying to force an update using the “Update” button in the GUI; the open-webui module would no longer start properly, not even after reinstalling it from the setup or using the “Uninstall Module” button in the UI.
I resolved this by removing the “open-webui\python\Lib\site-packages” folder and restarting from the desktop app’s setup to re-select the reinstallation from scratch, while keeping the same folder to preserve the data.

I then analyzed the differences and it appears that the following packages were missing from the previous corrupted installation:
open-webui\python\Lib\site-packages\fastapi
open-webui\python\Lib\site-packages\fastapi-0.136.3.dist-info
open-webui\python\Lib\site-packages\google
open-webui\python\Lib\site-packages\lxml
open-webui\python\Lib\site-packages\lxml-6.1.1.dist-info

@Werve commented on GitHub (Aug 21, 2026): > 5. Offer a clean runtime rebuild path on reinstall or startup repair. I encountered a similar issue after trying to force an update using the “Update” button in the GUI; the open-webui module would no longer start properly, not even after reinstalling it from the setup or using the “Uninstall Module” button in the UI. I resolved this by removing the “open-webui\python\Lib\site-packages” folder and restarting from the desktop app’s setup to re-select the reinstallation from scratch, while keeping the same folder to preserve the data. I then analyzed the differences and it appears that the following packages were missing from the previous corrupted installation: open-webui\python\Lib\site-packages\fastapi open-webui\python\Lib\site-packages\fastapi-0.136.3.dist-info open-webui\python\Lib\site-packages\google open-webui\python\Lib\site-packages\lxml open-webui\python\Lib\site-packages\lxml-6.1.1.dist-info

No labels

help wanted

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/desktop#136

No description provided.

Rows
Columns