[Windows] Codex sandbox Schannel fails with SEC_E_NO_CREDENTIALS; elevated sandbox launches without loaded user profile

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

Codex Desktop: 26.915.4065.0 Bundled Codex CLI / Doctor: Codex Doctor v0.155.0-alpha.9.2 windows-x86_64

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 x64 Microsoft Windows NT 10.0.26200

What issue are you seeing?

SUMMARY

Codex Desktop on Windows cannot establish HTTPS using Windows Schannel from its sandbox execution environment.

The failure is:

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

The same curl.exe / Schannel request succeeds from normal Windows PowerShell under the same Windows installation and signed-in user.

I reproduced the problem under both Codex Windows sandbox backends:

1. unelevated
2. elevated

I also tested Full Access and Workspace Write sandbox policies.

The failure persists when Codex's injected proxy environment variables are explicitly bypassed.

CONTROL TEST OUTSIDE CODEX

From normal Windows PowerShell:

whoami
rogerhouse2024\davea

curl.exe -I https://www.microsoft.com

Result:
HTTP/1.1 200 OK

Python HTTPS also succeeds:

python -c "import urllib.request; print(urllib.request.urlopen('https://www.microsoft.com').status)"

Result:
200

Therefore Windows networking and Schannel function normally outside the Codex sandbox.

CODEX UNELEVATED SANDBOX

config.toml:

[windows]
sandbox = "unelevated"

Inside Codex:

whoami

Result:
rogerhouse2024\davea

Codex injects:

ALL_PROXY=http://127.0.0.1:9
GIT_HTTP_PROXY=http://127.0.0.1:9
GIT_HTTPS_PROXY=http://127.0.0.1:9
HTTP_PROXY=http://127.0.0.1:9
HTTPS_PROXY=http://127.0.0.1:9
NO_PROXY=localhost,127.0.0.1,::1

The proxy itself is not the cause of the Schannel failure.

Running:

curl.exe --noproxy "*" -I https://www.microsoft.com

produces:

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

Clearing HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, GIT_HTTP_PROXY and GIT_HTTPS_PROXY produces the same SEC_E_NO_CREDENTIALS result.

The failure occurs under both:

Sandbox settings -> Full access
Sandbox settings -> Workspace write

TOKEN COMPARISON

Normal PowerShell whoami /all contains these privileges:

SeShutdownPrivilege Disabled
SeChangeNotifyPrivilege Enabled
SeUndockPrivilege Disabled
SeIncreaseWorkingSetPrivilege Disabled
SeTimeZonePrivilege Disabled

Inside Codex unelevated, whoami /all contains only:

SeChangeNotifyPrivilege Enabled

The username, user SID, Medium integrity level, Administrators deny-only state, Microsoft Account identity, Cloud Account Authentication membership, and major group memberships otherwise match.

This demonstrates that Codex is executing the process under a filtered/restricted version of the host user's Windows token.

ELEVATED SANDBOX TEST

I changed only:

[windows]
sandbox = "elevated"

After restarting Codex, the task ran as a dedicated sandbox identity.

Observed identities included:

rogerhouse2024\codexsandboxonline

and after reprovisioning:

rogerhouse2024\codexsandboxoffline

CODEXSANDBOXONLINE PROFILE STATE

CodexSandboxOnline exists and is enabled.

Get-LocalUser showed a valid LastLogon and SID, but:

Test-Path "C:\Users\CodexSandboxOnline"

Result:
False

There was also no ProfileList registry entry at:

HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList<CodexSandboxOnline SID>

Inside the CodexSandboxOnline task:

vaultcmd /list

reported:

Vault: Windows Credentials
Location:

Schannel continued to fail with:

SEC_E_NO_CREDENTIALS (0x8009030e)

SUPPORTED ELEVATED SANDBOX REPROVISIONING

I closed Codex Desktop and ran the supported setup command from an Administrator PowerShell:

codex sandbox setup --elevated --current-user

Result:

Windows elevated sandbox setup completed for davea at C:\Users\davea.codex.

Codex Doctor subsequently reported:

sandbox backend elevated
sandbox provisioning complete

However, this did not resolve the problem.

CODEXSANDBOXOFFLINE PROFILE STATE

After official elevated sandbox setup, CodexSandboxOffline had:

ProfileImagePath:
C:\Users\CodexSandboxOffline

The profile directory existed.

However:

Get-CimInstance Win32_UserProfile |
Where-Object { $_.LocalPath -like "CodexSandbox" } |
Select-Object LocalPath, SID, Loaded, Status

reported:

LocalPath: C:\Users\CodexSandboxOffline
Loaded: False
Status: 0

Inside the actual Codex task:

whoami

returned:

rogerhouse2024\codexsandboxoffline

but:

USERPROFILE=C:\Users\davea
LOCALAPPDATA=C:\Users\davea\AppData\Local

vaultcmd /list reported:

Vault: Windows Credentials
Location:

The following HKCU locations were unavailable:

HKCU\Volatile Environment

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Windows returned:

ERROR: The system was unable to find the specified registry key or value.

Schannel again failed:

curl: (35) schannel: AcquireCredentialsHandle failed:
SEC_E_NO_CREDENTIALS (0x8009030e)

