Windows] Elevated sandbox has no profile-backed credential context, causing SEC_E_NO_CREDENTIALS for private Git

What version of the Codex App are you using (From “About Codex” dialog)?

26.831.21537 (production)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop tasks on Windows are running under \CodexSandboxOffline while the environment points to my normal Windows profile at C:\Users<WINDOWS_USER>.

In elevated sandbox mode, Windows Credential Manager reports:

Location:

Git Credential Manager cannot use the wincredman credential store, and native Git fails before private repository authentication with:

schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
No credentials are available in the security package

This prevents Codex from authenticating with the private ChatGPT Sites repository and therefore blocks Sites source deployments.

The problem persists after a complete Windows shutdown/restart and in a fresh Codex task.

The same Codex-bundled Git executable works normally when run from standard Windows PowerShell under my real Windows user context. In that context, Windows Credential Manager has a valid profile-backed vault and Schannel reaches normal Git credential acquisition without SEC_E_NO_CREDENTIALS.

This strongly isolates the failure to the Codex elevated sandbox security context rather than the Git/Schannel installation itself.

What steps can reproduce the bug?

1. Open Codex Desktop on Windows with Windows sandbox mode set to elevated.

2. Open a task against an existing private ChatGPT Sites repository.

3. Run:

vaultcmd /list

Windows Credentials reports:

Location:

4. Run:

git credential-manager diagnose --no-ui

Git Credential Manager 2.7.3 initializes but reports credential-storage/networking failures, including inability to persist credentials using wincredman.

5. Run the authenticated read-only test:

git -c credential.interactive=false ls-remote origin

It fails before repository authentication with:

schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
No credentials are available in the security package

No repository refs are returned.

6. Close/restart Windows and Codex Desktop and repeat in a fresh task. The failure persists.

7. For comparison, run the exact Codex-bundled Git executable from normal Windows PowerShell under the signed-in Windows user:

%USERPROFILE%.cache\codex-runtimes\codex-primary-runtime\dependencies\native\git\cmd\git.exe

Under this normal Windows user context, vaultcmd /list shows real profile-backed credential vaults.

Running the same read-only ls-remote no longer produces SEC_E_NO_CREDENTIALS. It reaches normal credential acquisition and, because interactivity is deliberately disabled, returns:

fatal: Cannot prompt because user interactivity has been disabled.
fatal: unable to get password from user

This isolates the failure to the Codex elevated sandbox security context rather than the Git/Schannel installation itself.

What is the expected behavior?

Codex Desktop's elevated Windows sandbox should provide a supported credential context that allows Git Credential Manager and Schannel to authenticate securely with private repositories used by ChatGPT Sites.

Windows Credential Manager should expose a usable profile-backed vault, GCM should be able to access its credential store, and authenticated Git operations should reach private repository authentication without failing locally with SEC_E_NO_CREDENTIALS.

If the elevated sandbox intentionally cannot access the host user's credential vault, the Sites deployment mechanism needs another supported secure authentication path for its short-lived repository credentials.

Additional information

Environment:

• Windows profile: C:\Users<WINDOWS_USER>
• Codex task identity: \CodexSandboxOffline
• Git Credential Manager: 2.7.3
• Codex-bundled Git: 2.53.0.windows.3
• codex-cli: 0.152.1
• credential.helper=manager
• http.sslBackend=schannel
• Windows sandbox mode: explicitly elevated

Additional diagnostics:

• Windows credential/security services are running.
• Neutral HTTPS/TLS connectivity succeeds.
• Windows certificate stores are readable.
• No conflicting Git credential helper or repository-specific TLS configuration was found.
• Repository and .git ownership were initially CodexSandboxOffline. Both were changed back to the normal Windows user, but this did not resolve the credential-context failure.
• A fresh Sites repository credential can be issued, but Git inside the elevated sandbox fails locally before that credential can be evaluated.
• The private Sites repository target and account/project linkage appear correct.
• No 429, retry interval, quota message, usage cap, rate-limit response, or deployment-limit error has been observed.
• The issue persists after a complete Windows shutdown/restart and fresh Codex task.

Host-user isolation test:

The exact Git executable bundled with Codex was run from normal Windows PowerShell under the signed-in Windows user.

Under that context:

• Windows Credential Manager exposes profile-backed vaults under %LOCALAPPDATA%\Microsoft\Vault
• Git 2.53.0.windows.3 runs normally
• credential.helper=manager
• http.sslBackend=schannel
• Schannel does not produce SEC_E_NO_CREDENTIALS

Running:

git -c credential.interactive=false ls-remote origin

instead reaches normal credential acquisition and stops only because interactive prompting is deliberately disabled:

fatal: Cannot prompt because user interactivity has been disabled.
fatal: unable to get password from user

This demonstrates that the same Git/Schannel stack works under the normal Windows security context and fails specifically under CodexSandboxOffline.

Codex diagnostics also indicate that there is currently no supported secure handoff of the Sites short-lived repository credential from the Codex task to a Git process running under the host-user context.

Suspected failure boundary:

Based on these diagnostics, the suspected failure boundary is Codex Desktop for Windows elevated-sandbox security-context provisioning.

Windows itself has a valid signed-in user profile, required security services are running, neutral TLS connectivity succeeds, Git configuration is correct, and Sites can issue a repository credential.

The failure occurs because the Codex task process runs as CodexSandboxOffline without a profile-backed Windows credential context. This prevents Windows Credential Manager/GCM and Schannel from operating normally.

This is a suspected failure boundary rather than a definitive root-cause assertion; confirmation from the Codex Desktop/Sites engineering side is requested.

Impact:

Local repository work and production builds succeed, but authenticated private Sites repository operations cannot run. This blocks authenticated repository reads through native Git, source uploads to the private Sites repository, and deployment of new Sites versions.

The existing live Site remains operational and the pending production-build-validated commit remains safely preserved locally.

Security:

No credentials, tokens, authenticated repository URLs, private repository secrets, computer name, Windows username, or other sensitive stored values are included in this report.

Start by reproducing the elevated Windows sandbox boundary with vaultcmd /list, git credential-manager diagnose --no-ui, and git -c credential.interactive=false ls-remote origin, then compare the same bundled Git executable under the normal Windows user context. Trace CodexSandboxOffline credential-context provisioning and the Sites credential handoff; done means private repository Git operations no longer fail locally with SEC_E_NO_CREDENTIALS through a supported secure path.