Codex Stuck as CodexSandboxOffline After Stop? Start a New Task

If an existing Codex task starts running commands as codexsandboxoffline after you press Stop or lose the network, do not repair Windows accounts or permissions. Preserve the task's useful context, restart or update the Codex app, and open a brand-new task. Then use whoami and a read-only repository check to determine whether the bad sandbox identity is attached to the old task or affects the whole app.

That is the safest current workaround for the specific behavior reported in openai/codex issue 37187. The reporter reproduced it after both a network interruption and pressing Stop in Codex for Windows 26.730.8199.0. An affected task kept returning codexsandboxoffline, Access is denied, and approval prompts. A new task created after returning to a known-good app version used the normal Windows identity and worked. The older task remained broken, so reopening the same conversation is not a reliable recovery test.

This is an open upstream issue, not a confirmed root-cause announcement. Treat the new-task comparison as a diagnostic and containment step, not a universal fix.

Confirm That the Failure Is Task-Specific

Issue 37187 is a close match when all of these are true:

• The failure began immediately after Stop or a network interruption.

• One existing task reports codexsandboxoffline or fails ordinary commands with Access is denied.

• The same task keeps requesting approval despite a permissive local profile.

• Closing and reopening the affected task does not clear the behavior.

• A newly created task can run the same harmless checks normally.

Record the Codex app version, embedded runner version if visible, Windows version, interruption type, and the exact first error. Do not paste repository secrets, environment variables, or private paths into a public issue.

Use this small comparison before changing anything on the machine:

If only the existing task fails, preserve its context and move the work to the new task. If every new task fails, the problem is broader than the task state and you should follow the official Windows sandbox diagnostics instead.

Step 1: Preserve Context Without Reusing the Broken Task

Before closing anything, copy the useful user-visible context from the affected task:

• The original goal and acceptance criteria.

• The last confirmed successful step.

• The files intentionally changed.

• The latest git status --short, if the task can still run it.

• Any pending decisions or commands that were not executed.

Do not ask the failing task to make more changes just to create a handoff. If command execution is unreliable, write the handoff manually from the visible conversation and inspect the repository in a normal terminal.

This distinction matters because task context and repository state are separate. Starting a new task does not erase uncommitted files. It does mean the new task needs a concise handoff so it does not repeat or overwrite work.

Step 2: Restart and Update Through a Trusted Channel

Close the Codex app normally and reopen it. Install an available update only through the Microsoft Store or another official OpenAI distribution channel. Do not download an older installer from an unverified mirror.

The issue 37187 reporter used a signed Store rollback to compare versions, which helped isolate the regression. That is useful evidence, but it is not a general instruction to hunt for old packages. The durable recovery test is whether a brand-new task works on an officially installed version.

If you manage Codex on a corporate Windows device, preserve the version details and ask your administrator to control any rollback. Organization policy, AppLocker, endpoint protection, or Store management can change what is safe and supported.

Step 3: Create a Brand-New Task

Do not duplicate, resume, or reopen the affected task for this test. Create a new task in the same project and give it a bounded handoff:

Continue this task using read-only checks first. The previous Codex task began reporting codexsandboxoffline after a Stop or network interruption. Do not modify Windows users, services, ACLs, registry keys, sandbox settings, or security software. Start with whoami and git status --short. Report the identity, working directory, Codex version, and any approval prompt before making changes.

The new task is the control. If it inherits the old task through a resume, duplicate, or fork path, the comparison may not isolate task-local state.

Step 4: Verify the New Task With Read-Only Checks

Run one variable at a time:

whoami
git status --short

Observe the identity and whether the repository status returns without Access is denied. Keep the working directory, command text, and permission profile the same when comparing tasks.

If those checks pass, make a disposable empty directory outside the repository and ask Codex to create and remove one test file inside it. Do not use a project folder, home directory, system directory, or shared drive for the first write probe.

Success means the new task uses the expected identity, completes read-only commands, and performs the isolated write without unexpected approval or access errors. It does not prove why the older task retained the offline identity.

Step 5: Continue Safely From the New Task

When the new task passes, give it the preserved handoff and have it inspect the existing diff before editing:

git status --short
git diff --stat

Then verify the exact changed files and continue from the last confirmed step. Keep the broken task only as a reference until the replacement task has recovered the necessary context.

If the new task also reports codexsandboxoffline, stop the comparison. Capture sanitized diagnostics and use OpenAI's Windows sandbox documentation and Codex app guidance for Windows. The broader sandboxing guide explains the boundary, while agent approvals and security explains why broad permissions are not a substitute for a healthy execution identity.

Do Not Delete Sandbox Accounts or Rewrite ACLs

Search results for sandbox errors often recommend deleting local accounts, changing directory ownership, disabling security software, editing registry keys, or killing Windows authentication services. Those actions are not supported by the evidence in issue 37187 and can make the machine less secure or harder to recover.

For this incident, do not:

• Delete or rename Windows users, including sandbox-related identities.

• Grant broad access to the repository, home directory, or system directories.

• Run Codex as Administrator to hide the error.

• Disable antivirus, endpoint protection, AppLocker, or Controlled Folder Access.

• Stop LSASS or other Windows authentication services.

• Edit Codex state files or the registry without official instructions.

If many new tasks fail and Windows reports authentication-resource exhaustion, use the separate Codex Windows LSASS logon-session diagnostic. If the error is a general sandbox setup failure rather than an interruption-specific task regression, start with the Codex Windows sandbox error guide.

A Reusable Diagnostic Prompt

Use this prompt to keep the recovery bounded:

Compare one affected Codex task with one brand-new task using read-only checks. Record the app version, Windows version, interruption type, working directory, permission profile, whoami output, git status result, and exact first error. Do not modify users, groups, ACLs, services, registry keys, security software, sandbox settings, or project files. If the new task works, summarize the old task's visible context and continue only after inspecting the existing diff. If the new task fails, stop and return sanitized diagnostics.

To check whether the upstream report has been fixed, start with the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then ask Aident Loadout for a read-only update:

Check Aident Loadout authentication and Vault status. Discover the current read-only web research or GitHub issue Action, inspect its schema, and preflight a request for openai/codex issue 37187. If the request is valid and free, execute it. Return only the issue state, updated time, affected versions, maintainer guidance, related issue links, and canonical URL. Do not comment, react, edit, close, or create anything.

Set up Aident Loadout and check the current CodexSandboxOffline report.

Sources

• Stop or network interruption leaves a task as codexsandboxoffline, issue 37187

• Codex cannot run commands after Windows sandbox setup, issue 9062

• Codex Windows sandbox documentation

• Codex app guidance for Windows

• OpenAI Codex sandboxing

• OpenAI agent approvals and security

Refresh this guide when issue 37187 is fixed or closed, when Codex documents task sandbox identity persistence, or when the Windows app changes its recovery behavior after Stop or network interruption.