Windows sandbox setup refresh errors prevent editing existing files and browser control

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

26.831.2377.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Codex could read files and had previously created new Markdown files in my workspace, but it consistently could not modify any existing file. The failure occurred during apply_patch verification, before a patch was applied.

The same Windows sandbox error also prevented browser-control initialization, so Codex could not even open the official support page to submit this report.

Environment

• OS: Microsoft Windows NT 10.0.26200.0 x64
• Workspace: C:\AI_study\2026\Changsoo_Vault
• Time zone: America/Los_Angeles
• Affected capabilities:
  • Updating existing workspace files with apply_patch
  • Windows/browser control initialization
• Working capabilities:
  • Read-only PowerShell commands
  • Earlier creation of new Markdown files

Reproduction steps

1. Open an existing Markdown file in the writable workspace.
2. Ask Codex to apply even a no-op patch or a one-line text insertion.
3. The patch fails before any modification is applied.
4. Try to initialize browser control in order to open the official support page.
5. The browser-control runtime exits before the initial state is returned.

Actual result

The following error appeared repeatedly while trying to update different existing files:

apply_patch verification failed: Failed to read file to update
C:\AI_study\2026\Changsoo_Vault\Ingest\CatchUpAI_VL\Topics\Datacenter-Workforce-Programs\README.md:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error: setup refresh had errors

The same error occurred for other existing files, including:
- Ingest/CatchUpAI_VL\Topics\Datacenter-Workforce-Programs\04-US-Regional-Map\guides\find-your-region.en.md
- Journal\2026-09-02.md
- AI\Research\2026-09-02 Codex Windows sandbox setup refresh 오류 보고서.md
Browser-control initialization also failed:

node_repl kernel exited unexpectedly
windows sandbox failed: helper_unknown_error: setup refresh had errors

Expected result
- Codex should be able to update existing Markdown files inside the writable workspace.
- Browser control should initialize normally so Codex can navigate to a support page when requested.
- If sandbox initialization fails, Codex should provide actionable diagnostics explaining why existing-file updates fail while read-only operations and new-file creation may still work.
User impact
This was not a minor inconvenience. On 2026-09-02, I could not complete normal work with Codex for the entire day because existing-file updates repeatedly failed.
This blocked:
- Adding reciprocal Korean/English links to existing documents
- Creating the September 2 Daily Roundup, because the required first step was preserving the user's verbatim note in an existing Journal file
- Submitting an error report through Codex browser control
As a result, I had to continue my work using Claude only. This caused a real productivity loss and forced a tool switch in the middle of ongoing knowledge-management and documentation work.
Request
1. Please investigate the Windows sandbox setup refresh failure.
2. Please check whether apply_patch verification and browser-control initialization share the same sandbox initialization component.
3. Please provide the recommended diagnostic logs, log locations, and safe recovery steps for this failure on Windows.

### What steps can reproduce the bug?

1. Start Codex App on Windows and open a workspace with existing Markdown files.

2. Ask Codex to update an existing file using `apply_patch`. The patch can be a no-op or a simple one-line insertion.

Example target file:
`C:\AI_study\2026\Changsoo_Vault\Journal\2026-09-02.md`

Example requested change:
```diff
@@
## Thoughts
+
+Test line

3. Codex fails before applying the change. The same failure occurred with multiple existing Markdown files.
Error:

apply_patch verification failed: Failed to read file to update ...:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error: setup refresh had errors

4. In the same Codex session, try to initialize browser control to open a support page. The browser-control runtime also exits before returning its first state.
Error:
node_repl kernel exited unexpectedly
windows sandbox failed: helper_unknown_error: setup refresh had errors

Notes:
- Read-only PowerShell commands worked normally.
- Codex had previously created new Markdown files, but could not modify existing ones.
- I do not have a session ID, token-limit value, or context-window value to provide.

### What is the expected behavior?


두 번째 칸에는 아래를 넣으세요.

```md
Codex should successfully apply a valid patch to an existing file inside the writable workspace.

For the example above, Codex should insert `Test line` under the `## Thoughts` heading in `Journal/2026-09-02.md`.

Browser control should also initialize normally and return its first state so Codex can open a support page when requested.

If the Windows sandbox cannot initialize, Codex should provide actionable diagnostics explaining:
- why existing-file updates fail,
- whether browser control is affected by the same sandbox component, and
- what logs or recovery steps the user should use.

This issue prevented me from completing normal work with Codex for the entire day and forced me to continue the work using Claude instead.

### Additional information

## Additional user impact and feedback

This issue had a significant productivity impact. I was unable to complete normal work with Codex for an entire day because the application repeatedly failed when it needed to update existing files. I had to switch to Claude to continue the work.

More broadly, Codex currently feels substantially less reliable and less effective than Claude for this kind of ongoing knowledge-management and documentation workflow. The problem is not only the sandbox error itself, but also how much manual intervention was required around it.

For example, I asked Codex to prepare this bug report. When the GitHub form asked for the Codex App version, Codex initially told me to open the app and check the version myself. I then explicitly asked Codex to check it directly. Only after that follow-up request did it retrieve the installed package version (`26.831.2377.0`) using a read-only system query.

In my view, checking an available local application version is a basic diagnostic step that Codex should perform proactively when preparing a bug report. I should not need to discover that information manually or ask a second time for Codex to inspect it.

The expected agent behavior should be:
- identify the information required by the bug-report form;
- automatically collect non-sensitive, locally available diagnostics such as app version, operating system version, and reproducible error text;
- clearly distinguish unavailable information from information it can retrieve itself; and
- avoid shifting routine diagnostic work back to the user unnecessarily.

This incident made it difficult to rely on Codex as the primary tool for a time-sensitive, ongoing workflow.

Reproduce the failure through apply_patch verification and browser-control initialization, then inspect the Windows sandbox setup-refresh diagnostics for a shared cause. Trace whether both paths use the same sandbox component; done means existing-file updates and browser control work, or the app reports actionable logs, locations, and recovery steps.