[Windows/MSIX] Store updates re-trigger Defender Firewall prompt and accumulate stale rules for versioned ChatGPT.exe paths

[VirgilMing]

Summary

On the Microsoft Store / MSIX Windows build, recent Codex/ChatGPT updates repeatedly trigger the standard Windows Defender Firewall prompt asking whether to allow the app on private and/or public networks.

The prompt reappears after app updates even if the previous version was already allowed. The likely mechanism is that the firewall rule is tied to the full executable path under the versioned MSIX install directory, for example:

C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\ChatGPT.exe

Each Store update installs a new versioned path, so the previous rule no longer matches the new ChatGPT.exe. Windows therefore asks again, while the old path-specific rule remains behind.

This is a user-visible recurring security prompt and causes stale firewall-rule accumulation across app versions.

Environment

• Windows 10 22H2, build 19045.7663, x64
• Microsoft Store / MSIX package: OpenAI.Codex
• The behavior has reproduced across multiple recent Store updates

Steps to reproduce

1. Install or update the Microsoft Store OpenAI.Codex package.
2. Launch the desktop app.
3. Windows Defender Firewall shows the standard network-access prompt asking whether to allow the app on private/public networks.
4. Allow or dismiss the prompt and continue using the app.
5. Install the next Store update, which moves the executable into a new versioned WindowsApps\OpenAI.Codex_<version>... directory.
6. Launch the app again.
7. The firewall prompt appears again even though the previous version was already handled.
8. Inspecting firewall application rules across affected systems shows rules tied to old versioned ChatGPT.exe paths can remain after the corresponding MSIX version is gone.

Expected behavior

Updating the Store/MSIX package should not require the user to make the same private/public network exposure decision again for every app version.

The app should use a stable Windows firewall identity/rule strategy appropriate for an MSIX package, or otherwise reconcile/remove stale version-specific rules during update/setup.

If the listener only needs loopback access, the desktop app should also avoid causing a broad private/public inbound-network prompt in the first place.

Actual behavior

Every affected Store update can appear to Windows Firewall as a new executable because the full path changes with the MSIX version. This re-triggers the network-access prompt and leaves stale rules associated with superseded package paths.

Previous reports / duplicate-tracking problem

This exact sub-issue was already documented inside #35737 under the section “Firewall rules accumulate one set per installed version.” That reporter found 30 Codex/ChatGPT firewall rules across 12 distinct versioned install paths and explicitly observed that every update triggered a fresh Windows Defender Firewall prompt.

However, #35737 was later closed as a likely duplicate of #35352. #35352 tracks an unrelated embedded-browser GPU / SwiftShader Code Integrity crash and does not cover the firewall-rule accumulation or per-update network-access prompt.

So this issue is intentionally narrow: it tracks only the MSIX/versioned-path firewall prompt and stale-rule accumulation behavior that appears to have fallen out of tracking when the larger compound report was closed.

#34616 independently notes that a Desktop update triggered a new Windows network-access prompt and changed inbound firewall state, although that issue is primarily about UI-thread blocking and is not a duplicate of this one.

Suggested fix direction

• Prefer a stable package/app identity rather than a versioned executable path where supported.
• Reconcile or remove stale Codex/ChatGPT firewall rules that reference superseded MSIX package directories.
• If the relevant listener is loopback-only, avoid requesting broad LAN/public inbound access.
• Add an MSIX update regression test that upgrades between two package versions and verifies that no duplicate user firewall prompt or stale path-specific rule is created.