Windows Codex Desktop opens Git Credential Manager while checking ChatGPT Sites remotes

Open 💬 3 comments Opened Jul 29, 2026 by YashSerai

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

26.721.4979.0 (x64); bundled/session CLI 0.146.0-alpha.3.1

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After I started using ChatGPT Sites, Codex Desktop began opening Git Credential Manager during ordinary chat activity. It happened when I sent a message even though neither I nor the agent requested a fetch, pull, push, clone, or other remote Git operation.

I captured this process tree:

ChatGPT.exe
  -> git.exe -c core.hooksPath=NUL -c core.fsmonitor= remote show sites-origin
  -> git remote-https sites-origin https://git.chatgpt-team.site/<workspace>/<project>.git
  -> git credential-manager-core get

The sites-origin remote came from an older ChatGPT Sites workspace. I redacted its identifiers above. The active agent session contained no remote Git command.

This appears to be the path described in #28761, which is stacked on #29470. In particular, git remote show contacted the Sites remote and started the credential helper during a background metadata check.

What steps can reproduce the bug?

Have a local workspace previously connected to ChatGPT Sites with an HTTPS sites-origin remote.
Leave it available to Codex Desktop, then work in another chat or send a message without requesting a Git operation.
Git Credential Manager opens.
The process tree matches the chain shown above.

This happened repeatedly. I captured the trace on July 28, 2026 at 19:02:52 America/Vancouver.

What is the expected behavior?

Default-branch discovery should use local refs and should not contact a remote or open authentication UI during ordinary chat activity.

Additional information

Git for Windows uses the system manager-core credential helper on this machine.

This repository-local workaround stopped the visible window:

git config --local credential.https://git.chatgpt-team.site.interactive false

The same git remote show sites-origin check still invoked GCM and remained stuck for more than 20 seconds.

#31073 covers authenticated operations failing in the sandbox. #33264 covers repeated local probes and orphan processes in a workspace with no remote. This report is about a background git remote show against a Sites remote opening GCM.

I am happy to test a Windows build or help add a focused regression test.

View original on GitHub ↗

3 Comments

sri299792458 · 1 month ago

Independent reproduction of this exact issue on Windows after deploying a ChatGPT Site.

Environment:

ChatGPT Desktop: 1.2026.190.0
Windows 11 Home, build 26200, x64
Git for Windows: 2.41.0.windows.1
Git Credential Manager: 2.1.2

Observed repository state:

The local branch tracks sites/main.
The sites remote points to https://git.chatgpt-team.site/<redacted-workspace>/<redacted-project>.git.
The system Git configuration enables credential.helper=manager.
Git Credential Manager windows appear intermittently after the repository has been connected to ChatGPT Sites, even when the user is not intentionally fetching or publishing.

A read-only non-interactive check reproduced the authentication boundary:

GIT_TERMINAL_PROMPT=0
GCM_INTERACTIVE=Never
git ls-remote sites

fatal: Cannot prompt because user interactivity has been disabled.
fatal: could not read Username for 'https://git.chatgpt-team.site': terminal prompts disabled

This confirms that ordinary access to the persisted Sites remote falls through to the global HTTPS credential helper. Sites publishing itself uses a temporary per-operation credential rather than a durable GCM credential, so subsequent background remote checks can reopen the credential UI.

Expected behavior: background repository/default-branch metadata checks should not contact the protected Sites remote or invoke interactive credential helpers. The Sites remote should be skipped for automatic checks, queried non-interactively, or supplied with an appropriate refreshable credential.

No project or account identifiers are included here. Happy to provide additional sanitized diagnostics if useful.

sandan-dominik · 24 days ago

Same here

floxrot · 2 hours ago

I can independently confirm this issue on Windows.

Codex Desktop repeatedly launches Git Credential Manager during ordinary task execution, including when neither the user nor the agent requested any remote Git operation. This affects multiple repositories and is not limited to one broken credential configuration.

The repository-local credential.<url>.interactive=false workaround is not viable. It merely suppresses the prompt; it does not prevent Codex from invoking Git Credential Manager or performing the remote probe. More importantly, it also breaks legitimate Git operations performed by other applications such as SourceTree, causing pushes to fail with:

fatal: Cannot prompt because user interactivity has been disabled.

This is therefore not just a cosmetic popup issue. Users currently have to choose between repeated unsolicited authentication dialogs from Codex and breaking authentication in their normal Git clients.

The impact is compounded by the ongoing Windows sandbox/ACL failure family, such as #36087. In my environment, sandbox ACL initialization failures can already prevent shell commands and file operations from running reliably. Combined with the unsolicited Git/GCM activity, this makes Codex Desktop on Windows effectively unusable for normal professional development workflows.

These may be separate root causes, but together they represent a serious Windows reliability regression. Background repository inspection must not:

Contact a remote merely to discover repository metadata.
Invoke an interactive credential helper.
Inherit persistent repository credential settings intended for normal user Git clients.
Require users to disable Git Credential Manager globally or per repository.

Please use local refs for metadata discovery and explicitly disable credential prompting only for the background child process. Hiding the console window alone would not fix the underlying problem—the remote probe itself must either be removed or made strictly non-interactive and fail-fast.

At minimum, this issue needs an assigned owner, an acknowledged status, and a supported mitigation. Leaving Windows users to modify Git authentication globally or install third-party process wrappers is not an acceptable workaround for a desktop application performing unsolicited background Git operations.