[Bug]: Managed Codex provider check still fails on Windows 0.1.4 when new .codex-provisioning guard files appear #27119

Summary

Recurrence of #14325 on T3 Code 0.1.4, Windows 11 (10.0.26200), managed Codex CLI 0.156.1. ChatGPT sign-in remains recognized, but the provider becomes Needs attention with Could not check Codex right now. Retry, or reconnect in provider settings.

Reproduction and observed recurrence

1. Run T3 normally on Windows without Developer Mode or symlink creation privilege.
2. Connect an additional ChatGPT account using a managed Codex provider.
3. materializeCodexShadowHome fails to create links with EPERM.
4. Precreating existing required links from an elevated process temporarily restores Authenticated status and 8 available models (verified in UI and provider catalog).
5. A new .codex-provisioning-<hash>.guard appears in the shared Codex home. On the next check, the provider fails again because it needs another new link.

Sanitized evidence

CodexShadowHomeFileSystemError: Codex shadow home filesystem operation 'symlink' failed for '<T3_DATA>/providers/codex/<instance>/shadow/.codex-provisioning-<hash>.guard' to '<CODEX_HOME>/.codex-provisioning-<hash>.guard'.
  at CodexHomeLayout.ensureSymlink
  at materializeCodexShadowHome
  at refreshSnapshot
[cause]: Error: EPERM: operation not permitted, symlink '<CODEX_HOME>/.codex-provisioning-<hash>.guard' -> '<T3_DATA>/providers/codex/<instance>/shadow/.codex-provisioning-<hash>.guard'

The installed server bundle confirms that materializeCodexShadowHome enumerates all shared-home entries, excludes a small fixed private/local set, and calls ensureSymlink for every remaining entry. The exception is then reduced to the generic provider-check warning despite authenticated managed credentials.

Expected

Additional managed accounts should work on default Windows permissions, or setup should detect and clearly explain the missing filesystem capability. New transient provisioning/lock/temp files should not disable an otherwise authenticated provider.

Suggested investigation

Use a deliberate shared-entry policy rather than mirroring every current/future root entry; exclude transient guard/temp files; use appropriate Windows link strategies where safe; keep SQLite DB/WAL/SHM families coherent (see #24486); surface the actual filesystem error instead of advising an account reconnect.

No account identifiers, tokens, screenshots, or full private logs are included. Investigated and filed by Codex at the user's request.