I need human technical review of a persistent ChatGPT/Codex Windows desktop service issue and a supported way to prevent it.
Over weeks/months, consecutive reboots repeatedly produced two service token errors and two AppX errors. Uninstalling the ChatGPT desktop app stops the recurring errors; reinstalling it makes them return. I have observed this across earlier builds, clean Windows installations and each of the other devices I tested. It is not limited to the current version. App reset and reinstalling Windows have not solved it. The app need not be launched and no coding task is required.
My existing report and technical evidence are here: openai/codex #50719. This is my own report; I am not presenting it as an independent second user’s confirmation. The new follow-up with the latest captured evidence is openai/codex #51528.
The errors are:
Application — CodexSandboxService.OpenAI.Codex — Event ID 1003 (twice):
unable to restore package uninstall listener: open the logged-in user's token: Er is geprobeerd te verwijzen naar een token dat niet bestaat. (os error 1008)
Microsoft-Windows-AppXDeployment/Operational — Event ID 302 (twice):
Failed to start system service: appxsvc with error: 0x8007045B.
The Dutch token message is ERROR_NO_TOKEN: Windows could not supply the requested user token. The code uses WTSQueryUserToken for the installation owner’s primary Windows logon access token, to restore the package-uninstall listener. It is not a missing ChatGPT login/API token or a file to replace.
Current environment, for identification: Windows 11 Pro x64, 26H2, build 26300.9550; Store package OpenAI.Codex 26.930.7945.0; bundled CLI 0.160.1; ChatGPT Plus. The service is Automatic / LocalSystem and running. Its startup-type control in Services is greyed out because this is a packaged service.
Recent measured exceptions: two normal reboots on 7 October 2026 produced no new token errors. Belgian time, UTC+2:
- Failing boot at 01:48:40.500: the two token errors occurred around 01:48:47.927, approximately 44 seconds before Windows user logon at 01:49:32.384.
- Error-free boots at 02:16:38.500 and 02:39:40.500: Windows logon preceded the service-running event. Restarting the service while logged in also produced no token error.
No permanent service/app setting was changed. These two exceptions do not disprove the earlier repeated pattern or establish a fix. They support a timing problem between auto-start restoration and the availability of a logged-on Windows user.
The matching public service code tries the recorded session and other sessions. Initialisation performs two restoration attempts and logs failures while continuing. PR #45224 explains why uninstall ownership is registered even before sandbox setup. More Codex file permissions do not supply a Windows token before logon. No supported user setting or permanent product fix has been verified.
The AppX errors in the earlier capture occurred during an actual shutdown. 0x8007045B means Windows shutdown is in progress, but the exact calling app/service operation remains unidentified. One common cause for the two error types has not been proved. Earlier log-clearing batches and closing the app have not been established as independent fixes. EventLog was running and recorded the latest boot/logon/service sequence; the preceding shutdown’s capture was incomplete after EventLog had been stopped.
OpenAI Support has received the retained diagnostics privately. Its first response was AI-assisted; human engineering review and a supported solution are still requested. Please answer:
- Is the missing owner token during automatic uninstall-listener restoration known? What exact condition makes this recur on consecutive boots and disappear on occasional boots?
- Is there a supported app/Windows setting or workaround that prevents it while keeping ChatGPT installed, without source edits or protected service changes?
- Should the listener defer until Windows logon and retry then, instead of logging two expected missing-token errors?
- Which lifecycle operation causes the AppXSvc request during shutdown, and what additional trace is required?
- Is there a fix or engineering bug reference? Please provide a human technical answer rather than another generic reinstall/reset, which I have already tried repeatedly.
I am sharing the public technical summary here and keeping full logs, account details and identifying screenshots in the private support case.