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

Open 💬 18 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 ↗

18 Comments

brightmarkworks · 1 month 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 · 1 month 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 · 1 month 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 month 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 · 1 month 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.

brightmarkworks · 1 month ago

Retested after updating to ChatGPT/Codex version 26.715.61943
(released July 20, 2026).

The core issue remains unresolved.

Test environment:

Windows
Git 2.53.0.windows.2
Repository:

C:\Dev\guided-investor-app

Branch:

develop, 70 commits behind origin/develop

Existing untracked files were present
No real push was performed

Results:

git fetch origin — FAILED

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

No credentials are available in the security package

git push --dry-run — FAILED

Same SEC_E_NO_CREDENTIALS failure.

Direct .git/FETCH_HEAD read/write probe — PASSED

This appears improved compared with earlier tests.

git add temporary-file — FAILED

fatal: Unable to create
'C:/Dev/guided-investor-app/.git/index.lock':
Permission denied

git restore --staged temporary-file — FAILED

Same .git/index.lock permission failure.

Direct .git/index.lock creation probe — FAILED

Access to the path
'C:\Dev\guided-investor-app\.git\index.lock'
is denied.

The temporary test file was removed. Final repository status matched
the initial state.

Interpretation:

The update appears to have changed one symptom because FETCH_HEAD is
now directly writable. However, the two main blockers remain:

Codex still cannot access the Windows Git credential context

for HTTPS operations.

Codex still cannot create .git/index.lock and therefore cannot

stage, unstage, or commit reliably.

The same repository continues to work from normal Windows
PowerShell / VS Code under the same user account.

Please clarify:

Was version 26.715.61943 intended to address this issue?

Has the root cause been identified?

Is the remaining problem believed to involve:

Windows credential inheritance
Codex process identity
sandbox ACL handling
Git subprocess handling
or another component?

What exact validation sequence should users run to confirm

the intended fix?

brightmarkworks · 1 month ago

Retested after updating to ChatGPT/Codex desktop version 26.715.72359
(released July 22, 2026).

The issue is still present.

Test environment:

Windows
Repository:

C:\Users\Enouc\Documents\Codex\schema-source-remediation-v0a

Branch:

tech/schema-source-remediation-v0a

HEAD:

f4b5c7c960a36e1c13beaf66f75c80247f9a744c

Initial working tree:

clean

Existing untracked files:

none

No real push was performed

Results:

Workspace access — PASSED

Codex could read:

repository path
branch
HEAD
working-tree status

git log — PASSED

Latest commit:
f4b5c7c Update grant contract governance docs

git status — PASSED

Remote credential test — FAILED

Command:
git ls-remote origin HEAD

Error:
fatal: unable to access
'https://github.com/brightmarkworks/investment-app-prototype.git/':
schannel: AcquireCredentialsHandle failed:
SEC_E_NO_CREDENTIALS (0x8009030e) -
No credentials are available in the security package

Temporary file creation — PASSED

git add temporary file — FAILED

git restore --staged temporary file — FAILED

.git/index.lock creation — FAILED

Codex still could not create or use .git/index.lock for staging operations.

Cleanup — PASSED

The temporary file was removed and the repository returned to a clean state.

Interpretation:

The July 22 update did not resolve the two main Windows sandbox failures:

Codex still cannot access the Windows Git credential context for HTTPS remote operations.
Codex still cannot create or use .git/index.lock, so it cannot reliably stage, unstage, or commit.

The same repository continues to work from normal Windows PowerShell under the same user account.

Please keep this issue open.

Could you also confirm:

Whether version 26.715.72359 was intended to include a fix for this issue.
Whether the root cause has been identified.
Whether the remaining failure is believed to involve:

Windows credential inheritance
Codex process identity
sandbox ACL handling
Git subprocess handling
or another component

What exact validation sequence users should run once a fix is released.

brightmarkworks · 1 month ago

Update after installing the July 23, 2026 ChatGPT desktop release.

Environment

