Mouse Properties dialog opens unexpectedly on Windows

Screenshot

The Mouse Properties dialog that unexpectedly opens during Codex usage:

<!-- @Flewrider: Please edit this comment to add your screenshot by dragging and dropping the image here -->

---

Fix submitted in #9371

Have you reported this upstream to the Windows Terminal GitHub? If so, can you link to the issue? If not, please file one and include analysis there as well. Ideally, nothing we do at the application level should be able to trigger this kind of behavior, so we should first establish whether this is a terminal bug and how it is being invoked.

Could you also go deeper on the analysis section here? I am missing a concrete causal step that explains how the proposed change prevents the dialog from opening. Right now, it is hard to validate that this specific flag is responsible, or that disabling it is sufficient, without a clearer explanation of the sequence of events that leads to the issue.

No I havent reported it upstream. And I can‘t really tell you how to trigger the issue. I just know that it only happens while codex is running in Windows Terminal in Powershell. I gave the issue to claude code and it deciphered that those flags should be the issue. I have tested it for a while and the Window didnt pop up again but that could also be pure luck since it‘s super random when it happens. Never had that issue with other clis.
I dont have time to go further in this so if noone else is reporting this happening we can close the issue too.

So far, no one else has reported this issue. We can keep the bug report open for a while to see if anyone else reports it.

If you still have the Claude session and can rehydrate it, would you mind asking it to spell out the concrete causal chain that links this flag to the Mouse Properties dialog opening?

Right now we’re missing the step that explains how disabling REPORT_ALTERNATE_KEYS prevents the dialog from triggering, which makes it hard to validate that this is the actual root cause rather than a coincidence.

Claudes rundown on the issue is this:

------------------
What We Know (Facts)

