Codex on Windows breaks Playwright Firefox: SxS launch failure and Juggler handshake hang

Summary

Codex on Windows cannot reliably run Playwright Firefox tests in its execution environment, while the exact same Playwright Firefox binary and the exact same tests work correctly from a normal PowerShell session on the same machine.

Chromium and WebKit work successfully from the same Codex environment.

The failure has two reproducible stages:

1. Playwright Firefox launched from the normal %LOCALAPPDATA%\ms-playwright cache fails before the test body starts with browserType.launch: spawn UNKNOWN and a Windows Side-by-Side activation error.
2. A byte-identical copy of the same Firefox build placed inside the workspace launches successfully, including Firefox child processes, but Playwright then hangs while establishing the Firefox/Juggler session and no test completes.

This appears to be specific to the Codex on Windows execution environment rather than the project, Playwright installation, Firefox binary, or Windows installation.

The Windows sandbox / restricted process environment may be involved, but the exact root cause is not yet confirmed.

Environment

• OS: Windows x64
• ChatGPT desktop app version: 26.901.51231
• App mode: Codex
• Powered by: Codex & OWL
• Subscription: ChatGPT Plus
• Active task permission mode: Approve for me
• Global Settings > General > Permissions shows Full access enabled
• Playwright: 1.63.0
• playwright-core: 1.63.0
• Playwright Firefox revision: 1543
• Firefox version: 155.0
• Firefox architecture: x64

The desktop Settings UI shows Full access enabled globally, while the affected Codex task itself runs with Approve for me selected in the composer. I am reporting both UI states because their exact interaction/effective execution policy is not clear from the product UI.

Playwright Firefox executable:

C:\Users\<user>\AppData\Local\ms-playwright\firefox-1543\firefox\firefox.exe

Other Playwright browser executables used successfully from the same Codex environment:

Chromium:

C:\Users\<user>\AppData\Local\ms-playwright\chromium-1243\chrome-win64\chrome.exe

WebKit:

C:\Users\<user>\AppData\Local\ms-playwright\webkit-2359\Playwright.exe

Expected behavior

Codex should be able to run normal Playwright Firefox projects on Windows in the same way it runs Chromium and WebKit.

A standard Playwright command using:

--project=firefox

should launch the patched Playwright Firefox binary, establish the Playwright/Juggler connection, and execute the tests.

Actual behavior

1. Firefox from the normal Playwright cache

Inside the Codex execution environment, Firefox fails before any test body runs:

browserType.launch: spawn UNKNOWN

Direct launch of the same executable from that environment produces the Windows error:

The application has failed to start because its side-by-side configuration is incorrect.

The Windows error corresponds to:

ERROR_SXS_CANT_GEN_ACTCTX (14001)

For the final focused suite, all 14 attempted Firefox tests fail at browser launch before entering the test body.

2. The same Firefox outside Codex works

From a normal PowerShell session on the same machine, using the same repository, the same Playwright installation, the same Firefox revision, and the same final focused test suite:

13 passed
1 skipped

The skipped test is intentionally Chromium-only.

There are no Firefox test failures.

Therefore the Playwright Firefox installation and the application tests themselves are functional.

3. Byte-identical workspace copy changes the failure

As a diagnostic experiment only, the complete firefox-1543 directory was copied from %LOCALAPPDATA%\ms-playwright into a temporary directory inside the workspace.

The original and copied firefox.exe were verified to be byte-identical.

SHA-256:

425A0A0FB606F567A303BDCEA727476E124C0DEB589050B13668AF688DA17FCB

Results:

• Original executable from %LOCALAPPDATA%: Windows Side-by-Side launch failure.
• Byte-identical workspace copy: launches successfully and prints Mozilla Firefox 155.0.

This demonstrates that executable location changes Firefox behavior inside the Codex execution environment even though the binary itself is identical.

4. Playwright with the workspace copy gets further but still does not work

A temporary PLAYWRIGHT_BROWSERS_PATH was pointed at the workspace copy.

With this configuration:

• spawn UNKNOWN disappeared;
• Playwright successfully created Firefox;
• Firefox child processes were created from the workspace copy;
• the Playwright runner entered the first test.

However, the Firefox/Playwright session never completed its handshake.

The first test remained stuck for more than two minutes and zero tests completed, so the diagnostic run was stopped.

The temporary directory and its processes were then removed.

