Windows sandbox HTTPS via Schannel fails with `SEC_E_NO_CREDENTIALS`

Summary

On Windows, HTTPS requests that use the Windows TLS stack (Schannel) fail inside the current sandboxed shell with:

• PowerShell / .NET: Authentication failed, see inner exception
• inner Win32 error: SEC_E_NO_CREDENTIALS (0x8009030e)
• curl.exe (Schannel build): schannel: AcquireCredentialsHandle failed

At the same time:

• Python HTTPS works in the same sandbox
• the same PowerShell HTTPS call works outside the sandbox
• sandbox users can do Schannel HTTPS successfully after their profiles are initialized

I started investigating sandbox-user profile initialization because the Schannel failure was SEC_E_NO_CREDENTIALS, which strongly suggested missing or inaccessible per-user Windows state. The fact that the sandbox users initially had no profile directories made that look like a credible lead.

Related issue: #17458 ("Windows sandbox users are created but their profiles are not initialized until manual first logon").

Version / platform

• Date observed: April 11, 2026
• Platform: Windows 11 / Windows 10.0.26200
• PowerShell: 7.5.5
• curl.exe: 8.18.0 with Schannel

Failing behavior

Inside the sandboxed shell:

Invoke-WebRequest -UseBasicParsing -Uri 'https://api.ipify.org'

fails with:

The SSL connection could not be established, see inner exception.
Authentication failed, see inner exception.
SEC_E_NO_CREDENTIALS (0x8009030e)

Raw .NET TLS fails too:

$tcp = [System.Net.Sockets.TcpClient]::new('api.ipify.org',443)
$ssl = [System.Net.Security.SslStream]::new($tcp.GetStream(), $false, ({$true}))
$ssl.AuthenticateAsClient('api.ipify.org')

and curl.exe fails with:

curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS

What works

• Python HTTPS in the same sandbox
• raw TCP connectivity to port 443
• PowerShell HTTPS outside the sandbox
• Schannel HTTPS when run manually as CodexSandboxOnline after profile creation
• Schannel HTTPS when run manually as CodexSandboxOffline after profile creation

Important observations

1. The failing current sandboxed shell is running as the real user

Inside the failing shell:

• whoami -> ELIOT-PC2\Eliot
• USERPROFILE -> C:\Users\Eliot

So the failing shell appears to be a restricted real-user context, not an actual dedicated sandbox-user process.

2. Dedicated sandbox users succeed after profile creation

After manually forcing first logon for:

• CodexSandboxOnline
• CodexSandboxOffline

both can do:

• PowerShell HTTPS
• raw .NET SslStream
• curl.exe HTTPS

successfully.

That manual profile initialization is tracked separately in #17458.

3. There is also an env inheritance bug

In those sandbox-user sessions, env is still inherited from the real user:

• USERNAME=Eliot
• USERPROFILE=C:\Users\Eliot
• APPDATA=C:\Users\Eliot\AppData\Roaming
• LOCALAPPDATA=C:\Users\Eliot\AppData\Local
• TEMP/TMP=C:\Users\Eliot\AppData\Local\Temp

That looks like a real bug in the elevated Windows sandbox path, but it is not sufficient by itself to explain the Schannel failure, because the sandbox users still succeed despite the wrong env.

Why this looks like a sandbox-specific Schannel issue

The failure is specific to the Windows TLS stack:

• PowerShell / .NET / Schannel curl.exe fail
• Python HTTPS succeeds

That points to a Schannel / SSPI / token / user-profile interaction, not general network failure.

Repro

Inside sandbox:

whoami
Invoke-WebRequest -UseBasicParsing -Uri 'https://api.ipify.org'
curl.exe https://api.ipify.org

Observed:

• whoami = real user
• Schannel HTTPS fails with SEC_E_NO_CREDENTIALS

Outside sandbox, the same PowerShell HTTPS call succeeds.

Expected behavior

HTTPS requests using Schannel should work in the Windows sandbox when network access is allowed.

Actual behavior

Schannel HTTPS fails in the current sandboxed shell with SEC_E_NO_CREDENTIALS.

Related issue discovered during investigation

The offline firewall setup also appears broken:

setup_error.json contains:

{
  "code": "helper_firewall_rule_create_or_add_failed",
  "message": "SetRemotePorts failed: Error { code: HRESULT(0x80070057), message: \"Параметр задан неверно.\" }"
}

That may be a separate Windows sandbox bug.

Suggested investigation areas

1. Determine whether the active Windows shell sandbox path is using:

• dedicated sandbox users
• or a restricted-token-on-real-user path

1. Compare the failing shell token/context with the successful CodexSandboxOnline / CodexSandboxOffline sessions.
2. Investigate what Schannel/SSPI state is missing in the restricted real-user sandbox context.
3. Separately fix the incorrect env inheritance in the elevated sandbox path.
4. Consider whether #17458 is a prerequisite or partial trigger for this issue, even if it is not the full root cause.