Windows PowerShell: Codex should quote paths containing parentheses like Next.js app/(main)

Additional confirmation and workaround:

I confirmed that this is caused by PowerShell parsing the unquoted (main) segment instead of treating it as a literal path.

Test 1: check what main resolves to on Windows PowerShell

```powershell
Get-Command main

Result:

Application main.cpl C:\WINDOWS\system32\main.cpl

So if PowerShell evaluates main as a command, it can open the Mouse Properties control panel.

Test 2: compare PowerShell token parsing

Unquoted:

rg test iPlantMES/apps/web/app/(main)/admin -S

PowerShell tokenizes it like this:

Generic :: iPlantMES/apps/web/app/
LParen :: (
Identifier :: main
RParen :: )
Generic :: /admin

Quoted:

rg test 'iPlantMES/apps/web/app/(main)/admin' -S

PowerShell tokenizes it correctly as a single path argument:

StringLiteral :: 'iPlantMES/apps/web/app/(main)/admin'

I also tested the unquoted command directly. In my case, rg split the path and failed with:

rg: /admin: 지정된 파일을 찾을 수 없습니다. (os error 2)

Using PowerShell cmdlets showed the same underlying issue:

Get-Item iPlantMES\apps\web\app\(main)\admin

Result:

Get-Item : A positional parameter cannot be found that accepts argument '$null'.

Workaround:

Always quote paths that include PowerShell metacharacters such as parentheses:

rg test 'iPlantMES/apps/web/app/(main)/admin' -S
Get-Item 'iPlantMES\apps\web\app\(main)\admin'

Suggested fix:

When Codex generates shell commands for Windows PowerShell, it should quote or otherwise safely escape path arguments containing characters such as ( and ).

Confirming on a second project — same trigger pattern, same dialog.

Environment

• codex-cli 0.130.0 (one minor newer than the OP; bug persists)
• Windows 11 Pro 26200
• PowerShell 7
• Next.js 16 project using route-group folders ((main)/, (auth)/)

The Mouse Properties dialog opens intermittently while Codex works in this project. I haven't captured a single-command transcript, but the timing matches what's described here and in #9370: it surfaces during sessions where the agent touches files under src/app/(main)/.... (auth) doesn't trigger anything (no auth.cpl to resolve to), consistent with the PATHEXT analysis.

Worth cross-linking #9370. That's the older canonical thread, with six independent reporters across Codex CLI, the VS Code extension (0.4.71/74/76), and Google Antigravity, but the discussion got pulled toward a REPORT_ALTERNATE_KEYS / Kitty Keyboard Protocol theory before settling on the same (main) cause @jhseo-tec writes up cleanly here. PR #9371 was closed because the original reporter couldn't supply a minimal repro for the kitty theory; this issue has it.

Per-session workaround for anyone hitting this in the meantime — strip .CPL from PATHEXT in the shell that invokes Codex:

$env:PATHEXT = ($env:PATHEXT.Split(';') | Where-Object { $_ -ne '.CPL' }) -join ';'

This doesn't fix the underlying parsing ((main) still gets evaluated as a sub-expression), but main no longer resolves to anything launchable, so you get the $null parameter error without the Control Panel popup. The Codex command still fails on that file, but no dialog.

Confirming this still reproduces on Codex Desktop for Windows.

Environment:

• Codex Desktop package observed locally: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• codex-cli 0.125.0
• Windows: Microsoft Windows NT 10.0.26200.0
• PowerShell: 5.1.26100.8457
• Node: v24.14.1
• Project type: Next.js App Router with route group paths such as src/app/(main)/...

Observed again on 2026-05-31 02:43:06 +08:00. Process snapshot:

ProcessId       : 39232
ParentProcessId : 44576
CreationDate    : 2026/5/31 2:43:06
Name            : rundll32.exe
CommandLine     : "C:\WINDOWS\system32\rundll32.exe" Shell32.dll,Control_RunDLL "C:\Windows\system32\main.cpl"

The parent process had already exited by the time I checked, which fits a short-lived shell command launching main.cpl.

Local diagnosis matches this issue:

• In PowerShell, an unquoted path segment like src/app/(main)/... is parsed as an expression.
• main resolves on Windows to C:\Windows\system32\main.cpl.
• That opens the Mouse Properties dialog.
• Quoting the path, e.g. "src/app/(main)/...", avoids the dialog and passes the path correctly.

This also looks like the concrete root cause behind the broader Mouse Properties report in #9370.

Suggested mitigation:

• When generating Windows PowerShell commands, Codex should quote or escape path arguments containing PowerShell metacharacters such as ( and ).
• For PowerShell cmdlets, prefer -LiteralPath.
• Ideally, the tool runner / command generator should reject or rewrite commands containing unquoted path segments matching route-group-style folders such as (main) or (auth).

Additional evidence from a later occurrence: this time the Codex Desktop UI itself showed the commands that were run immediately before the Mouse Properties dialog appeared.

The visible commands included unquoted pathspecs with Next.js route-group folders, for example:

git diff -- src/components/features/AnimeSubscriptionButton.tsx src/app/(main)/anime/[id]/page.tsx ...
git diff -- src/app/(main)/admin/downloads/Client.tsx src/components/features/EpisodeSourceDialog.tsx ...
git diff -- src/components/features/SeasonalBrowseWeekday.tsx src/app/(main)/page.tsx ...

The Mouse Properties dialog appeared while those commands were being run.

So this is not just a suspected background process chain: Codex generated/executed PowerShell commands containing unquoted src/app/(main)/... path arguments. Quoting those pathspecs individually avoids the issue, e.g.:

git diff -- "src/app/(main)/anime/[id]/page.tsx"
git diff -- "src/app/(main)/admin/downloads/Client.tsx"
git diff -- "src/app/(main)/page.tsx"

This also suggests git diff -- <pathspecs...> needs the same Windows PowerShell quoting treatment as rg and Get-Content commands.