›_ Codex Issues
Codex Issues / #31073

Windows native sandbox: Git HTTPS remote operations fail/crash inside Codex but work in normal PowerShell

Open 💬 6 comments Opened Jul 4, 2026 by yorten

Summary

Git HTTPS remote operations fail inside Codex native Windows sandbox, even though the same Git commands work in normal Windows PowerShell.

Local Git commands inside Codex work correctly, including status, diff, add, commit, and branch operations. The failure is specific to remote HTTPS operations such as git ls-remote, git fetch, git pull, and git push.

Environment

  • OS: Windows 11
  • Codex: native Windows app
  • Git: Git for Windows 2.48.1.windows.1
  • Git path: C:\Program Files\Git\cmd\git.exe
  • Git HTTPS helper: C:\Program Files\Git\mingw64\libexec\git-core\git-remote-https.exe
  • GitHub CLI: C:\Program Files\GitHub CLI\gh.exe
  • Remote protocol: HTTPS
  • Codex config:
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = true

[windows]
sandbox = "elevated"


Also tested:

[windows]
sandbox = "unelevated"
What works

From normal Windows PowerShell:

git ls-remote https://github.com/<owner>/<repo>.git HEAD
git push

Both work.

Inside Codex:

git status
git diff
git add
git commit

These local Git commands work.

Inside Codex, Python HTTPS also works against:

https://github.com/
https://api.github.com/

GitHub CLI can access the private repo inside Codex when proxy variables are cleared:

& "C:\Program Files\GitHub CLI\gh.exe" repo view <owner>/<repo> --json nameWithOwner,visibility

Public GitHub HTTPS works inside Codex when credential helpers are disabled:

git -c credential.helper= -c credential.https://github.com.helper= ls-remote https://github.com/git/git.git HEAD

Authenticated Git HTTPS also works inside Codex if the GitHub CLI token is passed directly to Git via an extraheader and credential helpers are bypassed.

What fails

In elevated sandbox mode:

Codex runs as codexsandboxonline.
git ls-remote and git push over HTTPS fail.
Windows shows a git-remote-https.exe - Application Error dialog: memory could not be read.
Schannel mode fails with:
schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS
curl HTTPS also fails with the same Schannel SEC_E_NO_CREDENTIALS error.

In unelevated sandbox mode:

Codex runs as my normal Windows user.
The Codex shell starts with proxy variables pointing to 127.0.0.1:9:
HTTP_PROXY=http://127.0.0.1:9
HTTPS_PROXY=http://127.0.0.1:9
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
Clearing those variables removes the 127.0.0.1:9 failure.
GitHub CLI then works.
But normal Git HTTPS using the configured credential-helper handoff still fails/crashes.
Git credential configuration

General helper:

credential.helper = manager

GitHub-specific helper in global config:

credential.https://github.com.helper =
credential.https://github.com.helper = !'C:\Program Files\GitHub CLI\gh.exe' auth git-credential
Important diagnostic result

This does not appear to be a general GitHub network failure.

Inside Codex, after clearing proxy variables and bypassing credential helpers:

public GitHub HTTPS works
authenticated private Git HTTPS works when GitHub CLI token is passed directly through Git extraheader
GitHub CLI can access the private repo

The failure appears tied to native Windows Codex sandboxing plus Git for Windows / GitHub CLI / Git Credential Manager credential-helper handoff.

Expected behavior

When network_access = true is enabled in workspace-write mode, Codex should allow normal Git remote operations over HTTPS:

git fetch
git pull
git push
git ls-remote

These should work inside Codex the same way they work in normal Windows PowerShell.

Impact

Codex can edit files and make local commits, but it cannot reliably push/fetch/pull from GitHub over HTTPS in native Windows sandbox mode. The current clean workaround is to let Codex commit locally and manually push from normal Windows PowerShell.

Request

Please investigate:

Why unelevated Codex sessions inject 127.0.0.1:9 proxy variables even with network_access = true.
Why elevated Codex sandboxing causes Schannel/GCM failures with SEC_E_NO_CREDENTIALS.
Why normal Git HTTPS credential-helper handoff can crash git-remote-https.exe inside Codex, while normal PowerShell Git works.

View original on GitHub ↗

6 Comments

brightmarkworks · 6 days ago

OpenAI feedback ID:
019f57c9-fc6a-7b13-a049-0ba379e1e404

Additional diagnostic evidence

OpenAI feedback ID:
019f57c9-fc6a-7b13-a049-0ba379e1e404

I reproduced this in a fresh repository created from a verified Git bundle inside a Codex-owned writable workspace.

