[GH-ISSUE #267] [Bug] Open WebUI Desktop still shows Sign in after reinstall and local data reset #172

New issue

Closed

opened 2026-10-18 14:06:43 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

Originally created by @yenchalwarmonali60-dotcom on GitHub (Sep 2, 2026).
Original GitHub issue: https://github.com/open-webui/desktop/issues/267

Description

I encountered an issue with Open WebUI Desktop on Windows where the application continued to show only the Sign in page even after reinstalling the application and attempting to reset its local data.

I spent approximately 1 hour and 20–25 minutes troubleshooting this issue.

Environment

OS: Windows
Open WebUI Desktop version: 0.0.20
Installation: Windows desktop installer
Browser: Google Chrome
Local server: http://127.0.0.1:8080

What happened

I had installed Open WebUI several months ago but had not used it for approximately 2–3 months.

When I opened Open WebUI again, it showed a login page with:

Email
Password
Sign in

There was no visible Sign up / Create account option and no obvious password recovery option.

The same login page appeared both inside the Open WebUI desktop application and in Google Chrome at http://127.0.0.1:8080.

Troubleshooting

I checked Docker Desktop, but there was no Open WebUI container.

I checked Windows Task Manager and found uv.exe and Python processes associated with Open WebUI.

I then uninstalled/reinstalled Open WebUI.

After reinstalling, the same Sign in page appeared.

I also checked %APPDATA% and found an Open WebUI-related folder. I renamed the previous folder to:

Open WebUI-old

After launching Open WebUI again, a new Open WebUI folder was created.

However, the application still showed only the Sign in page.

The browser also showed the same login page.

At one point, http://127.0.0.1:8080 showed:

ERR_CONNECTION_REFUSED

After restarting/opening the application again, the login page became available.

Expected behavior

After reinstalling and starting with a fresh local installation, I expected a first-time setup screen or a Sign up / Create account option.

If previous account data is intentionally preserved after reinstalling, the application should clearly explain how to recover the existing account or perform a complete local reset.

Actual behavior

Even after reinstalling the application and renaming the apparent old Open WebUI data folder, the application continued to show only:

Email / Password / Sign in

A new folder was created, but there was still no obvious way to create a new account or determine which existing local data was being used.

Suggested improvement

It would be helpful to provide a clear first-run/recovery flow, such as:

Create new local installation
Recover existing installation
Reset local account/database

It would also be useful for the documentation to clearly explain which local files contain the Open WebUI database and what needs to be removed or renamed for a genuinely clean installation.

Additional information

The issue occurred both inside the desktop application and through Chrome using the local address http://127.0.0.1:8080.

I am reporting the observed behavior rather than assuming the exact root cause.

Originally created by @yenchalwarmonali60-dotcom on GitHub (Sep 2, 2026). Original GitHub issue: https://github.com/open-webui/desktop/issues/267 ## Description I encountered an issue with Open WebUI Desktop on Windows where the application continued to show only the **Sign in** page even after reinstalling the application and attempting to reset its local data. I spent approximately **1 hour and 20–25 minutes** troubleshooting this issue. ## Environment * OS: Windows * Open WebUI Desktop version: 0.0.20 * Installation: Windows desktop installer * Browser: Google Chrome * Local server: `http://127.0.0.1:8080` ## What happened I had installed Open WebUI several months ago but had not used it for approximately 2–3 months. When I opened Open WebUI again, it showed a login page with: * Email * Password * Sign in There was **no visible Sign up / Create account option** and no obvious password recovery option. The same login page appeared both inside the Open WebUI desktop application and in Google Chrome at `http://127.0.0.1:8080`. ## Troubleshooting I checked Docker Desktop, but there was no Open WebUI container. I checked Windows Task Manager and found `uv.exe` and Python processes associated with Open WebUI. I then uninstalled/reinstalled Open WebUI. After reinstalling, the same Sign in page appeared. I also checked `%APPDATA%` and found an Open WebUI-related folder. I renamed the previous folder to: `Open WebUI-old` After launching Open WebUI again, a new Open WebUI folder was created. However, the application still showed only the **Sign in** page. The browser also showed the same login page. At one point, `http://127.0.0.1:8080` showed: `ERR_CONNECTION_REFUSED` After restarting/opening the application again, the login page became available. ## Expected behavior After reinstalling and starting with a fresh local installation, I expected a first-time setup screen or a **Sign up / Create account** option. If previous account data is intentionally preserved after reinstalling, the application should clearly explain how to recover the existing account or perform a complete local reset. ## Actual behavior Even after reinstalling the application and renaming the apparent old Open WebUI data folder, the application continued to show only: **Email / Password / Sign in** A new folder was created, but there was still no obvious way to create a new account or determine which existing local data was being used. ## Suggested improvement It would be helpful to provide a clear first-run/recovery flow, such as: * Create new local installation * Recover existing installation * Reset local account/database It would also be useful for the documentation to clearly explain which local files contain the Open WebUI database and what needs to be removed or renamed for a genuinely clean installation. ## Additional information The issue occurred both inside the desktop application and through Chrome using the local address `http://127.0.0.1:8080`. I am reporting the observed behavior rather than assuming the exact root cause.

bsakaguchi closed this issue

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

bsakaguchi referenced this issue

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

[PR #172] [MERGED] 0.0.17 #221