[Bug][Windows] Native-main owner permanently unavailable via a separate, hardcoded 8s PowerShell WindowsIdentity SID lookup — distinct from the icacls timeout fixed in #1156/#1197 #2331

Title

[Bug][Windows] Native-main owner permanently unavailable via a separate, hardcoded 8s PowerShell WindowsIdentity SID lookup — distinct from the icacls timeout fixed in #1156/#1197

Summary

On a clean Windows install, ocx setup / ocx sync consistently fails to inject opencodex into Codex's config.toml with:

⚠️  Codex configuration was not written: the coordinator path could not be resolved: CodexUserIdentityRefusal: Windows effective-account lookup timed out.

Once the proxy is pointed at from config.toml anyway (manual injection, or a run where injection partially succeeded), every native OpenAI request fails with the same symptom described in #1156:

{"error":{"message":"OpenCodex local native-main profile maintenance is active; retry this request","type":"server_error","param":null,"code":"server_is_overloaded"}}

(HTTP 503, errorCode: "server_is_overloaded", as seen via ocx logs --json.)

Codex CLI/App surfaces this to the end user as "Selected model is at capacity. Please try a different model.", which is misleading — the account is not actually rate-limited (confirmed working immediately via ChatGPT web and via native codex with opencodex fully removed).

This looks like #1156 but is a different code path

#1156 / PR #1197 fixed a 5s → 30s timeout for the icacls-based ACL-hardening sequence in src/lib/windows-secret-acl.ts, configurable via OPENCODEX_ACL_TIMEOUT_MS (up to a 60s cap).

The failure here traces to a different, separate file: src/codex/user-identity.ts. It spawns powershell.exe -Command "[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value" synchronously (Bun.spawnSync) with a hardcoded 8-second timeout:

const WINDOWS_POWERSHELL_LOOKUP_TIMEOUT_MS = 8_000;
const WINDOWS_POWERSHELL_LOOKUP_TIMEOUT_CI_MS = 30_000;

function windowsIdentityLookupTimeoutMs(): number {
  return process.env.CI === "true"
    ? WINDOWS_POWERSHELL_LOOKUP_TIMEOUT_CI_MS
    : WINDOWS_POWERSHELL_LOOKUP_TIMEOUT_MS;
}

This timeout is not configurable by OPENCODEX_ACL_TIMEOUT_MS or any documented env var — the only way to widen it is the undocumented CI=true (8s → 30s). Once this lookup fails once, the native-main owner appears to get fenced closed the same way #1156 describes (isNativeMainTrafficBlocked() → activeServiceOwnershipBlockReason() / snapshot.status === "blocked"), and — unlike what I'd expect from a transient timeout — the block persists across:

• ocx stop / ocx start (fresh process each time)
• ocx restart
• ocx service uninstall + ocx service (fresh Task Scheduler registration)
• a full clean reinstall: npm uninstall -g @bitkyc08/opencodex, deleting ~/.opencodex and all ~/.codex/opencodex-*/.opencodex-native-main-* files, then npm install -g @bitkyc08/opencodex@latest (2.29.0) and ocx setup again from scratch

Every one of the above reproduced the identical CodexUserIdentityRefusal failure on the first ocx sync/ocx setup "inject" attempt, deterministically.

What did not fix it

• setx OPENCODEX_ACL_TIMEOUT_MS 60000 + ocx restart — no change (wrong subsystem; this only affects windows-secret-acl.ts, not user-identity.ts)
• CI=true (extends the 8s → 30s window for this specific check) + ocx restart — no change
• Disabling/enabling a Tailscale VPN connection — no change (ruled out network interference)
• Closing the Codex Desktop app / all codex.exe processes before starting the proxy — no change (ruled out a concurrent-session conflict)
• A second, fully clean reinstall (see above) — reproduced identically

What did fix it

ocx provider account-mode direct
ocx restart

This routes native OpenAI requests through Codex Direct (caller bearer token passthrough) instead of the native-main-profile-manager/pool layer, sidestepping both the icacls envelope and the identity-lookup check entirely. codex exec -m gpt-5.6-sol "..." then completes normally through the proxy.

Standalone reproduction of the identity lookup itself

Running the exact same command manually, outside opencodex, completes quickly:

> Measure-Command { powershell -NoProfile -Command "[System.Security.Principal.WindowsIdentity]::GetCurrent().User.Value" }
# real 0.49s

So powershell.exe itself is not generically slow on this machine — the 8s budget is being exceeded specifically when spawned from inside the bun/opencodex process context. This smells like the same class of cause named in #1156 (Defender real-time scanning a freshly-spawned child process from a recently-installed/updated binary), just hitting a second, separate timeout that wasn't covered by that fix.

Environment

• OS: Windows 11 Pro, build 10.0.26200
• opencodex: 2.29.0 (reproduced identically on 2.26.0 before upgrading)
• Bun (bundled): 1.3.14
• Codex CLI: 0.148.0
• Provider: OpenAI — ChatGPT login (native-main / account pool default, not API key)

Suggested fix

• Make WINDOWS_POWERSHELL_LOOKUP_TIMEOUT_MS in src/codex/user-identity.ts configurable via an env var, same pattern as OPENCODEX_ACL_TIMEOUT_MS (or fold it into that same override).
• Consider whether a single failed identity lookup should be allowed to permanently fence the native-main owner across process restarts and reinstalls the way it currently appears to — a transient failure ideally shouldn't require account-mode direct as the only escape hatch.