USER PROFILE SERVICE OBSERVATION

During the CodexSandboxOnline logon window, the Microsoft-Windows-User Profile Service/Operational log contained no profile-load events.

This appears consistent with the sandbox account being authenticated/logged on without Windows User Profile Service actually loading its profile.

CODEX DOCTOR

Codex Doctor v0.155.0-alpha.9.2 reports:

sandbox backend elevated
sandbox provisioning complete

It also successfully performs its own host-context connectivity tests.

However, commands executed inside the actual sandbox identity continue to fail Schannel as described above.

OPENSSL CONTROL TEST

Git for Windows is configured for OpenSSL:

git version 2.54.0.windows.1

http.sslBackend:
openssl

Git's CA bundle exists:

C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt

After clearing Codex's proxy environment variables, Git/OpenSSL reaches TLS certificate verification but returns:

SSL certificate OpenSSL verify result:
unable to get local issuer certificate (20)

This is a different failure from the Schannel SEC_E_NO_CREDENTIALS error and confirms that the proxy error and Schannel credential-acquisition error are separate layers.

SUSPECTED FAILURE BOUNDARY

The evidence appears to isolate the problem to the Windows security/profile context used when Codex launches sandboxed processes.

Unelevated:

• real Windows username
• filtered/restricted token
• Schannel AcquireCredentialsHandle fails

Elevated:

• dedicated CodexSandboxOnline/Offline identity
• Windows profile is not loaded into the sandbox process
• vaultcmd reports
• HKCU profile-backed state is unavailable
• USERPROFILE/LOCALAPPDATA still point to the host user's profile
• Schannel AcquireCredentialsHandle fails

The same Windows installation, same curl.exe, same network connection and same Schannel stack work normally outside Codex.

The supported elevated sandbox reprovisioning command reports success but does not resolve the missing loaded-profile / Schannel condition.

This appears to be a Codex Windows sandbox process-launch/profile-loading issue rather than a system-wide Windows Schannel failure.

What steps can reproduce the bug?

1. On Windows 11, configure Codex:

[windows]
sandbox = "unelevated"

2. Start a fresh Codex Desktop task.

3. Run:

whoami
curl.exe --noproxy "*" -I https://www.microsoft.com

4. Observe:

whoami returns the normal Windows user.

curl fails with:

schannel: AcquireCredentialsHandle failed:
SEC_E_NO_CREDENTIALS (0x8009030e)

5. Run the same curl command from normal Windows PowerShell.

6. Observe HTTP/1.1 200 OK.

7. Change:

[windows]
sandbox = "elevated"

8. Completely restart Codex and create a fresh task.

9. Run:

whoami
vaultcmd /list
curl.exe --noproxy "*" -I https://www.microsoft.com

10. Observe a CodexSandboxOnline/Offline identity, vaultcmd reporting Location: , and the same SEC_E_NO_CREDENTIALS failure.

11. From Administrator PowerShell run:

codex sandbox setup --elevated --current-user

12. Observe successful sandbox provisioning.

13. Restart Codex and repeat the elevated test.

14. The sandbox process still has no loaded profile-backed credential context and Schannel continues to return SEC_E_NO_CREDENTIALS.

What is the expected behavior?

When Codex permits network access, Windows Schannel-backed applications executed inside the Codex sandbox should be able to acquire a valid TLS client credential context and establish ordinary HTTPS connections.

In elevated sandbox mode, CodexSandboxOnline/Offline should either have their Windows user profiles correctly loaded before sandbox commands execute, or Codex should provide another supported execution context that allows Schannel/SSPI to function normally.

The supported sandbox setup command should not report provisioning complete if required profile-backed state for the sandbox execution context is unavailable.

Additional information

Related existing issues:

#17459
Windows sandbox HTTPS via Schannel fails with SEC_E_NO_CREDENTIALS

#42621
Elevated sandbox has no profile-backed credential context, causing SEC_E_NO_CREDENTIALS

This report adds several observations:

1. The problem reproduces on Codex Desktop 26.915.4065.0 / CLI 0.155.0-alpha.9.2.

2. Both unelevated and elevated Windows sandbox backends were tested.

3. Full Access and Workspace Write both reproduce the failure.

4. Explicitly bypassing Codex's 127.0.0.1:9 proxy does not resolve Schannel.

5. CodexSandboxOffline has a registered profile on disk, but Win32_UserProfile reports Loaded=False while the Codex process is executing as that account.

6. HKCU profile-backed keys are unavailable from the running sandbox process.

7. vaultcmd reports Location: .

8. USERPROFILE and LOCALAPPDATA still point to the host user's profile while whoami reports CodexSandboxOffline.

9. Running the supported:

codex sandbox setup --elevated --current-user

reports successful provisioning but does not resolve the condition.

No passwords, authentication tokens, private repository credentials, API keys, or other secrets are included in this report.

Start by reproducing the unelevated and elevated cases with whoami, vaultcmd /list, and curl.exe --noproxy "*" -I https://www.microsoft.com, then inspect the sandbox path exercised by codex sandbox setup --elevated --current-user. Done means sandboxed Schannel HTTPS succeeds with a valid profile-backed credential context, and provisioning does not report success when that context is unavailable.