[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

[Py-CI-Park]

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.

[github-actions]

Issue closed: use an issue template

Thanks for taking the time to submit this issue. It was closed automatically because it was not opened with a recognized issue template (Bug report, Feature request, Documentation, or Provider compatibility). Freeform and API-opened issues cannot skip this check.

• This issue does not use a recognized issue template.

Please edit the issue to add:

• Open a new issue with the Bug report, Feature request, Documentation, or Provider compatibility template.
• Or edit this issue so the body uses the template section headings for the kind of report you are filing.

See the Contributing guide for details.

Once the report passes the automated checks, it will be reopened automatically unless a maintainer has changed its state.