Codex Desktop intermittently enters onboarding after Windows reboot instead of restoring the existing session

Start by tracing the session-restoration and first-run/onboarding-state detection paths for Codex Desktop on Windows, especially recovery after reboot or unclean shutdown. Use the reported version and reboot sequence as context, and inspect available diagnostics if provided. Done means an existing installation does not enter onboarding when durable state remains available, while partial recovery shows a restrained recovery notice.

Description

During a sequence of Windows reboots, Codex Desktop initially recovered normally after each restart. Following a later reboot in the same sequence, however, reopening Codex presented the onboarding flow rather than the normal interface for the existing installation.

The durable state was ultimately still present: existing tasks, workspace files, and persistent context had not been lost. Some lightweight UI/session state was not restored.

Presenting onboarding was especially disconcerting because it suggested that the application might have lost its account, configuration, tasks, or workspace state. Determining that the loss was limited to disposable UI state required an unnecessary manual audit.

The earlier successful recoveries during the same reboot cycle suggest that this is an intermittent session-restoration or onboarding-state detection failure, rather than onboarding being an expected consequence of every unclean restart.

Observed behaviour

1. Codex Desktop was already configured and in active use.
2. Windows went through a sequence of reboots.
3. Codex reopened normally following the earlier reboots.
4. Following a later reboot, Codex opened into onboarding rather than the existing user interface.
5. Some transient UI/session state was no longer present.
6. Durable tasks, workspace files, and persistent context were subsequently found to be intact.

Expected behaviour

For an existing installation after a reboot or unclean shutdown, Codex Desktop should:

• recognize the existing user and installation;
• restore the last usable session state where possible;
• open the normal task interface when durable state remains available; and
• show a restrained recovery notice if some session state could not be restored.

Missing or damaged transient UI state should not cause the application to present first-run onboarding.

Impact

No consequential project data appears to have been lost in this instance. The primary impact was loss of confidence during recovery: onboarding made a minor UI-state restoration failure look like possible account or project loss.

This is particularly problematic for an agentic development tool, where users may have multiple active tasks, local workspaces, approvals, and accumulated context. Recovery UX should clearly distinguish:

• a genuinely new installation;
• a signed-out state;
• unavailable durable state; and
• partial recovery of transient UI state.

Frequency and reproducibility

Observed once following several successful recoveries during the same sequence of Windows reboots.

The failure is therefore intermittent. I do not currently have a deterministic reproduction beyond the reboot or unclean-shutdown condition.

Environment

• Application: Codex Desktop for Windows
• Codex version: 26.715.10079.0
• Operating system: Windows 11 Home, version 25H2
• OS build: 26200.8875
• Installation had previously completed onboarding and was in regular use.

Likely area

Session restoration, first-run/onboarding-state detection, or unclean-shutdown recovery.

Privacy note

I have omitted screenshots, task names, workspace paths, account details, and private project information from this public report. Redacted diagnostic information could be provided privately if there is an appropriate channel.