Codex Stuck on "Running command"? Test Workspace Dependencies

If every local command in Codex for Windows stays on Running command, first run the same harmless command outside Codex and then repeat it from a fresh, empty Codex project. If the command works outside Codex but hangs in every Codex project, open Settings > Workspace Dependencies, record the Diagnose result, choose Reset and Install Workspace, start a new task, and retry one command.

That reset repaired one documented failure in about two minutes, with the next command finishing in 416 ms. It is not a universal fix. A second reporter had the same visible symptom but the reset did not help, and a large real workspace could reproduce hangs that an empty project did not. The controlled checks below separate those variants before you delete files, weaken the sandbox, or reinstall the app.

Match the Exact Symptom

Use this guide when:

• Codex reaches a tool call, but the card remains on Running command indefinitely;

• even Get-Date or cmd.exe /d /c echo CODEX_OK hangs inside Codex;

• the same command returns promptly in a normal PowerShell or Command Prompt window;

• restarting Codex, Windows, or the app did not reliably fix it; or

• an empty project and a real workspace behave differently.

Use a different diagnosis when Codex prints a concrete process error such as CreateProcessAsUserW failed, spawn EPERM, or Access is denied. Those failures reach a narrower process or permission boundary and are covered by the Codex Windows sandbox error guide.

Prerequisites

Before testing:

• save or commit work you need to preserve;

• stop other Codex tasks so the first test is sequential;

• record the Codex app version from About;

• note the exact local time when the next hang begins; and

• do not delete a workspace, dependency directory, or .codex state to make the symptom disappear.

The diagnostic commands below are read-only except for creating one empty folder under your user profile. They do not modify the affected repository.

Step 1: Prove the Windows Shell Still Works

Open PowerShell outside Codex and run:

cmd.exe /d /c echo CODEX_OK
Get-Date

Expected result: CODEX_OK and the current date appear promptly. If these commands also hang outside Codex, stop here. The problem is not isolated to Codex, so investigate Windows, disk health, endpoint security, or the shell itself first.

This check matters because the selected GitHub report measured PowerShell completing outside Codex in 0.21 seconds while the Codex command never spawned.

Step 2: Compare an Empty Local Project

Create a clean folder under your Windows profile:

$smoke = Join-Path $HOME 'codex-smoke-test'
New-Item -ItemType Directory -Force -Path $smoke | Out-Null
Set-Location $smoke

Open that folder as a new Codex project and ask Codex to run exactly one command:

Run cmd.exe /d /c echo CODEX_OK and report only the output and elapsed time

Wait for that command to finish or clearly hang before starting another task.

Expected result: the marker completes in the empty project. If it does, the command runner can start, so compare the real workspace in Step 6. If the empty project also hangs, continue with the dependency and dispatch checks.

One independent report completed three sequential commands in a fresh empty project in 9, 6, and 8 seconds, then hung again after returning to a real project on a busy drive. The empty control is therefore a classifier, not proof that the installation is fully healthy.

Step 3: Check Whether the Sandbox Log Reached This Attempt

Immediately after reproducing the hang, run this outside Codex:

$sandboxLog = Join-Path $HOME '.codex\.sandbox\sandbox.log'

if (Test-Path -LiteralPath $sandboxLog) {
  Get-Item -LiteralPath $sandboxLog | Select-Object FullName, LastWriteTime, Length
  Get-Content -LiteralPath $sandboxLog -Tail 80
} else {
  'No sandbox.log exists at the expected path'
}

Compare LastWriteTime with the time you recorded. Sanitize usernames, repository names, commands, and file contents before sharing the log.

Expected result: a fresh entry identifies whether dispatch reached the sandbox logger. In the dependency-bundle report, a START line appeared without a matching SUCCESS or FAILURE, and no runner process was created. Another reporter saw no fresh log at all, suggesting a different pre-dispatch variant that the workspace reset did not repair.

Do not treat an old log as evidence about the current hang.

Step 4: Diagnose and Reset Workspace Dependencies

In the Codex app:

1. Open Settings > Workspace Dependencies.

2. Run Diagnose and save the result.

3. Close or stop active Codex tasks.

4. Choose Reset and Install Workspace.

5. Wait for installation to complete.

6. Start a new task in the empty smoke-test project.

7. Run only cmd.exe /d /c echo CODEX_OK.

Expected result: the new task prints CODEX_OK and completes. One reporter found that Diagnose incorrectly said the bundle was healthy, but the reset still restored command execution. A full app uninstall and reinstall had not replaced that persisted bundle.

Do not repeatedly reset dependencies if the first reset completes but the marker still hangs. Move to the next classifier and preserve the evidence for a report.

