nootn
July 5, 2026, 1:00am
1
Codex UI unusable on Windows sometimes after using browser or terminal - gets a hand icon and it won’t go away. In the background the UI is still updating, I just can’t performa an actions becuase the cursor is locked on a hand icon and won’t let me press anything. Tabbing around to diffferent fields also works.
Screenshot 1 shows what the icon looks like, looks kind of like a “drag down” icon. Basically the whole surface is unusable at this point, I can’t press on anything, I have to restart to get it working again.
If I do ctrl+shift+p for example, an overlay comes over the top of the main surface, and that works! So it’s like the main surface is the only thing that has the issue.
Another example, say I have the hand issue, like this, then I right click, it shows the “select all” menu!
EricGT
July 5, 2026, 10:35am
2
Welcome to the forum!
You are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex .
There is a recent issue that looks similar to this problem.
opened 12:00AM - 10 Jun 26 UTC
bug
windows-os
app
browser
### What version of the Codex App are you using?
OpenAI.Codex `26.608.1337.0`
… Observed executable/runtime details from local process inspection:
- Package: `OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0`
- Chromium/Codex executable version shown in process annotations: `149.0.7827.54`
- Renderer processes use `--device-scale-factor=1.5`
### What platform is your computer?
Windows x64
Observed locally:
```text
Microsoft Windows NT 10.0.26200.0 x64
```
### What issue are you seeing?
The Codex Desktop in-app browser on Windows shows persistent cursor jitter/flicker while hovering over a local web app. The visible pointer alternates between the expected hand/pointer state and the normal arrow. The user describes it as the cursor jittering or flipping between the hand and arrow.
Important details:
- This happens in the Codex in-app browser.
- The same app in regular Chrome does **not** reproduce the problem.
- The symptom appears across the in-app browser/app surface, not just one route or one element.
- It was first noticed recently; the same local app was reportedly behaving correctly a day or two earlier.
- The app being viewed is a local development app at `http://localhost:5262/`, but rollback testing makes this look unlikely to be caused by that app's current code.
### What steps can reproduce the bug?
Current reproduction case:
1. Open Codex Desktop on Windows.
2. Open the in-app browser.
3. Navigate to a local app such as `http://localhost:5262/`.
4. Move the mouse over interactive areas such as a map, memorial/list surface, or other hoverable page areas.
5. Observe the physical cursor flickering/jittering between the hand/pointer and arrow cursor.
### Expected behavior
The cursor should remain stable over the same hover target.
For example, when hovering over an interactive map/pan surface or clickable item, it should stay in the expected hand/pointer/grab state and should not repeatedly flip back to the default arrow.
### Actual behavior
The cursor visibly jitters/flickers between cursor shapes, most noticeably hand/pointer and arrow. This makes the app feel unstable and hard to use inside the Codex in-app browser.
### Local diagnostics and mitigations already tried
We tested this as a Codex/browser-layer problem rather than a local web-app code problem because regular Chrome does not reproduce it.
Tried and did **not** fix it:
- Restarted the local app server.
- Restarted the Codex app.
- Restarted Windows.
- Uninstalled and reinstalled Codex Desktop.
- Updated from `26.602.9276.0` to `26.608.1337.0` through reinstall.
- Reset the Codex embedded browser profile by moving:
`C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\Codex\web\Codex`
to a timestamped backup and allowing Codex to recreate it fresh.
- Tested the same local app with rollback worktrees/builds from several earlier dates, including May 26, June 2, and June 6 versions. The cursor still jittered in Codex's in-app browser.
- Temporarily disabled/removed a Browser Use config test; disabling Browser Use did not fix the cursor jitter.
- Temporarily tested a per-app Windows DPI override for Codex. It changed display behavior but did not fix the cursor jitter, and was removed.
- Confirmed there is no active per-user AppCompat DPI override remaining for Codex.
- Confirmed the local app data/status remained healthy while testing; the issue was visual/input behavior in Codex's browser surface.
### Why this does not look like the local app's current code
- The same local app works normally in Chrome.
- The problem reproduces in Codex's in-app browser across multiple older versions of the local app code.
- Reinstalling Codex and recreating the Codex embedded-browser profile did not fix it.
- The symptom feels like a cursor/hit-test/input-layer issue in the Codex Windows in-app browser rather than a single CSS rule or route-level problem.
### Related issues found during research
These are not exact duplicates, but they appear related to the same Windows Codex/browser/input/cursor layer:
- #16188: Playwright/browser automation in Codex App on Windows hijacks the physical mouse cursor
- #26325: Codex Desktop in-app browser annotations lose focus when pressing Space
- #25200: Windows Computer Use makes system cursor invisible after every session
- #26401: Windows Codex app micro-freezes, with Browser/IAB/Computer Use initialization showing in logs
- #25352: Windows Codex app edge hover/popup menu behavior interfering with mouse use
I did not find an exact existing report for "Codex in-app browser hand/arrow cursor jitter," so filing this as a separate issue.
### Additional notes
This was reported from a real local debugging session where the user repeatedly confirmed the cursor jitter still reproduced after each attempted app/browser reset. The user specifically emphasized that Chrome was fine and the problem was inside Codex's in-app browser.
If that issue matches your problem, consider adding a
If it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.
reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.