If the Windows desktop app doesn’t respond when you click “Log in,” please try: restart the app/PC, turn off any VPN/proxy/security filters, then reset the Windows app (Windows Settings > Apps > Installed Apps > ChatGPT > three dots > Advanced options > Reset) . If it still won’t open the sign-in flow, confirm you can log in at https://chatgpt.com/auth/login and make sure you’re using the same sign-in method you originally used (e.g., “Continue with Google”) .
What Windows version are you on, and was ChatGPT installed via the Microsoft Store? Also, does clicking “Log in” open any browser window at all, or nothing happens?
restart the PC - No change
restart the app - No change
turn off any VPN/proxy/security filters - skipped as no VPN or proxy used. Will not turn off firewall.
Reset - No change
log in at https://chatgpt.com/auth/login - works as expected
OS Name: Microsoft Windows 11 Pro
Windows version: 10.0.26200 Build 26200
ChatGPT installed via the Microsoft Store? Yes
clicking “Log in” nothing happens? Yes
Same issue on ChatGPT Windows app 1.2026.133.0. Browser works. Login button does nothing after app reset/reinstall. Tested in a new Windows user profile and it fails there too. Clicking Login does not spawn a ChatGPT-owned msedgewebview2 process.
ME TOO. I’m reduced to using the browser verion. The App on my Android phone is fine but the Windows 11 app from the Windows APP store (just reiunstalled to no avail) doesn’t let me log in.
I can confirm the same issue on another independent Windows 10 PC.
Environment:
Windows 10 Pro 22H2, build 19045.6456
ChatGPT Windows desktop app from Microsoft Store, version 1.2026.133.0
ChatGPT Plus account
Symptoms:
The app opens and the list of previous chats may be visible, but opening any chat leaves the main pane blank.
After resetting/reinstalling the app, the Log in, Sign up, Settings, and other interface buttons do nothing at all.
The same account and all chat history work normally in the browser on the same PC.
Troubleshooting already performed:
Closed the app completely and restarted Windows.
Used Repair and Reset in Windows app settings.
Cleared the Microsoft Store cache.
Uninstalled and reinstalled the app from Microsoft Store.
Confirmed WebView2 Runtime is installed.
Temporarily disabled Avast completely; no change.
Confirmed DNS and HTTPS connectivity to ChatGPT/OpenAI domains.
This started today, June 27, 2026. It appears to be a regression affecting the Windows desktop app version 1.2026.133.0 rather than a local PC or account issue.
bug do Desktop versão 1.2026.133.0 com o log Unable to create cache / Access denied (0x5).
bug do Desktop versão 1.2026.133.0 com o log Unable to create cache / Access denied (0x5).
I just sent in an email titled “ChatGPT Windows app bug report”. It has the full details. I believe it’s related to a permissions issue when attempting to create cache files.
https://status.openai.com/, looking at the status, it doesnt seem our issue is being monitored over, can you please re verify with the team the priority of this bug to be monitored and cited to the public to keep an eye on? im left logged out from my subscription and unable to access it via chatgpt, and its been since 11 hours, a whole productive day…
I have exactly the same issue on Windows 10 IoT Enterprise LTSC & ChatGPT Desktop 1.2026.133.
What I’ve already ruled out:
Resetting the app
Uninstalling and reinstalling from Microsoft Store
Creating a brand new Windows user profile
Reinstalling / verifying WebView2 Runtime
Windows App Runtime is installed and healthy
Browser version works perfectly on the same machine and network
Logging in through the browser succeeds and hands control back to the desktop app
I also spent some time debugging the desktop app with Electron remote DevTools.
Here are the interesting findings:
The conversation API requests succeed (HTTP 200).
The SSE conversation stream contains the full conversation data (my prompt and the assistant response are present in the response).
The desktop app receives click events normally.
JavaScript execution and the DOM are working.
However, the conversation view never renders, even though the data is received successfully.
Additionally, I noticed multiple requests for ‘/cdn/assets/*.js’ returning:
HTTP 403
‘cf-mitigated: challenge’
The exact same asset URLs load normally in a regular browser on the same machine, while only the Electron desktop app receives the 403 responses.
This may be useful when investigating the issue because it looks like the backend is working correctly, but part of the desktop frontend fails to load, leaving the conversation pane empty and some UI actions non-functional.
I’m experiencing the same issue with the ChatGPT Windows desktop app from the Microsoft Store.
The browser version works normally on the same computer, but the desktop app does not process submitted prompts. I can type a prompt, but after pressing Send the prompt disappears, “Stop answering” appears, and the message is not added to the conversation. No response is generated.
The Log in button also does nothing, and Settings does not open. I already tried reinstalling the app, resetting it through Windows Settings, restarting the PC, and checking the browser version. The issue remains the same.
This seems limited to the Windows desktop app, not my account.
I can confirm this is exactly the same issue on my machine.
Environment:
Windows 11 25H2
ChatGPT Desktop 1.2026.133.0
ChatGPT Plus
Browser version works normally.
Additional findings that may help:
Reproduced on two different Windows user profiles.
Complete uninstall + App Reset + reinstall from Microsoft Store: no change.
Downloaded and installed the official MSIX package using winget download: same behaviour.
DISM /RestoreHealth and SFC /SCANNOW completed successfully after repairing Windows corruption, but the issue remained unchanged.
Windows App Runtime and WebView2 are present and healthy.
ProcMon did not reveal any obvious ACCESS DENIED or filesystem issue.
One interesting UI observation:
Clicking Log in in the left navigation sometimes only collapses the navigation pane instead of starting the authentication flow. This looks like a UI event handling issue rather than an authentication problem.
This appears reproducible on a healthy Windows installation.