This indicates that executable location affects the initial launch failure, but it is not the only problem. There appears to be an additional incompatibility in the Codex execution environment involving the Firefox/Playwright session after process creation.

Possible areas include Firefox child processes, inherited handles, IPC, the Juggler pipe, or temporary Firefox profile access. These are hypotheses, not confirmed root causes.

Additional diagnostics

The relevant Windows environment variables inside the Codex execution environment are present and valid:

SystemRoot = C:\windows
WINDIR = C:\windows
COMSPEC = C:\windows\system32\cmd.exe
LOCALAPPDATA = C:\Users\<user>\AppData\Local
APPDATA = C:\Users\<user>\AppData\Roaming
USERPROFILE = C:\Users\<user>

Explicitly overriding:

SystemRoot = C:\Windows
WINDIR = C:\Windows

does not change the Firefox failure.

So missing or invalid SystemRoot / WINDIR is not the cause.

The Firefox cache was also inspected:

• installation markers are present;
• the distribution appears complete;
• the original directory can be enumerated successfully;
• Test-Path for the Firefox executable returns True;
• mozglue.dll and xul.dll are present and loadable;
• the same build works from normal PowerShell;
• the same build can be launched from the workspace copy.

Microsoft Visual C++ runtime installation was also checked and there is no evidence that the VC++ runtime is the cause.

Important comparison

The problem is Firefox-specific in this Codex environment.

Playwright Chromium and WebKit are also stored under:

%LOCALAPPDATA%\ms-playwright

and are successfully launched and tested by Codex.

Therefore this does not appear to be a simple blanket restriction on %LOCALAPPDATA%.

Firefox has different process and IPC behavior, so the remaining failure may involve a Codex on Windows process-execution interaction with Firefox child processes or the Playwright Firefox/Juggler transport.

Again, that is a hypothesis rather than a confirmed root cause.

Reproduction outline

1. Use Codex on Windows with a normal Playwright project containing Chromium, Firefox, and WebKit projects.
2. Install Playwright browsers normally.
3. Run Chromium tests from Codex.
   • They pass.
4. Run WebKit tests from Codex.
   • They pass.
5. Run Firefox tests from Codex.
   • Firefox fails before test execution with spawn UNKNOWN / Windows Side-by-Side activation failure.
6. Run the same Firefox tests from a normal PowerShell session on the same machine.
   • They pass.
7. Copy the same Playwright Firefox revision into a temporary workspace directory and point a temporary PLAYWRIGHT_BROWSERS_PATH at it.
   • Firefox now launches.
   • Firefox child processes are created.
   • Playwright begins the first test.
   • The Firefox/Juggler handshake then hangs and no test completes.

Impact

This prevents Codex from performing reliable cross-browser verification on a normal Windows development machine.

The practical workaround is to manually rerun Firefox tests outside Codex, which defeats part of the purpose of using a coding agent for implementation and verification.

It also causes substantial agent time and paid usage to be spent diagnosing Codex's own execution environment instead of the user's project.

Users should not need to relocate Playwright browsers, investigate Windows Side-by-Side activation, experiment with environment variables, or manually repeat Codex verification steps for a standard Playwright Firefox workflow.

Request

Please investigate this as a Codex on Windows process execution compatibility issue with Playwright Firefox.

The Windows sandbox / restricted process environment may be involved, but the exact root cause is not yet confirmed.

The most useful areas to investigate appear to be:

• why the same byte-identical Firefox binary receives an SxS activation failure from %LOCALAPPDATA% but launches from a workspace directory;
• Firefox child-process behavior under the Codex Windows execution environment;
• inherited process handles / IPC used by Playwright Firefox;
• the Playwright Firefox/Juggler pipe handshake;
• temporary Firefox profile access and permissions;
• the interaction between task-level Approve for me and the global Full access permission setting.

I am happy to provide additional targeted diagnostics if a maintainer identifies a specific Windows trace, process/handle diagnostic, or reproduction experiment that would help.

Start by reproducing the Windows Codex failure with the Playwright --project=firefox entry point, comparing the normal %LOCALAPPDATA% browser path with a workspace copy and PLAYWRIGHT_BROWSERS_PATH. Trace the Windows process-launch and Firefox/Juggler handshake behavior; done means Firefox tests launch and complete reliably in Codex while Chromium and WebKit remain functional.