Windows Codex Desktop Playwright CLI sessions survive completed tasks and accumulate multi-GB Chrome process trees

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

26.715.7063.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

This appears related to #34178, but the environment and browser tool are different:

• #34178 reports agent-browser on macOS.
• This report reproduces with the built-in Playwright skill using @playwright/cli on Windows.
• It includes a Windows-specific session/named-pipe visibility problem: playwright-cli list reports no browsers while the daemon and Chrome process trees remain alive.

Codex Desktop tasks using the built-in Playwright skill can complete without closing their named @playwright/cli sessions.

Each completed task can leave behind a detached cliDaemon.js process and a complete headless Chrome process tree. Repeated browser-research and multi-agent tasks therefore accumulate Playwright sessions, Chrome processes, and memory until Windows experiences virtual-memory exhaustion.

Observed state

After several Codex browser tasks had completed:

• 8 live cliDaemon.js processes
• 8 distinct named Playwright CLI sessions
• 56 Playwright-owned Chrome processes, approximately 7 per session
• approximately 744 MB daemon working set
• approximately 3.84 GB Chrome working set
• approximately 4.58 GB combined working set
• 331 playwright_chromiumdev_profile-* temporary directories, 323 from the previous day
• playwright-cli list returned (no browsers) even though the daemon and Chrome processes were still alive

Windows Event Viewer recorded 69 Microsoft-Windows-Resource-Exhaustion-Detector event 2004 warnings over the preceding three days.

There is no visible Playwright error when the leak occurs. The Codex task reports completion normally. The problem is silent process-lifecycle leakage after task completion.

What steps can reproduce the bug?

Reproduction pattern

1. Start several Codex Desktop tasks or subagents that use the built-in Playwright skill.

1. Each task uses a separate named session and runs commands similar to:

playwright-cli -s=<unique-task-session> open <url>
playwright-cli -s=<unique-task-session> snapshot
playwright-cli -s=<unique-task-session> goto <another-url>

1. Allow the Codex tasks to complete normally.

1. Review the task command history. No matching cleanup command is issued:

playwright-cli -s=<unique-task-session> close

1. Inspect the remaining Playwright CLI daemon processes in PowerShell:

Get-CimInstance Win32_Process |
Where-Object {
$_.Name -eq "node.exe" -and
$_.CommandLine -match "@playwright\\cli.*cliDaemon\.js"
} |
Select-Object ProcessId, ParentProcessId, CommandLine

1. Inspect Playwright-owned Chrome processes:

Get-CimInstance Win32_Process |
Where-Object {
$_.Name -eq "chrome.exe" -and
$_.CommandLine -match "playwright_chromiumdev_profile-"
} |
Select-Object ProcessId, ParentProcessId, CommandLine

1. Run playwright-cli list. In the affected state this can report (no browsers) while the processes found above are still alive.

1. Repeating the workflow with new task-specific session names causes the number of daemon and Chrome processes to grow linearly.

Environment

• Windows 11 x64
• Codex Desktop app version: 26.715.7063.0
• Node.js: 22.17.0
• npm: 10.9.2
• @playwright/cli: 0.1.17
• playwright / playwright-core: 1.62.0-alpha-1783623505000
• Physical RAM: 15.78 GB

Session and context information

The affected Codex session/conversation identifier is intentionally redacted as PII, but it can be provided privately to OpenAI maintainers if required.

Token-limit usage and context-window usage do not appear relevant. The issue reproduces across separate completed browser tasks and is caused by external process/session lifecycle handling rather than model context exhaustion.

What is the expected behavior?

Codex should guarantee cleanup of every browser session created by the built-in Playwright skill when:

• a task completes successfully
• a browser command fails
• a task times out
• a task is cancelled or interrupted
• a subagent completes
• Codex Desktop closes or restarts

Every successful playwright-cli -s=<session> open <url> command should have a matching playwright-cli -s=<session> close cleanup action.

The cleanup command should run in the same privilege and sandbox context used to open the session.

After closing the session, Codex should verify that:

• the named cliDaemon.js process exited
• the complete Playwright Chrome process tree exited
• no playwright_chromiumdev_profile-* Chrome processes remain for that session

If graceful cleanup fails, Codex should report the surviving processes and provide an explicit recovery action instead of silently reporting the task as complete.

On Windows, Codex should also consider managing spawned tool processes through a Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, so terminating the controlling process cannot leave descendants running indefinitely.

Additional information

Local implementation findings

Inspection of the locally installed Playwright CLI shows:

1. Playwright CLI intentionally starts a detached daemon for every named session.
2. Graceful cleanup works when the client can reconnect to the daemon and send the stop request.
3. On Windows, mixing elevated/out-of-sandbox and sandboxed invocations can prevent later commands from reconnecting to the named-pipe session. The browser remains alive but appears closed to playwright-cli list.
4. close-all only processes registry entries visible and connectable from the current client/workspace context.
5. Session.stop() returns without cleanup when it cannot connect to the daemon.
6. kill-all matches Playwright daemon command lines but does not directly match Chrome processes using playwright_chromiumdev_profile-*. If a daemon is force-killed rather than stopped gracefully, Chrome may survive.

Related reports

• https://github.com/openai/codex/issues/34178
• https://github.com/openai/codex/issues/33894
• https://github.com/openai/codex/issues/21994
• https://github.com/openai/codex/issues/17832
• https://github.com/openai/codex/issues/34063
• https://github.com/microsoft/playwright-cli/issues/360
• https://github.com/microsoft/playwright-cli/issues/364
• https://github.com/microsoft/playwright-cli/issues/312
• https://github.com/microsoft/playwright-cli/issues/388

Verified local mitigation

I modified the local Playwright skill to treat open as resource acquisition and require a matching close in a finally path.

A minimal verification produced one Playwright daemon, seven Playwright Chrome processes, and approximately 467 MB working set. After executing the matching session close, the state returned to zero Playwright daemons, zero Playwright Chrome processes, and zero Playwright working set.

I also installed a local Windows guard that periodically audits Playwright session count and memory use. This mitigates the host risk but does not fix the Codex task-lifecycle contract.