ChatGPT desktop:

Version 26.721.30844
Released July 23, 2026

Closest installed OpenAI desktop package observed:

OpenAI.Codex_26.721.3404.0_x64__2p2nqsd0c76g0

Repository:

Windows 10
Local Git repository
HTTPS GitHub remote
Working tree clean
Workspace reads successfully

Result

The issue is still reproducible after the update.

Workspace read:
PASS

Repository state:

Current branch and HEAD can be read
git status --short succeeds
Working tree remains clean

Repository write probes:
FAIL

The attempted .git and source-root write/delete probes were blocked before
PowerShell execution with:

approval required by policy, but
AskForApproval::Granular.sandbox_approval is false

Git fetch:
FAIL

Exact error:

error: cannot open '.git/FETCH_HEAD': Permission denied

Git push dry run:
FAIL

Exact error:

fatal: unable to access
'https://github.com/brightmarkworks/investment-app-prototype.git/':
schannel: AcquireCredentialsHandle failed:
SEC_E_NO_CREDENTIALS (0x8009030e) -
No credentials are available in the security package

Codex executable:
FAIL

Command:

codex --version

Exact error:

Program 'codex.exe' failed to run: Access is denied

Additional context

The repository is readable, but Codex still cannot reliably:

write Git metadata;
create Git lock files;
update FETCH_HEAD;
use Windows HTTPS Git credentials;
execute codex.exe from the session.

The same repository operations succeed when run manually in a normal
PowerShell session, including branch creation, commit, merge, fetch, and push.

Because the core write, fetch, credential, and executable-access failures
remain, my current disposition is:

NOT FIXED

Possible areas to investigate:

The desktop sandbox or approval policy is denying repository writes before

PowerShell commands execute.

The Codex process appears unable to write to .git, even when the repository

working tree is otherwise accessible.

Windows Schannel credentials available to normal PowerShell are not being

inherited or exposed to the Codex session.

codex.exe itself is returning Access denied inside the session.

Related earlier issue:
#29797

Current primary thread:
#31073

Is there a diagnostic log, sandbox-policy report, or permission trace I can
collect from the desktop app that would show why:

AskForApproval::Granular.sandbox_approval is false;
.git/FETCH_HEAD is not writable;
Windows Schannel credentials are unavailable; and
codex.exe is denied execution?

brightmarkworks · 1 month ago

Update after installing the latest ChatGPT desktop build.

Environment

ChatGPT desktop:

Version 26.721.31836
Released July 23, 2026

Installed Codex package observed:

OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0

Repository tested:
C:\Users\Enouc\Documents\Codex\schema-source-remediation-v0a

Final repository state:

Working tree clean

Result

The issue appears partially fixed.

What now works

Repository source-root write/delete:
PASS

Codex can now create, read, and remove ordinary files in the repository source tree.

What still fails in the normal sandbox

.git/index.lock create/delete:
FAIL

Exact error:

New-Item : Access to the path
'...\schema-source-remediation-v0a\.git\index.lock'
is denied.

git fetch origin:
FAIL

Exact error:

error: cannot open '.git/FETCH_HEAD': Permission denied

git push --dry-run origin develop:
FAIL

Exact error:

What works when escalated

.git/index.lock create/delete:
PASS

Observed:

True
False

git fetch origin:
PASS

Observed:
No error output

git push --dry-run origin develop:
PASS

Observed:

Everything up-to-date

What remains blocked even when escalated

codex --version:
FAIL

Exact error:

Program 'codex.exe' failed to run:
Access is denied

Detected executable:

C:\Program Files\WindowsApps\
OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0\
app\resources\codex.exe

Current disposition

PARTIALLY FIXED

Practical behavior now:

ordinary source-file edits work in the sandbox;
Git metadata writes still fail without escalation;
fetch still cannot write FETCH_HEAD without escalation;
Git HTTPS credentials are still unavailable without escalation;
codex.exe execution remains denied even when escalated.

