Codex Desktop stuck in "Windows Setup Incomplete" loop despite Windows Sandbox feature enabled

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #34748

Powered by Codex Action

Additional Windows 10 data point, with CLI isolation tests.

What issue are you seeing?

I am seeing a Windows-specific inconsistency between Codex Desktop Windows setup and Codex CLI sandbox behavior on a secondary local Windows user.

Environment:

• Windows 10 Pro 22H2
• OS build: 19045.6456
• Codex Desktop: Microsoft Store package
• Codex Desktop package version observed: 26.803.5235.0
• Codex CLI: 0.147.0-alpha.6.5
• x64
• Secondary local Windows user used for the failing setup

On the secondary Windows user, Codex Desktop repeatedly asks to complete Windows setup.

The UAC elevation prompt appears and can be approved with valid administrator credentials. After approval, the app appears to continue setup, but later returns to the state where Windows setup is still incomplete. Retrying repeats the cycle.

At the same time, CLI behavior is inconsistent:

codex exec --sandbox workspace-write ...

starts with:

approval: never
sandbox: read-only

and file writes fail.
However, the lower-level sandbox itself is functional. This command:

codex sandbox `
  --permission-profile ":workspace" `
  --cd D:\Codex-Sandbox-Test `
  powershell.exe -NoProfile -Command "'sandbox-direct-test' | Set-Content -LiteralPath .\sandbox-direct.txt -Encoding utf8"

successfully creates the file.

Also, this command:
codex exec --approve-for-me
successfully modifies files, even though the session header still reports:

approval: on-request
sandbox: read-only

So there appear to be two related inconsistencies:

1. Codex Desktop Windows setup does not successfully persist/complete for the secondary Windows user.
2. The CLI-reported sandbox: read-only state does not always match the actual ability to write when --approve-for-me is used.

I cannot determine whether these have the same root cause, but both were observed on the same installation during debugging.

What steps can reproduce the bug?

1. Use Windows 10 Pro 22H2 (build 19045.6456).

1. Install Codex Desktop from the Microsoft Store.

1. Sign in to Windows using a secondary local Windows user.

1. Launch Codex Desktop and sign in.

1. When Codex asks to complete Windows setup, start the setup process.

1. Approve the UAC elevation prompt using valid administrator credentials.

1. Observe that setup appears to continue, but Codex later returns to the "Windows setup incomplete" state.

1. Retry Windows setup and observe the same loop.

1. From PowerShell under the same secondary user, locate the Codex CLI installed for that user and run:

codex exec `
  --sandbox workspace-write `
  --cd D:\ABEA-Codex-Sandbox-Test `
  --skip-git-repo-check `
  --ephemeral `
  -

with a prompt asking Codex to create a small text file.

Observed result:
sandbox: read-only
and the write is rejected.

1. Test the low-level sandbox directly:

codex sandbox `
  --permission-profile ":workspace" `
  --cd D:\Codex-Sandbox-Test `
  powershell.exe -NoProfile -Command "'sandbox-direct-test' | Set-Content -LiteralPath .\sandbox-direct.txt -Encoding utf8"

Observed result:
sandbox-direct.txt is created successfully

1. Test:

codex exec --approve-for-me ...
with a prompt asking Codex to create another small text file.
Observed result:

• the file is successfully created;
• the session header still reports:

approval: on-request
sandbox: read-only

1. Verify the same workflow through a local automation/bridge process using codex exec --approve-for-me.

Observed result:

exitCode: 0
changedFiles: ["CURRENT_STATE.md"]
unexpectedFiles: []
constraintsSatisfied: true
with a clean Git baseline before execution.

What is the expected behavior?

I would expect:

1. Windows setup in Codex Desktop to complete once after successful UAC elevation and remain completed for that Windows user.

1. codex exec --sandbox workspace-write to provide actual workspace write access when that mode is accepted by the CLI.

1. The session header to report the effective sandbox/permission state accurately.

In particular, if --approve-for-me allows workspace writes, reporting only:

sandbox: read-only
is misleading because it does not describe the effective behavior observed by the user.
Ideally the CLI would expose the effective permission profile / approval mode clearly enough to explain why writes are allowed.

Additional information

Additional diagnostics performed during the investigation:

• codex doctor reported the installation as consistent.
• Authentication was configured successfully.
• WebSocket connectivity succeeded.
• Git was detected correctly.
• Codex state databases passed integrity checks.
• The only unrelated doctor warning was that rg.exe could not be found.
• Get-AppxPackage OpenAI.Codex reported:

Status        : Ok
SignatureKind : Store

• The Windows sandbox users existed and were enabled:

CodexSandboxOffline
CodexSandboxOnline

• CodexSandboxUsers contained the secondary Windows user and both sandbox users.

• Direct low-level codex sandbox --permission-profile ":workspace" execution successfully wrote files, indicating that the restricted-token sandbox itself was functional.

During early debugging there was also an old manually copied Codex CLI at:
D:\Tools\codex\codex.exe
and CODEX_CLI_PATH initially pointed to it.
That was corrected so that the automation used the current CLI installed under the secondary user's %LOCALAPPDATA%\OpenAI\Codex\bin\... directory.
After correcting the executable path, the end-to-end automation still required switching from:

--sandbox workspace-write
--ask-for-approval never

to:
--approve-for-me
before file modification worked reliably.
The old manually copied CLI was subsequently removed.
I did not change ownership or ACLs on C:\Program Files\WindowsApps.
I also tested the primary Windows user separately. On that account, workspace-write was able to create a file, although the first patch attempt failed before a later retry succeeded. This suggests the behavior may depend on per-user Codex/Desktop sandbox state rather than only on the machine-wide Store package.
Related issue:
#35349 appears very similar with respect to the Codex Desktop "Windows setup incomplete" retry loop. My additional data point is Windows 10, a secondary local Windows user, and the CLI comparison showing that :workspace and --approve-for-me can write while the displayed sandbox state remains read-only.

_This report was prepared with assistance from ChatGPT based on a real, interactive debugging session with a human user. All reproduction steps, command outputs, and observations above come from actual testing on the affected Windows installation._

Update after further investigation
I found an important detail that changes the diagnosis of the read-only behavior described in this report.
In Codex Desktop, under Configuration → Agent defaults → Sandbox settings, the selected profile was set to Read only. After changing this setting to Workspace write, the app also exposed the Allow network access option for that sandbox mode.
I then repeated the filesystem test without changing Windows permissions, ACLs, UAC settings, the Codex installation, or the executable.
The test was performed under both Windows user accounts involved in the original investigation, including the dedicated non-primary account.
In both cases Codex reported:
sandbox: workspace-write
and successfully:

create file -> success
read file   -> success
delete file -> success

No unrelated workspace files were modified.
This means that the previous read-only execution was not caused by Windows filesystem permissions, WindowsApps ACLs, the secondary Windows user account, or an inability of the sandbox itself to write to the workspace.
The Desktop Sandbox settings selection was controlling the effective sandbox mode.
There is still a UX/discoverability aspect worth noting: during troubleshooting, codex doctor reported a restricted filesystem sandbox and the CLI/Desktop behavior made the problem look like a failed Windows sandbox setup or permissions problem. The Desktop sandbox mode setting was not obvious as the source of the effective read-only state.
Therefore I would revise the original diagnosis as follows:

• workspace-write works correctly on this Windows 10 system once selected in Codex Desktop.
• It works under both tested Windows user accounts.
• No manual modification of WindowsApps permissions is required.
• No administrator elevation is required for normal workspace writes.
• The earlier read-only behavior was explained by the Desktop configuration rather than a filesystem ACL failure.

Separately, the earlier Windows setup/UAC behavior observed during installation may still be relevant, but I can no longer claim that it was the cause of the workspace being read-only.
I am leaving the issue open for maintainers to decide whether the remaining configuration/discoverability behavior is considered a bug or expected behavior.
_This update was drafted with ChatGPT based on troubleshooting and tests performed by a real user on the affected machine._

Windows 11 Pro 10.0.26200
OpenAI.Codex 26.814.5167.0
Containers-DisposableClientVM: Enabled
VirtualMachinePlatform: Enabled
Repair and Reset completed successfully (AppX registration result 0x0)
MacType fully exited; no subsequent CodeIntegrity events
After approving Windows setup, the app immediately shows “Windows setup incomplete”.