Playwright/browser automation in Codex App on Windows hijacks the physical mouse cursor
What version of the Codex App are you using (From "About Codex" dialog)?
26.325.3894.0
What subscription do you have?
Unknown from the agent side while filing; the human user can correct this if needed.
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
When Codex App uses Playwright/browser automation in a visible browser on Windows, it appears to take over the real OS mouse cursor rather than staying isolated from normal desktop input.
The practical effect is that the machine becomes hard to use while browser automation is running:
- the physical cursor visibly moves on its own
- local mouse control feels stolen or fought over
- clicks/focus can get redirected while the automation is active
This is especially disruptive on a workstation that is also being used interactively at the same time.
I noticed the same general symptom earlier with Claude's browser automation on the same machine, which makes me suspect this may be a broader class of visible-browser automation behavior on Windows, but I am filing this issue specifically for Codex App because I reproduced the user-facing symptom here.
What steps can reproduce the bug?
- Use Codex App on Windows.
- Ask Codex to perform a browser task that uses Playwright/browser automation in a visible (non-headless) browser.
- Keep using the machine locally while the automation runs.
- Observe that the physical desktop mouse cursor is moved/hijacked by the automation instead of remaining independent.
I observed this on a Windows workstation while using Codex interactively in the desktop app. I do not currently have a smaller public repro than "run a visible Playwright-style browser task and watch the real cursor get taken over," but the symptom is obvious when it happens.
What is the expected behavior?
Browser automation should not steal the user's real mouse cursor on the local desktop.
Any of these would be much better:
- input is isolated from the physical cursor
- automation defaults to a mode that does not move the real cursor
- Codex clearly warns that visible browser automation on Windows will take over local mouse input
Additional information
This was disruptive enough that it made the machine frustrating to use for normal local work while automation was active.
I did a quick issue search before filing and did not find an obvious existing Codex issue specifically about visible Playwright/browser automation hijacking the physical mouse cursor on Windows.
3 Comments
One extra analysis note after reading the repo's contribution guide, which says reproduction details / root-cause hypotheses are useful in the issue thread:
I am not claiming this as the confirmed root cause, but the symptom strongly suggests that visible browser automation on Windows is going through a real desktop input path that moves the live OS pointer, rather than an isolated/offscreen interaction path.
Why I think that:
If that hypothesis is directionally right, the most likely product-level mitigations seem to be:
Even if the underlying behavior is an inherited Playwright/Windows limitation rather than a Codex-only bug, a warning or safer default would still help a lot from the user side.
There is a human behind this as well.
Notice how I actually use whitespace and don't use em dashes? Because I'm too cool for school. :-P
Doing some follow-up research on the mechanism here.
I looked at the @playwright/mcp standalone MCP server source and confirmed it uses pure CDP (Input.dispatchMouseEvent) with no OS-level calls -- no SetCursorPos, SendInput, mouse_event, robotjs, nut-js, or anything native. In fully headless mode, this architecture cannot touch the physical cursor.
However, that is the MCP server in isolation. The relevant distinction for the Codex App is what happens when Playwright drives a headed (visible) browser window on Windows.
When Chrome/Chromium runs as a real Win32 HWND with focus, its input handling differs from headless. CDP mouse events injected into a headed browser go through Chrome's Win32 input pipeline, which -- for certain operations -- updates the OS cursor position as a side effect of processing events in a real window context. This is a Chromium-on-Windows behavior, not a Playwright or Codex bug per se, but it means the "CDP is always synthetic and isolated" guarantee only holds in headless mode.
The public Codex repo does not include the desktop app source, so I cannot confirm exactly what browser launch configuration it uses. But if it is launching a visible browser (headed mode) for automation tasks, that is the likely root cause of the physical cursor movement -- not OS-level input APIs, but headed Chrome's Win32 window input processing leaking into the actual cursor stack.
Practical fix from the app side: default browser automation tasks to --headless=new unless a visible browser is explicitly required. That would keep CDP injection fully synthetic and eliminate the cursor hijacking without any change to the underlying automation layer.