This is an improvement over the previous build, where source-root writes were also blocked, but the repository Git workflow is not yet fully usable without escalation or manual PowerShell fallback.

Questions for maintainers

Is it expected that .git metadata operations require escalation while ordinary repository writes do not?

Is the Schannel credential failure caused by the sandbox not inheriting Windows Git credentials?

Is there a supported way to grant persistent repository Git metadata access without approving each operation?

Is the codex.exe Access denied failure expected for the WindowsApps package path, or does it indicate a separate packaging/ACL issue?

Related earlier issue:
#29797

Current primary thread:
#31073

brightmarkworks · 1 month ago

Request for human review / escalation

Over the past two weeks, we have posted nine separate comments documenting repeated Windows tests across multiple ChatGPT/Codex desktop updates.

The latest full repeat test is complete, and the issue remains NOT FIXED.

At this point, we are requesting escalation to a human engineer or support reviewer. Continued end-user update-and-retest cycles are no longer productive without someone reviewing the sandbox, credential, and executable-permission behavior directly.

Latest tested environment

ChatGPT desktop:

Version 26.721.41059

Installed Codex package:

OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0

Repository:
C:\Users\Enouc\Documents\Codex\schema-source-remediation-v0a

GitHub remote:
https://github.com/brightmarkworks/investment-app-prototype.git

Repository baseline:

Branch: develop
HEAD: 7fe702775a15d1084beba5b9542670d30b6b94ca
Working tree: clean

Latest repeat-test result

Overall issue status:
NOT FIXED

Workspace read:
PASS

Source-root write/read/delete:
BLOCKED BY POLICY

Exact error:

approval required by policy, but AskForApproval::Granular.sandbox_approval is false

.git temporary-file write/delete:
BLOCKED BY POLICY

Exact error:

approval required by policy, but AskForApproval::Granular.sandbox_approval is false

Escalation for the .git temporary-file test:
NOT AVAILABLE

.git/index.lock safety precheck:

Existing lock: False
Active Git processes: None

.git/index.lock create/delete:
BLOCKED BY POLICY

Exact error:

approval required by policy, but AskForApproval::Granular.sandbox_approval is false

Escalation for the index-lock test:
NOT AVAILABLE

Final .git/index.lock state:
False

git fetch origin:
FAIL, both non-escalated and escalated

Exact error:

error: cannot open '.git/FETCH_HEAD': Permission denied

git push --dry-run origin develop:
FAIL, both non-escalated and escalated

Exact error:

SEC_E_NO_CREDENTIALS still present:
YES

Detected Codex paths:

C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\resources\codex

C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

codex --version:
FAIL

Exact error:

Program 'codex.exe' failed to run: Access is denied

Escalated codex --version:
NOT AVAILABLE

Exact policy response:

approval policy is Granular(GranularApprovalConfig {
sandbox_approval: false,
rules: false,
skill_approval: false,
request_permissions: true,
mcp_elicitations: true
});
reject command — you should not ask for escalated permissions if the approval policy is Granular(...)

Final cleanup

Temporary artifacts remaining:
NONE

Final branch:
develop

Final HEAD:
7fe702775a15d1084beba5b9542670d30b6b94ca

Final working tree:
CLEAN

Practical impact

Normal development work still requires frequent manual PowerShell intervention outside Codex for:

branch creation
Git staging
commits
merges
fetch
push
Git metadata writes
cleanup operations blocked by the sandbox

Codex can read the repository, but the Git workflow remains unreliable or unusable inside the normal desktop sandbox.

Requested human review

Please escalate this issue to a human engineer or support reviewer who can directly inspect:

Why AskForApproval::Granular.sandbox_approval remains false.

Why repository source-root and .git write operations are blocked before PowerShell executes.

Why .git/FETCH_HEAD is not writable even when escalation is attempted.

Why Windows Schannel credentials available to normal PowerShell are unavailable inside Codex.

Why codex.exe in the WindowsApps package returns Access denied.

