Codex Security Deep Scan fails twice on Windows: spawn EPERM, then missing threat_model.md after workaround #36588

Summary

Codex Security Deep Scan on Windows encounters two sequential terminal failures:

1. With CODEX_CLI_PATH unset, discovery workers fail with spawn EPERM. This matches Codex Security 0.1.14 Deep Scan fails with spawn EPERM on Windows when CODEX_CLI_PATH is unset #35872.
2. After applying the documented workaround—pointing CODEX_CLI_PATH at the directly spawnable native npm codex.exe and restarting Codex Desktop—a fresh scan gets past worker launch but fails later because the required threat_model.md artifact is missing.

Both scans terminated during discovery with zero accepted findings and no validation or final report. The second failure happened after multiple worker attempts, so the scan performed substantial work but returned no usable partial result.

Environment

• Windows 11 Home, x64, version 10.0.26200
• Codex Desktop
• Codex Security plugin 0.1.15
• Native npm Codex CLI binary, currently codex-cli 0.146.0
• Private local Git repository scanned at a fixed immutable revision
• Deep Scan workflow: deep-scan-mcp/v1, deterministic mode

Failure 1: bare codex cannot be spawned

Steps

1. Leave CODEX_CLI_PATH unset.
2. Start a fresh Codex Security Deep Scan.
3. Complete setup and allow preflight to pass.
4. Wait for discovery workers to launch.

Actual result

The selected worker exhausted four attempts with synchronous spawn EPERM. The remaining workers were canceled.

Sanitized result:

{
  "status": "failed",
  "discoveryCount": 0,
  "failure": {
    "phase": "discovery",
    "message": "spawn EPERM",
    "kind": "Error:EPERM"
  }
}

Directly spawning the native npm codex.exe succeeds. The plugin runtime falls back to the bare command when the override is absent:

function resolveCodexPath(env = process.env) {
  return env.CODEX_CLI_PATH?.trim() || "codex";
}

This first failure is already represented by #35872.

Workaround applied

1. Set the user-level CODEX_CLI_PATH to the direct native npm codex.exe, not the codex.cmd shim.
2. Verify that the file exists and --version exits successfully.
3. Restart Codex Desktop so the plugin MCP process inherits the variable.
4. Start a completely new Deep Scan against the same immutable revision.

The previous spawn EPERM no longer occurred, confirming that the workaround fixed the first launcher failure.

Failure 2: required worker artifact is missing

The new scan completed deterministic setup and successfully launched discovery workers. Its effective configuration was:

{
  "workers": 6,
  "subagents": 3,
  "stopAfterNoNew": 6,
  "maxDiscoveryRuns": 60
}

One discovery worker reached attempt 4 and then failed with:

Codex worker file change failed. Deterministic artifact validation also reported:
ENOENT: no such file or directory, realpath
'<scan-root>\artifacts\deep_discovery\workers\discovery-0004\output\threat_model.md'

The other five workers were canceled. Sanitized terminal manifest:

{
  "workflowVersion": "deep-scan-mcp/v1",
  "status": "failed",
  "dispatchedCount": 6,
  "discoveryCount": 0,
  "acceptedWorkerIds": [],
  "mergedWorkerIds": [],
  "workerThreatModelPaths": [],
  "canonical": null,
  "executions": [
    {
      "label": "discovery-0004",
      "kind": "discovery",
      "status": "failed",
      "attempt": 4,
      "error": "Codex worker file change failed. Deterministic artifact validation also reported: ENOENT: no such file or directory, realpath '<scan-root>\\artifacts\\deep_discovery\\workers\\discovery-0004\\output\\threat_model.md'"
    }
  ],
  "failure": {
    "phase": "discovery",
    "kind": "Error:file_change_failed"
  }
}

No successful discovery manifest was produced, so centralized validation, attack-path analysis, canonical result sealing, and report.md generation never ran.

Expected behavior

• On Windows, Deep Scan should resolve a directly executable Codex binary without requiring a manual environment override.
• Once workers launch, the artifact-writing contract should reliably produce every required file.
• If one worker fails to produce threat_model.md, successful worker output should be preserved or the scan should return a useful partial result instead of canceling every worker.
• Retries should surface actionable diagnostics and avoid repeating expensive attempts that end in the same deterministic artifact-validation failure.
• A failed scan should make clear what usage was consumed and whether any completed work can be resumed.

Impact

Deep Scan is currently unusable in this environment even after applying the workaround for #35872. The second failure occurs only after workers have launched and retried, but the all-or-nothing terminal result contains no findings or report. This creates user-visible compute/quota consumption without a usable deliverable.

I searched the issue tracker for both "Codex worker file change failed" and "threat_model.md" ENOENT and did not find an existing report for the second failure.