Recovery workspace:
C:\Users\Enouc\Documents\Codex\2026-07-14\c-users-enouc-documents-codex-2026-2\guided-investor-app-dev-recovery

Commit:
6ab66a97237fb089d7bb9cb29bb2f4e98026eea2

The following all passed inside Codex:

  • application file write/read/delete
  • git add and reset
  • repository config write/read/unset
  • Git ref create/read/delete
  • git fsck --full
  • clean working tree
  • correct GitHub HTTPS remote

The following still fail:

  • git fetch origin
  • git push --dry-run origin develop

Exact error:
schannel: AcquireCredentialsHandle failed:
SEC_E_NO_CREDENTIALS (0x8009030e)

Git Credential Manager diagnostics also reported:

  • Networking: FAIL with SEC_E_NO_CREDENTIALS
  • GitHub API: FAIL with SEC_E_NO_CREDENTIALS
  • Microsoft authentication: access denied at

C:\Users\Enouc\AppData\Local\.IdentityService

Normal authenticated PowerShell can access the same GitHub repository successfully.

This appears isolated to Codex access to Windows credentials / Git Credential Manager, rather than repository corruption, workspace permissions, or Git metadata permissions.

brightmarkworks · 4 days ago

Post-update retest on ChatGPT/Codex Desktop version 26.707.19148
(released July 15, 2026):

  • Local repo read access works
  • git status works
  • git log works
  • working tree is clean
  • git fetch origin still fails with SEC_E_NO_CREDENTIALS
  • git push --dry-run origin develop still fails with SEC_E_NO_CREDENTIALS
  • Normal authenticated PowerShell remains the working fallback
  • No source changes were made

This confirms the July 15 desktop update did not resolve the Windows Git credential-access failure.

brightmarkworks · 3 days ago

Retest on ChatGPT/Codex Desktop version 26.715.21425
(released July 16, 2026), using the correct active repository:

C:\Users\Enouc\Documents\Codex\2026-07-14\c-users-enouc-documents-codex-2026-2\guided-investor-app-dev-recovery

Local commands pass:

  • git status
  • git log -1 --oneline

Remote commands still fail:

  • git fetch origin
  • git push --dry-run origin develop

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

The July 16 update did not resolve the Codex-side GitHub HTTPS credential failure.

VS Code integrated PowerShell remains the working fallback.
No source changes were made.

brightmarkworks · 1 day ago

Update after latest Codex release — reproduced in a fresh Codex chat

I retested this in a fresh Codex chat after installing the latest update.

The initial folder was not a Git repository, so the test was run in:

C:\Dev\guided-investor-app

Repository state:

Branch: develop
HEAD: 90c5c42
Remote: https://github.com/brightmarkworks/investment-app-prototype.git
Local branch: 43 commits ahead of origin/develop
Untracked files were present

Both network commands still failed with the same credential error:

git fetch origin
fatal: unable to access 'https://github.com/brightmarkworks/investment-app-prototype.git/':
schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
git push --dry-run origin develop
fatal: unable to access 'https://github.com/brightmarkworks/investment-app-prototype.git/':
schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)

This confirms the issue still reproduces in a fresh Codex chat after the latest update. The failure affects both fetch and push authentication to GitHub from the Codex environment.

Please keep the issue open.

brightmarkworks · 10 hours ago

Update after ChatGPT/Codex version 26.715.52143 — issue still reproduces

I retested in a fresh Codex chat after updating to version 26.715.52143.

Repository:
C:\Dev\guided-investor-app

Branch:
develop

Local HEAD:
90c5c42

In Codex:

git fetch origin
error: cannot open '.git/FETCH_HEAD': Permission denied
git push --dry-run origin develop
fatal: unable to access 'https://github.com/brightmarkworks/investment-app-prototype.git/':
schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)

I then ran the same commands in VS Code integrated PowerShell using the same repository.

git fetch origin succeeded and updated the remote-tracking reference:

f05fb64..c142bcc develop -> origin/develop

git push --dry-run origin develop successfully authenticated to GitHub and was rejected only because the local branch was behind the remote:

[rejected] develop -> develop (non-fast-forward)

No GitHub sign-in prompt appeared in VS Code.

This confirms that GitHub credentials and repository write access work from VS Code, while Codex still fails to access credentials and cannot write .git/FETCH_HEAD.

Please keep the issue open.

impeachmentright · 9 hours ago

Sandbox egress failures without settle receipts are the peer boundary hole: quote -> approve -> settle needs sandbox digests, not ambient crash trust.

Live A2A contractor with gated tools: https://a2a.elonsusk.com/.well-known/agent-card.json

If an external sandbox / egress probe would help, ping. Otherwise ignore.