Windows app: terminal commands hang indefinitely after severe workspace performance degradation

Open 💬 8 comments Opened Jul 14, 2026 by howardsloane-boop
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.707.72221

What subscription do you have?

Pro

What platform is your computer?

Codex desktop app on Windows

What issue are you seeing?

In-app bug feedback was submitted from my signed-in ChatGPT Pro account on 14 July 2026, with the affected session logs included. No reference ID was displayed.

Title: Critical reproducible Codex workspace failure — terminal commands hang indefinitely
In-app bug feedback submitted with current session logs on 14 July 2026. No feedback/session ID was displayed.
Date: 14 July 2026
Severity: Critical operational blocker
Platform: Codex desktop application on Windows
Workspace location:
D:\OneDrive\[business project]\[application]\app_source

Issue summary

Codex is unable to execute even the simplest read-only terminal command in this workspace. Commands stall without producing any output and must be terminated manually.

This completely blocks source inspection, editing, building, testing and Git operations. Ordinary conversational responses and non-workspace tests remain responsive, indicating that the problem is specifically connected to workspace or terminal execution.

Reproduction steps

  1. Open Codex.
  1. Open the workspace shown above.
  1. Start a new task.
  1. Ask Codex to run only:

Get-Location

  1. Do not request any file inspection, build or source changes.

Expected result

The current working directory should be returned almost instantly.

Actual result

The command remains unresponsive without producing output. In the post-reboot test, it was still running after 1 minute 31 seconds and had to be stopped.

Previous failures during the same incident

  1. An implementation task ran for 16 minutes 18 seconds. The required patch mechanism repeatedly timed out before writing even a one-line change. No source changes were applied.
  1. A fresh task attempted the read-only command:

Get-Location

The command stalled repeatedly, including during an elevated retry, and was terminated each time.

  1. Another fresh task attempted:

Get-Location; Get-ChildItem -Force | Select-Object -ExpandProperty Name; Test-Path -LiteralPath package.json; git status --short --branch

This produced no output and was terminated after 40 seconds.

  1. Codex was then completely closed, remaining processes were cleared, and the computer was rebooted.
  1. Following the reboot, a new task was instructed to run only Get-Location. The command again failed to return and was stopped after more than 1 minute 31 seconds.

Troubleshooting already completed

  • Tested through multiple fresh Codex tasks.
  • Reduced the test to a single read-only Get-Location command.
  • Tried an elevated retry.
  • Fully closed Codex.
  • Rebooted the computer.
  • Reopened the workspace and reproduced the fault.
  • Confirmed that no build or source modification was required to trigger the problem.

Data and repository impact

No source files were changed during these failed attempts. No successful patch was applied, no UAT log was updated and no post-failure build was run. There is currently no evidence that the repository or application data has been corrupted.

A baseline pnpm/Vite build completed successfully before the terminal failure became total, transforming 32 modules.

Operational impact

This is a complete development blocker for a business-critical application. Codex cannot inspect the workspace, edit source files, run builds or report Git status. Continued retries are not practical or safe.

Evidence available

  • Screenshots of each stalled task and elapsed time.
  • Codex’s own failure reports confirming that no files were changed.
  • A saved Codex performance trace.
  • A consolidated Word incident record.
  • Exact workspace path and commands used.

Please investigate the Codex workspace/terminal execution service and advise whether this is related to:

  • Windows PowerShell process initialisation;
  • opening a workspace located within OneDrive;
  • workspace permissions or repository ownership;
  • local security-software interception; or
  • a Codex desktop/backend regression.

Please also confirm whether the performance trace can be uploaded securely and whether any additional diagnostic information is required.
Severe performance degradation preceding the failure

This incident did not begin with the complete terminal failure on 14 July 2026.

Throughout 13 July 2026, Codex performance was severely degraded. Development tasks that would ordinarily complete within minutes took hours. One task ran for approximately 1 hour 52 minutes, despite being of a type and scope that had previously completed much more quickly.

The application frequently remained in a working or thinking state for prolonged periods, with very slow or absent terminal feedback. By 14 July, the degradation had progressed to the point where Codex could no longer execute even a single read-only Get-Location command.

The apparent progression was therefore:

  1. Normal performance previously.
  2. Severe slowdown on 13 July, with routine tasks taking hours.
  3. Repeated patch-tool timeouts on 14 July.
  4. Total workspace terminal failure, including Get-Location.
  5. The same total failure persisting after Codex was fully closed and the computer rebooted.

Conversational and non-workspace Codex responses remained fast during at least some of this period. The severe degradation was most apparent when Codex attempted to access or operate within the local SETL workspace.

What steps can reproduce the bug?

  1. Open the Codex desktop app on Windows.
  2. Open a local development workspace stored under D:\OneDrive\[business project]\[application]\app_source.
  3. Start a new task.
  4. Ask Codex to run only the read-only PowerShell command:

Get-Location

  1. The shell does not return any output. The task remains working indefinitely and must be stopped manually.

The issue has been reproduced across multiple fresh tasks. It also persists after completely closing Codex, clearing remaining processes and rebooting the computer.

Other failed checks included:

Get-Location; Get-ChildItem -Force | Select-Object -ExpandProperty Name; Test-Path -LiteralPath package.json; git status --short --branch

That command produced no output and was terminated after 40 seconds.