Why escalated execution is unavailable in this policy state.

Why behavior has changed or regressed across desktop builds.

Whether multiple symptoms represent one sandbox/packaging defect or separate issues.

We are willing to provide:

desktop diagnostic logs
sandbox-policy reports
Windows ACL/permission traces
Git credential-manager diagnostics
a controlled reproduction session
a support bundle from the desktop app

However, after nine comments and repeated retesting across multiple updates, we are requesting that further testing be guided by a human reviewer rather than continuing blind update-and-retest cycles.

Please confirm:

whether this issue has been assigned for human review;
whether there is a diagnostic bundle we should collect;
whether the sandbox policy state shown above is expected;
whether the codex.exe WindowsApps execution failure is a known packaging issue.

Related earlier issue:
#29797

Current primary thread:
#31073

brightmarkworks · 28 days ago

Follow-up on human-review request

It has now been five days since the human-review/escalation request above, and there has been no maintainer response or assignment.

The issue remains active in current development work. The latest reproduction occurred during Step 7 Package 2:

Codex source editing and validation succeeded.
Authenticated Git remote operations still failed inside Codex.
A fetch attempt again encountered the Windows credential/schannel failure.
Git metadata operations still required manual handling outside Codex.
We again had to create a Git bundle, import it in normal Windows PowerShell, merge there, and push outside Codex.

Current practical impact:
Every implementation cycle requires a manual transfer and authenticated Git workflow outside Codex.

We are not requesting another blind update-and-retest cycle. We are requesting confirmation of one of the following:

This issue has been assigned for human review.
A maintainer needs a specific diagnostic bundle or log.
The issue should be split into separate credential, Git metadata, and WindowsApps execution defects.
There is another support channel where this desktop sandbox problem should be escalated.

Please advise before asking for another full retest.

brightmarkworks · 28 days ago

Post-update retest — normal updates welcome, human review still requested

ChatGPT desktop version shown in the app:
26.727.40816
Released July 30, 2026

Detected Codex package:
OpenAI.Codex_26.727.4816.0_x64__2p2nqsd0c76g0

Test repository:
C:\Dev\guided-investor-app

Result:
NOT FIXED

Bounded validation results:

codex --version — FAIL

Program 'codex.exe' failed to run: Access is denied.

Detected executable:
C:\Program Files\WindowsApps\OpenAI.Codex_26.727.4816.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

git status — PASS

Repository readable.
Branch: develop
Existing repository state remained unchanged.

Temporary source-file write/delete — PASS

A temporary source-root file was created and removed successfully.

.git/index.lock create/delete — FAIL

Access to .git\index.lock was denied.
No lock file remained after the test.

git fetch origin — FAIL

Exact error:
schannel: AcquireCredentialsHandle failed:
SEC_E_NO_CREDENTIALS

git push --dry-run origin develop — FAIL

Same SEC_E_NO_CREDENTIALS failure.

Final cleanup — PASS

No temporary test files remained.
The working tree returned to its original state.

Current practical result:

ordinary source-file writes now work;
Git metadata lock-file access still fails;
authenticated Git HTTPS fetch and push still fail;
codex.exe still cannot be executed from the session.

Normal maintenance updates are welcome and should continue. We are not asking for updates to be withheld.

However, this issue still requires human review and triage. Repeated automatic update-and-retest cycles have not resolved the underlying Windows sandbox, credential, Git metadata, and executable-access failures.

Please confirm:

Whether this issue has been assigned to a human engineer or support reviewer.
Whether it has been triaged to the responsible Windows sandbox, credential, or packaging team.
Whether a specific diagnostic bundle, sandbox-policy report, ACL trace, or Git Credential Manager log is needed.
Whether the remaining symptoms should be split into separate tracked defects.

We will continue installing normal maintenance updates, but further issue-specific testing should be guided by a human reviewer rather than repeated blindly after every release.

Related earlier issue:
#29797

Current primary issue:
#31073

Tempestline · 26 days ago

