What version of the Codex App are you using (From “About Codex” dialog)?
Unknown (Windows desktop app build not yet verified)
What subscription do you have?
Unknown / not relevant yet, because this happens before login completes
What platform is your computer?
Windows desktop (exact Windows version not yet collected)
What issue are you seeing?
Opening the Codex desktop app on Windows causes the machine to lag heavily before login completes and before any prompt/task is started.
The sign-in UI gets stuck on the "Get started with Codex" screen and shows "Cancel sign in", but does not progress.
At the same time, Task Manager shows a codex-windows-sandbox child process consuming substantial local resources:
codex-windows-sandbox ~820 MB memory- disk throughput around 132.0 MB/s
- the full
Codex process group around 1.1 GB memory
This makes the whole PC feel choppy / laggy.
What steps can reproduce the bug?
- Install/open the Codex desktop app on Windows.
- Launch the app.
- Attempt to sign in with ChatGPT.
- Before login finishes, observe that the UI remains on the sign-in screen.
- Open Task Manager and inspect the
Codex process group.
- Observe
codex-windows-sandbox running even though no prompt has been sent, no project/task has been started, and login has not completed.
- Observe heavy disk activity and system lag.
What is the expected behavior?
Launching the desktop app and waiting at sign-in should not start a heavyweight sandbox workload that causes sustained high disk I/O and machine-wide lag.
At minimum, the app should either:
- not initialize the Windows sandbox before login / before the first actual task, or
- initialize it in a lightweight/non-blocking way that does not degrade the host machine.
Reproducibility
Repeated on app launch.
Additional information
Important constraint from the affected user:
- Codex CLI appears to be working normally.
- Because desktop app / CLI may share state under
~/.codex, the user does not want to apply debugging steps that rename/delete shared local state if those steps could break normal Codex CLI behavior.
So this report is specifically about the desktop app starting a problematic Windows sandbox path even before login/task execution, and about needing a fix/workaround that does not require destructive mutation of possibly shared CLI state.
I can provide screenshots from Task Manager / sign-in screen if needed.
What version of the Codex App are you using (From “About Codex” dialog)?
Unknown (Windows desktop app build not yet verified)
What subscription do you have?
Unknown / not relevant yet, because this happens before login completes
What platform is your computer?
Windows desktop (exact Windows version not yet collected)
What issue are you seeing?
Opening the Codex desktop app on Windows causes the machine to lag heavily before login completes and before any prompt/task is started.
The sign-in UI gets stuck on the "Get started with Codex" screen and shows "Cancel sign in", but does not progress.
At the same time, Task Manager shows a
codex-windows-sandboxchild process consuming substantial local resources:codex-windows-sandbox~820 MB memoryCodexprocess group around 1.1 GB memoryThis makes the whole PC feel choppy / laggy.
What steps can reproduce the bug?
Codexprocess group.codex-windows-sandboxrunning even though no prompt has been sent, no project/task has been started, and login has not completed.What is the expected behavior?
Launching the desktop app and waiting at sign-in should not start a heavyweight sandbox workload that causes sustained high disk I/O and machine-wide lag.
At minimum, the app should either:
Reproducibility
Repeated on app launch.
Additional information
Important constraint from the affected user:
~/.codex, the user does not want to apply debugging steps that rename/delete shared local state if those steps could break normal Codex CLI behavior.So this report is specifically about the desktop app starting a problematic Windows sandbox path even before login/task execution, and about needing a fix/workaround that does not require destructive mutation of possibly shared CLI state.
I can provide screenshots from Task Manager / sign-in screen if needed.