A separate implementation task ran for 16 minutes 18 seconds because the patch mechanism repeatedly timed out before writing even a one-line change.

The simplest post-reboot reproduction, Get-Location alone, remained unresponsive for more than 1 minute 31 seconds.

No source files were changed during these tests.

Session ID: [INSERT IN-APP FEEDBACK SESSION ID HERE, OR WRITE “NOT YET AVAILABLE”]

What is the expected behavior?

Get-Location should return the current working directory almost instantly.

Codex should be able to inspect the workspace, execute read-only terminal commands, edit files, run builds and perform Git checks without indefinite terminal stalls.

Routine development tasks that ordinarily take minutes should not take hours.

Additional information

The complete terminal failure was preceded by severe performance degradation on 13 July 2026.

Routine development tasks that would ordinarily complete within minutes took hours. One task ran for approximately 1 hour 52 minutes. Codex frequently remained in a working or thinking state for prolonged periods, with very slow or absent terminal feedback.

By 14 July, the degradation had progressed through repeated patch-tool timeouts to total workspace terminal failure. Even Get-Location could no longer execute.

Conversational and non-workspace Codex responses remained fast during at least some of this period. The problem was most apparent when Codex attempted to access or operate within the local workspace.

A baseline pnpm/Vite build completed successfully before the terminal failure became total. There is currently no evidence of repository corruption.

Impact: complete development blocker for a business-critical application.

Screenshots, a performance trace and a consolidated evidence report are available privately on

View original on GitHub ↗

8 Comments

howardsloane-boop · 6 days ago

Clarification:

No in-app feedback/session ID was displayed. In-app bug feedback was submitted from my signed-in ChatGPT Pro account on 14 July 2026 with the affected session logs included.

The anonymised workspace structure is:

D:\OneDrive\[business project]\[application]\app_source

Screenshots, the saved performance trace and the consolidated evidence report are available privately on request. They have not been uploaded publicly because they may contain confidential workspace information.

github-actions[bot] contributor · 6 days ago

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

  • #33010
  • #31908

Powered by Codex Action

howardsloane-boop · 6 days ago

Update: the in-app feedback upload has now completed.

Feedback ID:
019f6071-a89c-71d0-b3e9-6879d320859f

The feedback was submitted from my signed-in ChatGPT Pro account with the affected session logs included. This Feedback ID should connect the GitHub issue to the private diagnostic submission.

howardsloane-boop · 6 days ago

Further reproduction — 14 July 2026, approximately 20:54 BST

The problem has recurred in a new Codex task within the affected Project DELTA workspace.

A simple read-only health check was requested to confirm:

  • the local date/time;
  • the current workspace path; and
  • whether package.json exists.

Codex worked for 2 minutes 24 seconds. It returned the date/time and workspace path, but could not confirm whether package.json existed because the read-only local checks did not return and had to be stopped.

Codex confirmed that:

  • SETL was not started; and
  • no files were changed, created or deleted.

This demonstrates that the workspace execution failure remains intermittent. An earlier simple test completed successfully, but this subsequent test again stalled on a basic read-only filesystem operation.

Screenshot attached.

<img width="974" height="537" alt="Image" src="https://github.com/user-attachments/assets/8f08af32-f0a9-40b3-a54b-0e09dde7547f" />

howardsloane-boop · 6 days ago

<img width="964" height="637" alt="Image" src="https://github.com/user-attachments/assets/48032fe6-625e-4b4e-a656-193b956ed9e9" />

mythofkas-commits · 4 days ago

yes. I've had the same exact intermittent problem.
It seems it's related to 'elevated' sandbox config flag. When I change it to 'unelevated' it goes away, but that's not a preferred choice for strong Windows sandbox.
This has started ever since Codex and chatgpt apps were combined - same day gpt 5.6 came out.

mythofkas-commits · 4 days ago

I found the issue I believe. It happened on July 8th with a PR here that changed the old inherited windows codexsandboxusers permissions which was unsafe, but since the update, Codex detecs the old permissions setup, tries to correct it, but ultimately fails to remove the inherited one from a child folder. This happens for every single attempt to run commands on Codex app, making them stall for 50-60 seconds.
If you remove the obsolete explicit CodexSandboxusers '0x1301FF' ACEs from your main drive and user folder, the issue should be resolved and reserved even after future app updates - I think lol
Definitely back it up beforehand but it doesn't affect anything else or modify or remove any file. It's actually more secure.

OR you could also change 'elevated' in your codex config file to 'unelevated' lol
I guess that might be a simpler temporary solution.

GeyerT · 17 hours ago
I found the issue I believe. It happened on July 8th with a PR here that changed the old inherited windows codexsandboxusers permissions which was unsafe, but since the update, Codex detecs the old permissions setup, tries to correct it, but ultimately fails to remove the inherited one from a child folder. This happens for every single attempt to run commands on Codex app, making them stall for 50-60 seconds. If you remove the obsolete explicit CodexSandboxusers '0x1301FF' ACEs from your main drive and user folder, the issue should be resolved and reserved even after future app updates - I think lol Definitely back it up beforehand but it doesn't affect anything else or modify or remove any file. It's actually more secure. OR you could also change 'elevated' in your codex config file to 'unelevated' lol I guess that might be a simpler temporary solution.

Many thanks, this solved the issue for me.
The quickfix is running he Sandbox as "unelevated" - but solving the ACE issue lead to a working sandbox in "elevated" mode again.