fix(plugin): resolve relocated Windows Deep Scan executables

[ianw-oai]

Summary

Keep Deep Scan workers usable when the configured Codex executable points into WindowsApps.

Changes

• Keep the original runtime behavior for executable selection, parent deny rules, and permission preflight.
• Skip configured WindowsApps paths and select the newest nonempty relocated executable when available.
• Keep explicit overrides outside WindowsApps and treat EPERM launch failures as non-retryable.
• Preserve the stdin transport changes already on main and the parent-denial changes from fix(plugin): preserve parent deny rules in Deep Scan workers #597.
• Remove the later WindowsApps override check, stderr capture, and tests added for those changes.

Testing

• Focused executable, parent-denial, worker-shutdown, and workbench tests: 41 passed, 0 failed.
• Full SDK suite: 1,552 passed, 29 skipped, 0 failed in each run (seeds 12345 and 2842775074).
• Types, formatting, build, and git diff --check: passed.
• Installed-package check on Node 24: passed, including public imports, CLI startup, all 111 plugin files, and nested-worker startup.
• The restored branch merges cleanly with main.
• GitHub CI is still running on the new commit.

Risk and rollout

The npm and plugin manifest versions are unchanged. This PR keeps the original port behavior instead of adding new error handling. Native Windows tests run in GitHub CI; local tests use synthetic files and settings.

Public disclosure review

• No customer, partner, prospect, or user identities, data, or identifying details are included.
• No credentials, personal data, private source, scan findings, or nonpublic links or tickets are included.
• I reviewed the branch name, title, description, commits, changes, comments, logs, screenshots, attachments, and links for public disclosure.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-08-21T22:09:20.113610Z	b5694c1	Manual request
🔒 Security Review	✅ Completed 2026-08-21T06:57:46.073898Z	be9471a	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[mldangelo-oai]

At current head d7959f3, the resolver treats every configured path containing WindowsApps as unusable before attempting to launch it. The test labeled "when WindowsApps is inaccessible" only passes a matching string; it never makes the path inaccessible. A valid explicit CODEX_CLI_PATH under that directory can therefore be ignored and replaced with a different cached executable. Please fall back only after a diagnosed access or launch failure, or distinguish an inherited WindowsApps path from a user override.

The description also no longer matches this head. #597's deny-rule changes are now included even though Risk calls them a separate PR, the branch is conflicting despite Testing saying otherwise, and GitHub reports no checks for d7959f3. The visible Codex security review is still attached to be9471a.

[ianw-oai]

@mldangelo-oai Addressed in 75dedd96.

The resolver now keeps an accessible explicit WindowsApps executable. It selects a relocated executable only if the configured path fails the file or access check. The shipped-runtime test covers an accessible override as well as an unavailable path. The four executable and parent-denial tests pass.

The description now includes the deny-rule changes from #597 and the current transport. The merge conflict is resolved, and checks now run on this head.

[mldangelo-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 75dedd96e1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[mldangelo-oai]

Re-reviewed 75dedd96. The original explicit-override problem is fixed: an accessible configured WindowsApps path is kept, an unavailable one falls back to the newest nonempty relocated binary, and the shipped-runtime tests pass.

One exact-head finding remains valid. The included preflight guidance says an early app-server exit reports the tool's diagnostic, but AppServerPreflightClient discards stderr and codexExecutableExitError keeps only the exit code or signal. That leaves configuration failures with generic PATH/version advice. I do not consider the EPERM fallback suggestion a blocker: this head deliberately trusts an accessible explicit override and treats launch-policy failures as non-retryable. Commenting rather than approving because the diagnostic contract and runtime still disagree.

[mldangelo-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b5694c1db0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[mldangelo-oai]

Re-reviewed exact head b5694c1. The stderr capture and close-event ordering fix the direct early-exit path, and the focused tests, types, and installed-package check all passed locally.

The exact-head classification-path finding is valid. After permissionProfile/list returns allowed false, readConfigRequirementsForClassification catches every non-abort rejection. I reproduced an app-server close with stderr during configRequirements/read and the method resolved undefined; verification then replaces the executable path and diagnostic with the generic managed-policy error. That path still disagrees with the documented diagnostic contract. The explicit-override and EPERM behavior remains deliberate and is not a blocker. Commenting rather than requesting changes.