Windows desktop 26.730.8199.0: Stop/network interruption leaves task stuck as codexsandboxoffline

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.730.8199.0 (regression); embedded command runner 0.147.0-alpha.1.2. Last known good / verified rollback: OpenAI.Codex 26.727.6591.0.

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64 (Windows 11 Home, build 22631)

What issue are you seeing?

Summary

On Windows, Codex desktop 26.730.8199.0 can leave a task in a broken sandbox state after the task is interrupted—observed once after a network loss stopped the task, and again after pressing Stop.

Afterward:

• whoami inside the affected task reports <machine>\codexsandboxoffline instead of the normal host user.
• Process/ownership/CIM queries can fail with Access Denied.
• apply_patch and ordinary commands can fail or trigger approval prompts.
• Approval prompts appear even though the effective task context reports:

approval_policy=never
sandbox_policy=danger-full-access
permission_profile=disabled

Launching Codex as Administrator did not resolve it, and normal restarts did not reliably repair the affected task.

Relevant sandbox log excerpts

PII and local project paths are redacted:

[codex-command-runner-0.147.0-alpha.1.2.exe] hide users: failed to hide current user profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied.)

grant read ACE failed on C:\Windows\Temp
read ACL run completed with errors
setup error: read ACL run had errors

Version-bisect evidence

I rolled the Microsoft Store-signed package back from 26.730.8199.0 to 26.727.6591.0. Both package signatures and package status were verified before testing.

Newly started work under 26.727.6591.0 immediately behaved normally:

• whoami returned the normal host user.
• Git, process/ownership queries, and apply_patch completed without approval prompts.
• A minimal apply_patch create/delete probe succeeded.
• No new entries were written to the sandbox error log during that verification.

However, an already-existing task later still reported <machine>\codexsandboxoffline and entered waitingOnApproval after rollback/restart, while the newly started task was healthy. This suggests the broken state may be retained per task/runner rather than being purely global configuration.

This is a behavioral observation, not a claimed root cause.

What steps can reproduce the bug?

1. Install or update the Windows Codex desktop app to 26.730.8199.0.
2. Start a local task with Full Access / approvals disabled.
3. Run ordinary local commands or a longer test.
4. Interrupt the task either by:

• losing network connectivity until the task stops, or
• pressing Stop while the task is running.

1. Continue or reopen the same task; restarting the app may not clear the state.
2. Run whoami, a process/ownership query, Git, and a minimal apply_patch.
3. Observe <machine>\codexsandboxoffline, Access Denied failures, and/or repeated approval prompts despite approval_policy=never and danger-full-access.
4. Roll back to 26.727.6591.0 and start a new task. The same probes run as the normal host user without approval prompts.

The failure occurred twice with the two interruption triggers above. I did not modify system ACLs, sandbox users, services, or host security settings while collecting this evidence.

What is the expected behavior?

Stopping a task or losing network connectivity must not corrupt or preserve an invalid Windows sandbox identity/mapping.

When a task resumes, Codex should either:

1. restore a healthy sandbox identity and honor the effective approval policy, or
2. fail once with an actionable sandbox reinitialization error.

A task configured with approval_policy=never, danger-full-access, and a disabled permission profile should not repeatedly request approval for ordinary local reads, Git commands, process queries, or apply_patch.

Additional information

Possibly related, but this report adds a specific interruption trigger and a verified app-version rollback comparison:

• #24934 — approval prompts despite approval_policy=never
• #29072 — Windows Codex App apply_patch / sandbox setup failure
• #9062 — Windows sandbox process launch / Access Denied
• #35737 — the same C:\Users\Default “hide users” failure, but that issue concerns MSIX package remediation rather than a stuck task identity

The issue author is the person who discovered and reproduced this regression: @junjiehei.

I can provide additional sanitized sandbox log excerpts to maintainers. I am intentionally not attaching full session transcripts or local project paths because they may contain private prompts, commands, and repository data.