Codex Desktop for Windows — patch service hangs and performs no writes in a valid multi-repo workspace
I am reporting a repeatable Codex Desktop issue on Windows.
Environment
- Date/time: 13 July 2026, Europe/Lisbon — 1200-1600
- OS: Windows 10.0.26200/26200
- Codex Desktop version: Version 26.707.62119
- Workspace type: local project-level umbrella,
project - The project contains three repositories:
- docs: read-only product specs
- repo: source repository
- devflow: workflow/process repository
- Cross-repository tasks must run from the umbrella root because one task may legitimately update both repo and devflow. The root must not be converted into a Git repository.
Sandbox/configuration
- The project uses a strict permission profile: the root, source repo, workflow repo, and .local are writable; docs remain read-only.
- Windows sandbox is set to elevated. Unelevated is not usable with this split read/write policy because Codex rejects it as restricted read-only access.
- The machine and Codex were restarted; the affected task was launched as a fresh new Codex task.
Verified inside the elevated Codex sandbox:
whoami: ***\codexsandboxoffline
node: v24.18.0
npm.cmd: 11.16.0
Python: 3.14.6
Therefore this is not caused by a missing Node/Python installation, PowerShell npm alias, or basic sandbox identity/access failure.
Reproduction
- Open Codex Desktop on Windows.
- Open the local project-level workspace
project. - Start a new Local task that updates files under
repo. - Ask the agent to perform a normal source edit.
- The editor reports: “The edit operation is taking longer than expected.”
- After several retries it reports: “The workspace patch service is not responding.”
- No intended source changes are written.
Important safety issue
After the patch service stopped responding, the agent attempted shell-based fallbacks (git apply and PowerShell/.NET WriteAllText). Those methods must not be used: they bypass the workspace’s controlled editing safeguards. The correct behavior should be to stop and report the patch-service failure, or offer an approved alternative editor/write path.
Expected behavior
Normal apply_patch edits should complete in this valid elevated sandbox, or Codex Desktop should expose an approved alternative write path for the task. It must not hang indefinitely and then lead agents toward unsafe shell-write fallbacks.
This issue has also occurred in earlier tasks, including after a full Codex restart. Please investigate the Windows Desktop patch-service/session backend and advise how to collect any relevant logs or diagnostics.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