Independent reproduction on 2026-08-02 — current Store build still affected

I independently reproduced this on another Windows installation.

Environment

Native Windows ChatGPT/Codex desktop app
Installed package: OpenAI.Codex 26.727.6591.0 (Status: Ok)
Codex CLI outside sandbox: 0.146.0
Git for Windows: 2.48.1.windows.1
Permission mode: workspace sandbox with automatic approval/review
Sandbox identity: <machine>\CodexSandboxOffline
GitHub remote protocol: HTTPS
GitHub CLI authentication storage: Windows keyring

Microsoft Store reports:

No available upgrade found.
No newer package versions are available from the configured sources.

Inside the normal sandbox

gh auth status fails before it can use the authenticated account:

warning: failed to load config: open %APPDATA%\GitHub CLI\config.yml: Access is denied.
failed to create root command: failed to read configuration

git ls-remote --exit-code origin HEAD fails with:

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

codex --version also fails inside the sandbox:

Program 'codex.exe' failed to run: Access is denied

The executable resolves into the packaged C:\Program Files\WindowsApps\OpenAI.Codex_26.727.6591.0... directory.

Approved host-boundary controls

The same operations succeed when explicitly retried through approved execution outside the sandbox:

codex --version returns codex-cli 0.146.0
gh auth status reports the existing keyring-backed login as active
gh repo view successfully reads private repository metadata and reports the expected permission
git ls-remote --exit-code origin HEAD succeeds and returns the remote HEAD

No push or repository mutation was performed.

ACL/setup observations

Read-only ACL inspection found:

CodexSandboxOffline and CodexSandboxOnline both exist and are enabled.
The workspace ACL includes CodexSandboxUsers with modify access.
%APPDATA%\GitHub CLI has the normal owner/SYSTEM/Administrators ACL and no CodexSandboxUsers entry.
The desktop package is healthy, and approved execution works, so this does not look like repository corruption, a broken GitHub login, or an incomplete app installation.

Impact / expected behavior

The approved host-boundary workaround is functional, but credentialed GitHub commands first run in the offline sandbox and fail. With automatic approval enabled, Codex should ideally recognize gh and authenticated remote Git operations as needing approved execution before the failed attempt, or provide a supported scoped credential/network broker for the elevated Windows sandbox.

A clean reinstall appears unlikely to help because the dedicated sandbox accounts and workspace ACLs are present and behaving as designed; the missing credential/profile access is the remaining boundary.

No credentials, usernames, private repository names, or tokens are included in this report.

yorten · 25 days ago

Update from the original reporter — the issue is no longer reproducing in my environment

I am no longer experiencing the original GitHub HTTPS and credential-access problem on my computer. However, I do not know which desktop release changed the behavior, and I do not consider this confirmation that the issue is fixed for everyone.

Several ChatGPT/Codex desktop updates were installed between my original failures and the successful tests. Before the successful test, I also completely exited the desktop app from the system tray and used Task Manager to terminate five remaining ChatGPT Classic processes.

Because multiple desktop updates and the complete process cleanup occurred before the successful test, I cannot determine whether:

a particular update fixed the problem;
terminating the remaining Classic/background processes was necessary;
or the recovery resulted from a combination of both.

The most useful behavioral difference I observed was the Windows execution identity.

Before the recovery, GitHub-related commands ran as:

desktop-pplbrda\codexsandboxoffline

In that state:

GitHub CLI could not access the valid Windows keyring-backed login;
GitHub network commands failed;
Codex did not present a usable approval prompt;
and authenticated GitHub operations did not work.

After the updates, full application shutdown, background-process cleanup, and a fresh Codex session, Codex began requesting permission for GitHub network and credential access.

After I approved the request, the command ran as:

desktop-pplbrda\tc

GitHub CLI then recognized my existing authenticated GitHub account:

gh auth status succeeded;
gh api user --jq .login returned the expected account.

I subsequently completed an end-to-end native GitHub workflow from Codex:

created a private GitHub repository;
added a normal HTTPS origin;
pushed main and a feature branch;
created a pull request;
reviewed and merged the pull request;
fast-forwarded local main from GitHub;
and finished with a clean working tree.

No workaround was used during that successful workflow:

no old Git wrapper;
no proxy-variable clearing;
no in-memory token extraheader;
no SSH conversion;
no Git credential reconfiguration.

I have continued using Codex through several additional desktop updates and have not noticed the original problem returning.

The reports from other users appear consistent with an important distinction:

commands that remain inside CodexSandboxOffline cannot access the user’s GitHub CLI configuration, Windows keyring, or Schannel credential context;
commands that are correctly routed through approved execution under the normal Windows user can access those credentials and work.

This suggests that the remaining issue may involve inconsistent approval or host-boundary routing rather than broken GitHub credentials themselves.

For affected users, one low-risk troubleshooting test may be:

Install all available ChatGPT/Codex desktop updates.
Exit the application completely from the system tray.
Open Task Manager and check for remaining ChatGPT, ChatGPT Classic, Codex, or related OpenAI desktop processes.
Terminate any remaining processes.
Reopen the app and start a fresh Codex session.
Test:

whoami
gh auth status --hostname github.com
gh api user --jq .login
git ls-remote --exit-code origin HEAD

The important observation is whether Codex requests approval and whether approved execution changes the identity from CodexSandboxOffline to the normal Windows user.

I am sharing this as a successful recovery case and a possible diagnostic lead. I cannot attribute the recovery to a specific desktop version, and the independent reproductions in this thread show that the behavior is not yet resolved consistently for every user.

Tempestline · 19 days ago

Post-update retest and approval-routing workaround — 2026-08-09

The issue still reproduces in the ordinary native Windows sandbox after updating:

Desktop package: OpenAI.Codex 26.803.5235.0
Local bundled CLI: 0.147.0-alpha.6.5
Normal command identity: <machine>\CodexSandboxOffline
gh auth status fails to read %APPDATA%\GitHub CLI\config.yml with Access is denied
Public and private git ls-remote over HTTPS fail with SEC_E_NO_CREDENTIALS
DNS resolution and TCP 443 connectivity succeed
codex --version through the packaged WindowsApps executable still fails with Access is denied

The documented unelevated fallback has been tried repeatedly on this machine and has not provided a durable fix.

New diagnostic result

Approval/host-boundary routing is sensitive to how the command is issued:

A compound PowerShell diagnostic containing multiple GitHub/Git commands was approved but still ran as CodexSandboxOffline; every credentialed operation failed.
The same checks succeed when each operation is issued as a standalone command with an explicit host escalation and a narrowly scoped prefix rule.

Successful standalone controls:

gh auth status --hostname github.com recognized the existing keyring-backed login.
gh repo view <private-repo> --json ... read private repository metadata with the expected permission.
git ls-remote https://github.com/<private-repo>.git HEAD returned the remote HEAD.

Repeating gh auth status without explicit host escalation immediately returns to the original AppData Access is denied failure.

This further isolates the problem to command classification and approval/host-boundary routing, rather than a broken GitHub login, repository, network connection, or Windows credential store.

Practical workaround

For this affected installation, Codex can perform GitHub work if it emits gh and remote git operations as separate, explicitly escalated tool calls with narrowly scoped command rules. Implicit retries and compound PowerShell batches remain unreliable.

Please investigate why an approved compound command can remain inside CodexSandboxOffline, while an equivalent standalone scoped command correctly crosses to the host user. No credentials, tokens, usernames, or private repository names are included here.

VerityCE · 18 days ago

Corroboration from another current Windows 11 installation (2026-08-10).

Environment:

Codex CLI 0.146.0
native Windows sandbox, workspace-write
CodexSandboxOnline

Redacted codex doctor --json reports:

Schannel update probe: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e);
no Codex credentials in the sandbox identity's home;
required ChatGPT endpoint unreachable from that diagnostic subprocess.