Step 5: Retest Sequentially

Run three marker commands one at a time. Wait for each to finish before starting the next.

The original issue measured 191 command starts and reported approximate hang rates of 17 percent with one command in the same second, 50 percent with three, and 83 percent with six. That is one environment, not a general benchmark, but it makes concurrency a useful variable to control.

Expected result: three sequential markers complete consistently. If sequential commands work but simultaneous tasks hang, temporarily resume tasks one at a time and include the concurrency difference in the bug report. Do not present sequential dispatch as a permanent fix.

Step 6: If Only the Real Workspace Hangs

Return to the affected workspace in a normal PowerShell window and first record repository state:

git status --short

Then estimate the number of entries. This can itself be slow on a very large tree, so stop it with Ctrl+C if disk use stays saturated:

Get-ChildItem -LiteralPath . -Force -Recurse -ErrorAction SilentlyContinue |
  Measure-Object

Use Task Manager to watch the affected drive while running one marker from Codex. Also preview ignored build output without deleting it:

git clean -ndX

The -n flag is essential: it previews what Git considers removable and changes nothing. Never turn that preview into git clean -fdX until a human has reviewed the list, confirmed that generated files are reproducible, preserved untracked work, and chosen the project's supported cleanup command.

Expected result: you can state whether the empty project works, how large the real tree is, whether the drive saturates, and which reproducible build outputs account for the difference. In one controlled A/B test, a 903,175-file tree took 14,944 ms per command; after the reporter removed 446,587 reproducible node_modules files with reviewed cleanup, the same command took 375 ms. The report said the tree walk did not respect .gitignore in that version.

Prefer the repository's documented clean command for generated output. Do not blindly delete node_modules, worktrees, caches, or the project to chase a timing improvement.

Step 7: Escalate the Variant the Tests Actually Found

If the reset fails, search the OpenAI Codex issue tracker for the exact signature. Add evidence to a matching issue or create a minimal report with:

• Codex app and command-runner versions;

• Windows version and drive type;

• whether the command works outside Codex;

• empty-project and real-project results;

• sequential and concurrent results;

• Workspace Dependencies Diagnose and reset outcomes;

• fresh sandbox-log timestamps and the first relevant sanitized lines;

• approximate file count and observed disk utilization; and

• the smallest command that hangs.

If there is no fresh sandbox log, say that explicitly. If reset repairs the empty project but the real workspace still hangs, do not label the bundle corrupt again without new evidence.

Common Failure Modes

Why This Diagnosis Works

Running command is a UI state, not a root cause. The same card can hide at least three boundaries:

1. persisted workspace dependencies cannot launch the command path;

2. dispatch stalls before a fresh sandbox log is written; or

3. the runner works, but a real workspace and its filesystem metadata make dispatch unreliable or extremely slow.

The outside-shell test proves that Windows can run the command. The empty project removes the real tree as a variable. The fresh log timestamp distinguishes a current sandbox attempt from stale evidence. The one-time dependency reset tests the persisted runtime without deleting the repository. Sequential retesting controls concurrency. Together, those checks turn a generic spinner into a report another person can reproduce.

Verify One External Action After Local Commands Recover

Once three sequential local markers complete, verify that Codex can also use one connected service without placing a provider token in the project. Give Codex this instruction:

Follow https://aident.ai/SETUP.md

Then ask it to search for one connected read-only Action, inspect the input schema, and execute one narrow request. The measurable success condition is one completed read-only Action with no provider API key pasted into the task, shell history, or repository.

For related boundaries, see how to reduce MCP token usage in Claude Code and Codex and how to give AI agents API access without exposing keys.

Ready to test that boundary? Set up Aident Loadout, run one read-only Action, and keep the provider credential out of the workspace.

Sources

• Windows: corrupted workspace dependency bundle halts all shell execution, OpenAI Codex issue, opened July 28, 2026

• Concurrency measurements for commands that never dispatch, issue comment, July 28, 2026

• Controlled workspace-tree A/B measurements, issue comment, July 28, 2026

• Independent Running command report where reset did not repair the variant, issue comment, July 31, 2026

• Empty-project versus real-workspace A/B result, issue comment, July 31, 2026

• Cross-volume cleanup can corrupt a shared workspace dependency bundle, OpenAI Codex issue, opened July 28, 2026

• Codex is always unresponsive, OpenAI Developer Community, July 27, 2026

• Is the new ChatGPT Codex application slower?, OpenAI Developer Community, July 10, 2026

This article reflects public Codex reports available on August 3, 2026. Recheck the current app version and linked issue status before applying a repair.