Windows app leaves PowerShell child processes running after an unbounded recursive scan

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

Codex desktop app package version: 26.715.4045.0

What subscription do you have?

Pro

What platform is your computer?

Windows 11

What issue are you seeing?

Summary

On Windows, the Codex desktop app started an unbounded recursive PowerShell search across my complete user profile.

The command continued running after the conversation had moved on and spawned a Windows PowerShell 5.1 compatibility child process. Both processes remained active until I terminated them manually.

This resulted in locked temporary files and may cause sustained CPU, disk, and memory usage.

Environment

• Codex desktop app package version: 26.715.4045.0
• Operating system: Windows 11
• Shell: PowerShell 7.6.2
• Compatibility host: Windows PowerShell 5.1
• Authentication: ChatGPT login
• Workspace: projectless Codex workspace
• Session ID: 019f7da6-e113-7971-9ea9-dc0645c15d78

Observed command

Codex started a command with this general shape:

Get-ChildItem -Path 'C:\Users\<user>' -Filter '<external-handoff-file>.md' -Recurse -File -ErrorAction SilentlyContinue

This searched the complete Windows user profile, including AppData and other large directory trees.

The live process tree was:

ChatGPT.exe
└─ codex.exe
└─ pwsh.exe
└─ powershell.exe

The PowerShell 5.1 child was started with:

-Version 5.1 -s -NoLogo -NoProfile

The use of -NoProfile confirms that the user's PowerShell profile was not responsible.

What steps can reproduce the bug?

These are the observed steps. I have not yet reduced the issue to a completely deterministic minimal reproduction.

1. Start the Codex Windows desktop app.
2. Open a projectless workspace outside the normal repository root.
3. A bounded custom SessionStart hook reports an external handoff file using a relative path.
4. Codex cannot directly resolve that path from the current workspace.
5. Codex starts a recursive PowerShell search across C:\Users\<user>.
6. Continue the conversation or move on from the command.
7. Inspect the running processes with:

Get-CimInstance Win32_Process -Filter "Name='pwsh.exe' OR Name='powershell.exe'" | Select-Object ProcessId,ParentProcessId,Name,CommandLine

1. Observe a pwsh.exe process owned by codex.exe and a Windows PowerShell 5.1 child process.
2. The processes remain active until manually terminated.
3. Some temporary files remain locked while these processes are running.

The affected live process was created on 2026-07-20 at approximately 06:53 local time.

What is the expected behavior?

Codex should:

1. Avoid recursively searching an entire Windows user profile for one known file.
2. Prefer bounded search roots and tools such as rg --files.
3. Apply a timeout to potentially expensive recursive searches.
4. Cancel the complete process tree when a command times out, is interrupted, or the task moves on.
5. Clean up PowerShell compatibility sessions and temporary proxy modules.
6. Warn before recursively scanning %USERPROFILE%.
7. Avoid repeating the same expensive search after reopening Codex.

Additional information

Restart clarification

At first, this looked like a process that had survived a Windows restart.

Further investigation showed that the previous process had been terminated by the restart, but Codex created a new instance of the search after the app was opened again.

The searched handoff filename was several days old, while the live process creation timestamp was from the current day. Historical temporary directories remained on disk across restarts, making the process appear older than it actually was.

Temporary directory impact

Many directories with names similar to the following accumulated under %TEMP%:

remoteIpMoProxy_DnsClient_1.0.0.0_localhost_<guid>

Some could not be removed because files inside them were held open by active PowerShell processes.

A typical error was:

The process cannot access the file because it is being used by another process.

Administrator privileges and -Force did not help because these were active file locks rather than permission errors.

Local configuration assessment

There is also a local configuration issue: the SessionStart hook supplied an external handoff using a relative path in a projectless workspace.

The hook itself is bounded, read-only, starts no child processes, and does not perform the recursive search. I will correct the local path handling separately.

However, the Codex runtime should still bound and terminate a shell command and its child processes when an agent proposes an overly broad search.

A total of 253,488 matching temporary directories were counted. A second measurement after 10 seconds returned the same count, confirming that directory generation had stopped and that this was a stable accumulated backlog.

Related reports

I searched the existing issues and did not find an exact duplicate.

Potentially related reports:

• https://github.com/openai/codex/issues/17229
• https://github.com/openai/codex/issues/22085
• https://github.com/openai/codex/discussions/14758

Those reports concern child-process cleanup or high resource usage on Windows. This report adds a concrete pwsh.exe to powershell.exe process chain, an unbounded recursive filesystem scan, locked PowerShell proxy directories, and evidence that the process was recreated after restarting and reopening Codex.

I can provide sanitized screenshots, process timestamps, sanitized command lines, relevant session logs, and the bounded SessionStart hook if requested.