Additional isolation:

connected GitHub app operations work;
CLI/curl credential paths do not;
gh auth status currently also reports its stored token invalid, so that is a separate local auth fact rather than proof of the Schannel root cause;
most importantly, an explicitly approved standalone whoami still returns CodexSandboxOnline. The host-routing workaround reported above is therefore unavailable in this permission profile.

Please document or implement a supported brokered path for approved Git/GitHub commands to execute with the normal user's authorized credential context, without copying tokens into repositories/environment files, disabling the sandbox, or requiring WSL.

brightmarkworks · 17 days ago

Update after latest ChatGPT/Codex desktop release — issue still present in my environment

Thanks to everyone who has continued testing and sharing results here. The recent reports about approval/host-boundary routing have been especially helpful.

I retested after updating to the current ChatGPT/Codex desktop version:

ChatGPT/Codex Desktop: 26.803.61601
Windows: native Windows environment
Repository: normal local Git repository with HTTPS GitHub remote

My practical result remains similar to earlier tests:

ordinary repository/source access works;
Codex can perform the application/source work;
Git metadata operations still periodically require manual PowerShell intervention because Codex cannot reliably create the needed .git lock files;
authenticated Git HTTPS operations from the Codex environment still fail with the Windows credential/Schannel path;
normal account-owner PowerShell continues to work for the same repository.

The recurring Git HTTPS error remains:

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

I have also continued seeing .git metadata permission failures during normal development work, for example when Codex attempts branch creation, staging, merges, or ref/lock updates. Those operations succeed when I perform them manually from normal Windows PowerShell.

The newer comments in this thread suggest an important distinction between:

commands that remain under CodexSandboxOffline / CodexSandboxOnline; and
commands that are successfully routed through an approved host boundary under the normal Windows user.

In my environment, I have not yet seen a reliable automatic transition to a usable normal-user credential context that removes the need for the PowerShell fallback.

I am continuing normal maintenance updates, but I am trying to avoid repeating broad blind retest cycles. If maintainers would like a specific focused test—particularly around whoami, approval routing, standalone Git commands, sandbox identity, .git lock creation, or Schannel credential acquisition—I’m happy to run it.

Thanks again to the other users who have posted reproductions and workarounds. Those reports are helping narrow this from a general Git/network problem toward the Windows sandbox identity / approval / credential-routing boundary.

Current disposition in my environment: still not resolved.

ale-arc · 1 day ago

Current reproduction: credentials exist; Codex sandbox misclassifies the failure

Reproduced on 2026-08-26 on Windows with the current Codex desktop environment and sandbox_mode = workspace-write.

The GitHub credentials are valid: gh auth status succeeds using the existing local login, without exposing account or token details.

Differential test against the same repository and command:

Inside Codex sandbox:
git ls-remote origin refs/heads/main
fatal: ... schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)

Outside Codex sandbox / approved host execution:
git ls-remote origin refs/heads/main
4d312540375703a740269910e0de2acc7efd00b1  refs/heads/main

An actual git fetch origin main outside the sandbox also succeeded and updated the local remote-tracking ref. The repository and credentials were not broken.

The additional Codex failure is diagnostic: after the sandbox command failed, the agent reported that GitHub credentials were absent. That conclusion is incorrect and can cause unnecessary credential repair or re-authentication guidance. The accurate classification is a sandbox/Schannel credential-context or host-boundary routing failure, with a valid credential available to the normal Windows user.

Expected behavior:

Treat SEC_E_NO_CREDENTIALS from a sandboxed Schannel process as a sandbox transport/context failure, not proof that the user's GitHub credentials are absent.
Route credentialed Git operations through the supported approved host boundary when available, or report the boundary limitation explicitly.
Preserve the existing credential and avoid asking users to copy tokens, disable TLS verification, or re-authenticate without evidence that the credential itself is invalid.

No token, secret, account identifier, private repository name, or credential material is included in this report.