1. REPORT_ALTERNATE_KEYS sends CSI u sequences - When enabled, keys are reported as ESC [ unicode-key:alternate-key ;

modifiers u format (https://sw.kovidgoyal.net/kitty/keyboard-protocol/)

1. ConPTY has documented escape sequence bugs:

• https://github.com/microsoft/terminal/issues/12166: ConPTY modifies/re-encodes escape sequences
• https://github.com/microsoft/terminal/issues/1965: Escape sequences behave strangely over conpty
• ConPTY can do "lossy" parsing and re-serialization of ANSI sequences

1. Mouse Properties opens via main.cpl - No built-in Windows keyboard shortcut triggers this dialog (https://support.m

icrosoft.com/en-us/topic/how-to-run-control-panel-tools-by-typing-a-command-bce95b4d-e8c2-1cd0-ee0d-027679d520a6)

What We Don't Know (Gaps)

1. The exact escape sequence that triggers main.cpl - I cannot identify what specific byte sequence would cause

Windows to launch a Control Panel applet

1. How ConPTY mangling → shell command execution - There's no documented mechanism for how a malformed escape sequence

would result in control main.cpl being executed

1. Whether it's actually REPORT_ALTERNATE_KEYS - The correlation is based on:

• The flag being present in the code
• Known ConPTY issues with escape sequences
• The timing of when the dialog appears (during TUI operation)

Honest Assessment

The investigation identified REPORT_ALTERNATE_KEYS as a suspect because:

• It's a Windows-unfriendly feature (kitty protocol isn't fully supported on Windows Terminal)
• It adds complexity to the escape sequences being sent
• ConPTY has documented issues handling such sequences

But I cannot provide a concrete sequence X → conpty bug Y → main.cpl launch chain.

To properly prove causation, you'd need:

1. Capture raw escape sequences being sent when the dialog appears
2. Identify exactly which sequence correlates with the dialog
3. Reproduce by manually sending that sequence

---------------

This doesnt seem to be very specific.
I found this random stackoverflow post from 8 years ago (thank god for stackoverflow and reddit am i right): Why does running main in powershell open my mouse properties
which seems to be correlated to my issue.
-> I can confirm typing main in my terminal opens the dialog window.

Claudes assessment on the issue:

---------------

The "main" → main.cpl

On Windows:

1. .CPL is in PATHEXT (typically ...;.CPL;...)
2. main.cpl exists in C:\Windows\System32 (which is in PATH)
3. Typing "main" in a shell resolves to main.cpl and executes it
4. Mouse Properties opens (since main.cpl @0 = Mouse Properties)

The Missing Link

What we still don't know: How does Codex cause "main" to be executed as a shell command?

Possible mechanisms based on https://github.com/microsoft/terminal/issues/1965:

Theory A: Escape sequence corruption → literal text

1. Codex sends escape sequences (keyboard enhancement, mouse capture, etc.)
2. Due to ConPTY bugs (split writes, lossy parsing), part of the sequence isn't interpreted as an escape code
3. Raw bytes appear as literal text in the terminal
4. If that text happens to spell "main" and gets interpreted as input...

Theory B: Input mode confusion

1. With REPORT_ALTERNATE_KEYS enabled, https://github.com/microsoft/terminal/issues/17656 can re-encode VT sequences
2. This re-encoding could produce unexpected input that gets typed into the shell
3. If that input produces "main"...

What Would Prove This

To establish the actual causal chain, you'd need to:

1. Capture terminal I/O when the dialog appears (log all bytes sent/received)
2. Identify the exact sequence that precedes the dialog opening
3. Reproduce by manually sending that

The current fix (disabling REPORT_ALTERNATE_KEYS on Windows) may work by reducing the complexity of escape sequences sent, making ConPTY corruption less likely—but it's treating a symptom rather than a proven root
Do you want me to help add some debug logging to capture terminal I/O so we can catch the actual trigger?

-> it does seem to be based on some escape character issues making main (my project im working on has a main section since its next.js based) be interpreted as a command.

(sry for formatting i dont know why that one part is a weird code block)

Ok, we're going to close out the PR for now.

At this point we really need a proper minimal reproducible example. The current theory is plausible, but without a concrete repro chain it’s hard to validate that this flag is the actual cause rather than a coincidence.

One possible next step would be to use your preferred coding agent to build a very small executable test harness and explore it until you can identify the exact sequence of events that triggers the dialog. Capturing raw terminal I/O when it happens would likely be necessary to prove causation here.

We’d prefer not to disable REPORT_ALTERNATE_KEYS at this time for two reasons:

1. Windows Terminal may eventually support this behavior correctly: https://github.com/microsoft/terminal/issues/11509
2. Other Windows terminals (for example WezTerm) already support it today

I’m going to close the PR for now, but please feel free to continue investigating a minimal repro. If you do find one, we’d be open to a more narrowly scoped change, such as disabling this only for Windows Terminal rather than Windows as a whole.

I’m experiencing the same issue. It happens at seemingly random moments and the Mouse Properties window suddenly opens.
In my case, this occured twice while using the Codex plugin in Visual Studio Code on Windows. I haven't encountered this problem when using Codex CLI so far.

I noticed it happen twice today both times when the agent used this:

• Ran Get-Content app\(main)\admin\settings\page.tsx
└ Get-Content:
Line |
2 | Get-Content app\(main)\admin\settings\page.tsx
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| A positional parameter cannot be found that accepts argument '$null'.

and both time when it failed with the same message.

I also experience the same issue using codex in powershell on windows. Can't consistently reproduce it but it does happen when working on a repo with (main) in the path, e.g. src/routes/(main)/+page.svelte

Edit - caught it opening today, here is the line that triggered it:

Ran Get-Content -Path frontend/src/routes/(main)/+page.svelte
  └ Get-Content : A positional parameter cannot be found that accepts argument '$null'.
    At line:2 char:1
    … +3 lines
        + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.GetContentCommand

edit2: here's another one that just opened the mouse properties window.

Ran git diff -- frontend/src/routes/(main)/admin/shows/+page.server.js
  └ fatal: Invalid path '/admin': No such file or directory

It's still intermittent, it will often successfully run git diff on files inside the (main) folder with no issue.

Confirming this also happens using the VS code Codex extension 0.4.71 directly.

this issue is still active on version 0.4.74

happens in 0.4.76 vscode extension. opens 3-4 mouse properties (idk, maybe more?). can't repro consistently.

happens in 0.4.76 vscode extension. opens 3-4 mouse properties (idk, maybe more?). can't repro consistently.

0.4.78 - haven't experienced this again.

Hi, I'm not really familiar with github, but i noticed this discussion when googling, and i must mention this issue has happened to me when interacting with external api's in both codex and google's antigravity.
Edit: I see a user using claude also gets this issue: https://www.reddit.com/r/codex/comments/1rsx91r/codex_casually_opens_mouse_properties_on_windows/

This is happening to me too. Super annoying when using Codex.

<img width="419" height="469" alt="Image" src="https://github.com/user-attachments/assets/48207036-2542-41fb-8b21-07f14ba87ca3" />