Bug: `apply_patch` intermittently fails with `cannot enforce split writable root sets` after workspace migration on Windows

Bug: apply_patch intermittently fails with cannot enforce split writable root sets after workspace migration on Windows

Environment

• Platform: Windows
• Product: Codex Desktop
• Repository: Large Git repository
• Workspace: Migrated from C:\... to D:\...
• Editing mechanism: apply_patch
• Multi-agent/Sub-agent: Enabled

---

Description

After migrating a large project from the C: drive to the D: drive, apply_patch became unstable.

The workspace root correctly pointed to the D: drive, but editing operations began failing intermittently with:

cannot enforce split writable root sets

The failure occurred even though the workspace itself appeared to be correctly opened and readable.

---

Steps to Reproduce

Unfortunately, I cannot provide a minimal public repository because this occurred in a private production project.

However, the issue was reproduced consistently using the following workflow:

1. Open a large Git repository on Windows.
2. Migrate the repository from C:\... to D:\....
3. Continue working in the migrated workspace.
4. During later editing operations, apply_patch begins reporting writable-root errors.

To isolate the problem, I performed a harmless probe inside the same task:

1. Create a temporary file using apply_patch.
2. Creation succeeds.
3. Immediately delete the same file using apply_patch.
4. Deletion fails.

Error:

cannot enforce split writable root sets

The probe file was located inside a temporary ignored directory and did not modify project source code.

---

Expected Behavior

If the workspace is writable:

• Creating a file with apply_patch should succeed.
• Deleting that same file immediately afterward should also succeed.

The writable root state should remain internally consistent throughout the task.

---

Actual Behavior

The first apply_patch operation succeeds.

The immediately following apply_patch operation on the same file fails with:

cannot enforce split writable root sets

Once this occurs, the current editing session becomes unreliable for further production edits.

---

Investigation Performed

To isolate the cause, I intentionally disabled every possible workaround.

Specifically, I prohibited:

• git apply
• PowerShell file modifications
• Any workaround that bypasses apply_patch

This ensured the issue was isolated to the native editing mechanism.

I also tested two different task continuation strategies:

1. Task handoff

The original task directly handed off to a new task.

Result:

Same failure.

2. Task lookup by Task ID

A completely new task was created and instructed to continue using the previous Task ID.

Result:

Same failure.

Therefore, the issue does not appear to be related to task inheritance or context transfer.

Most importantly, the create/delete probe reproduced the problem inside the same task, indicating that the failure does not require task handoff to occur.

---

Additional Observations

• The repository itself is healthy.
• Git operations function normally.
• The workspace root correctly points to the D: drive.
• The issue is specific to apply_patch.
• The problem appears to be related to writable-root management rather than repository contents.

---

Impact

This issue is particularly disruptive for long-running sessions on large repositories.

Once the writable-root state becomes inconsistent:

• apply_patch can no longer be trusted,
• production editing must stop,
• users may need to abandon an otherwise healthy task after significant work has already been completed.

---

Possible Area to Investigate

Based on the observed behavior, the issue appears related to one or more of:

• Windows sandbox initialization
• Writable-root tracking
• Split writable-root enforcement
• Workspace migration handling
• Long-running editing session state
• Internal state management of apply_patch

---

Error Message

cannot enforce split writable root sets

This was the only consistent error observed throughout reproduction.