Skip to content

[Critical][Windows App 26.825] One writable-root setup failure disables exec and apply_patch globally #41516

Open
Open
[Critical][Windows App 26.825] One writable-root setup failure disables exec and apply_patch globally#41516
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

Description

@vlastimilvajnorak
vlastimilvajnorak
opened on Aug 29, 2026

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

Codex App 26.825.4187.0; bundled Codex CLI 0.149.0.

What subscription do you have?

Not disclosed in this public report.

What platform is your computer?

Windows 11 Pro x64, build 26200. PowerShell 7.6.4.

What issue are you seeing?

Severity: Critical workflow blocker.

The Codex App's Windows workspace-write sandbox repeatedly fails during setup refresh before any requested process starts. If setup cannot update one configured writable root, the entire sandbox becomes unusable, including narrower writable roots that are otherwise valid.

The user-visible error is:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

apply_patch fails through the filesystem sandbox helper with the same setup-refresh error before it can read or edit a file.

A sanitized local sandbox log identifies the underlying operation only as:

write ACE grant failed on <WRITABLE_ROOT>: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors
setup error: setup refresh had errors

The following all failed in the same task before process or file access:

  • a minimal Get-Location command through bundled PowerShell;
  • a read-only Git command through cmd.exe;
  • apply_patch on a file inside an explicitly writable task worktree;
  • repeated attempts using both native and normalized path syntax.

The same read-only commands succeed when explicitly escalated outside the sandbox. This confirms that the shell, repository, worktree, and requested commands are healthy. There is no equivalent policy-compliant fallback for the required apply_patch editor, so normal repository work cannot be completed.

What steps can reproduce the bug?

  1. On Windows, open a local Codex project with multiple configured writable roots, including a broad workspace root and a narrower task worktree.
  2. Use workspace-write sandboxing.
  3. Run a minimal read-only command such as Get-Location through normal unified exec.
  4. Observe that the process never starts and setup refresh returns helper_unknown_error.
  5. Retry through cmd.exe; observe the same pre-launch failure.
  6. Attempt apply_patch inside the explicitly writable worktree; observe the same sandbox setup failure before file access.
  7. Run the read-only command with explicit escalation outside the sandbox; observe that it succeeds.

What is the expected behavior?

  • A failure on one redundant or broad writable root must not disable all valid narrower writable roots.
  • The helper should skip or isolate the failing root, or provide a supported repair/elevation flow.
  • The user-visible error should include the failed operation and Win32 error code instead of only helper_unknown_error.
  • apply_patch and read-only exec should remain usable for valid explicitly writable roots.
  • Sandbox setup should recover after workspace-root configuration changes without requiring unsafe filesystem workarounds.

Additional information

This is recurring rather than transient and has blocked multiple local tasks. No secrets, repository content, real paths, account identifiers, session identifiers, or customer data are included in this report.

Related open reports reviewed before filing:

This report adds a current reproduction on Codex App 26.825.4187.0 and the fail-all behavior where one writable-root setup error disables otherwise valid task-specific roots.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    tool-callsIssues related to tool calling
    on Aug 29, 2026

  2. github-actions commented on Aug 29, 2026

    @github-actions
    github-actionsbot
    on Aug 29, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. vlastimilvajnorak commented on Aug 29, 2026

    @vlastimilvajnorak
    vlastimilvajnorak
    on Aug 29, 2026
    Author

    Additional current reproduction on Codex App 26.825.4187.0:

    A newly created parallel recovery task immediately reproduced the same failure. A minimal Get-Location command and a read-only policy-file read both failed before process launch with:

    Failed to create unified exec process: helper_unknown_error: setup refresh had errors

    The same recovery task can still run approved read-only commands only through explicit execution outside the sandbox, while normal unified exec and the required apply_patch editor remain unavailable. This rules out corruption limited to one conversation or one task runtime.

    No project paths, session identifiers, account details, or repository content are included in this update.

    The repository's issue-labeler automation has now correctly applied bug, app, windows-os, sandbox, and tool-calls; no manual label bypass is needed.

  4. LeoOliveiraConcept commented on Sep 13, 2026

    @LeoOliveiraConcept
    LeoOliveiraConcept
    on Sep 13, 2026

    I was able to identify and resolve one concrete cause of this failure on Windows 11.

    Symptoms

    apply_patch and filesystem operations were failing globally with:

    helper_unknown_error: setup refresh had errors

    codex doctor --json reported the Windows sandbox provisioning as failed.

    The sandbox log revealed the actual failing writable root:

    granting write ACE to C:\Program Files (x86)\PegasoDriver
    write ACE grant failed on C:\Program Files (x86)\PegasoDriver:
    SetNamedSecurityInfoW failed: 5
    setup refresh completed with errors

    The important detail was that this directory was not the main project. It was an old reference folder included in a multi-root .code-workspace:

    {
    "folders": [
    { "path": "." },
    { "path": "../some-other-project" },
    {
    "path": "../../../../../../../Program Files (x86)/PegasoDriver"
    }
    ]
    }

    Codex apparently treated every workspace folder as a writable root. Since Windows does not allow the sandbox helper to add the required write ACE to this Program Files directory, that single failure caused the entire sandbox setup to fail, including apply_patch against otherwise valid project files.

    Fix

    I removed the obsolete Program Files (x86)\PegasoDriver entry from the .code-workspace file and reopened the workspace.

    After that:

    • sandbox diagnostics returned healthy;
    • setup_error.json was no longer generated;
    • apply_patch successfully modified and reverted a test file;
    • no ACL changes to the actual project were required;
    • the project could remain inside OneDrive.

    A useful diagnostic workflow for this issue is:

    1. Inspect the current .code-workspace.
    2. Identify all folders being treated as writable roots.
    3. Inspect %USERPROFILE%\.codex\.sandbox\sandbox.<date>.log.
    4. Search for write ACE grant failed.
    5. Remove unintended or protected external directories from the workspace instead of granting Codex write access to them.

    In my case, the underlying error was:

    SetNamedSecurityInfoW failed: 5

    and removing the protected writable root fully restored apply_patch.

    This may help distinguish this failure from OneDrive or project ACL issues: my actual project ACLs were correct, and the failure was caused by a separate protected folder included in the multi-root workspace.

  5. jyx114514 commented on Sep 26, 2026

    @jyx114514
    jyx114514
    on Sep 26, 2026

    I can reproduce this intermittently in Codex on Windows. The failure occurs before the requested shell starts. I explicitly tested both Windows PowerShell 5.1 and PowerShell 7; both fail with the identical unified-exec setup-refresh error before reporting their version or executing Get-Location. cmd.exe is affected at the same stage as well.
    This therefore does not appear to be specific to PowerShell 5.1/7 or the command being executed.
    Interestingly, the condition can sometimes recover after repeated tool-execution attempts without changing Windows permissions, sandbox configuration, or project files.
    Windows 11
    codex：26.909.11814

    Image Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingtool-callsIssues related to tool callingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions