Git 2.55.0.windows.3: writes to refs/remotes/* silently rolled back on machines with antivirus real-time protection (exit 0, no output)

[XLF66666]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.55.0.windows.3
cpu: x86_64
built from commit: 52ca1113d651127f89477a8763f86ab20f645e1d
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.21.0
OpenSSL: OpenSSL 3.5.7 9 Jun 2026
zlib: 1.3.2
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [版本 10.0.26100.4652]

Options set during installation

Portable/bundled copy — NOT installed via Git for Windows setup.exe. It is shipped by WorkBuddy desktop v5.3.14 at ~/.workbuddy/binaries/PortableGit/versions/1.2.0/ (so no C:\Program Files\Git\etc\install-options.txt exists on this machine). Default options otherwise. The only effective non-default is that this git.exe sits ahead of system Git on PATH inside the WorkBuddy agent session.

Other interesting things

Environment correlation (the key signal):

• Affected binary: bundled portable Git 2.55.0.windows.3 (path above) → refs/remotes/* writes silently lost.
• Control: system-installed Git 2.45.2.windows.1 (C:\Program Files\Git) on the SAME machine, SAME repo, SAME operations → works correctly.
• Resident security software: Windows Defender real-time protection enabled + Sangfor aTrust zero-trust client.

Scope of the defect (what still works) — isolated via a systematic experiment matrix:

Operation	Result
Write to refs/remotes/* (fetch/push/update-ref)	silently lost
Write to refs/heads/* (local branches)	works
Write objects (git hash-object -w)	works
Write .git/config (git config)	works
Read-only commands (status/rev-parse/log/branch)	work, do not trigger cleanup
Plain bash-level printf > .git/refs/remotes/origin/master	persists (survives 60s polling)
Manual writes via Git 2.45.2 update-ref	persists

Excluded causes: non-sample hooks (none), core.hooksPath (unset), fsmonitor/maintenance (unset), reftable (absent), commondir (absent), repo corruption (reproduces on a fresh empty repo under pure-ASCII $env:TEMP), binary tampering (valid Johannes Schindelin Authenticode signature), path-based or process-based sandboxing (failure follows the binary when copied to a plain directory, and reproduces in native PowerShell with no shell wrappers).

Hypothesis: The ref-write transaction path in 2.55 interacts badly with real-time file-system filter drivers (antivirus / zero-trust clients hooking file I/O): the write is reported complete (exit 0, no stderr), then silently rolled back after the file handle closes. The 2.45 code path does not trigger this. Could not identify the specific filter (querying Defender exclusions needs admin), but the binary-version correlation is deterministic on this machine. This resembles a previously-fixed git-for-windows class of bug where a security-software Windows Filter Platform driver rewrote git's stdout buffering and output was lost on exit (fixed via explicit fflush(stdout) before exit) — same root category (resident security filter driver silently breaking git I/O on Windows), 2.55 regressed where 2.45 did not.

Impact: remote-tracking refs silently regress to a stale packed-refs snapshot, so every consumer of "where does origin point" gets wrong data: git status shows a bogus ahead/behind count, and AI coding agents relying on these refs to decide whether to pull can skip syncs or act on stale remote history — with zero error signal.

Workaround: writing the loose ref file directly (outside git) persists:
mkdir -p .git/refs/remotes/origin
git ls-remote origin master | awk '{print $1}' > .git/refs/remotes/origin/master

Terminal/shell

PowerShell (native, no shell wrappers). Also reproduces via a plain printf to the ref file in bash, proving it is not shell-specific. The bug manifests ONLY with the bundled 2.55.0.windows.3 binary; system Git 2.45.2.windows.1 on the same machine does NOT exhibit it.

Commands that trigger the issue

$git = "$env:USERPROFILE\.workbuddy\binaries\PortableGit\versions\1.2.0\mingw64\bin\git.exe"
$t = "$env:TEMP\git-refs-bug-repro"
Remove-Item -Recurse -Force $t -ErrorAction SilentlyContinue
New-Item -ItemType Directory $t | Out-Null
Set-Location $t
& $git init -q .
& $git -c user.email=t@t -c user.name=t commit -q --allow-empty -m init
$sha = (& $git rev-parse HEAD).Trim()
& $git update-ref refs/remotes/origin/master $sha
"exit code          : $LASTEXITCODE"
"ref file persisted : $(Test-Path "$t\.git\refs\remotes\origin\master")"
"git reads it back  : $(& $git rev-parse refs/remotes/origin/master 2>$null)"

Expected behaviour

On a healthy setup the three printed lines are:
exit code : 0
ref file persisted : True
git reads it back :
The ref file should persist on disk and git rev-parse refs/remotes/origin/master should return that SHA.

Actual behaviour

On the affected machine the three printed lines are:
exit code : 0 ← success illusion, no error anywhere
ref file persisted : False ← .git/refs/remotes/origin/master does NOT exist on disk
git reads it back : (empty) ← git rev-parse reports "unknown revision"
Additionally, any pre-existing loose refs under .git/refs/remotes/origin/ are DELETED by the operation, so ref resolution falls back to a stale packed-refs snapshot. git status then shows a bogus "[ahead 498]" count. The exact same script with system Git 2.45.2.windows.1 prints True / — same machine, same repo, only the binary differs.

Repository

N/A — reproduces on a freshly git init empty repo under $env:TEMP; not tied to any specific remote or repo contents. (In production the symptom surfaced against a Gitee-hosted project, but the ref-write failure is independent of the remote.)

[dscho]

"Loose refs" are an implementation detail that no user should rely on. For example, if the local Git is configured to use reftable as ref format, those loose ref files should not even exist, and the assumption that you are entitled to rely on their presence is simply incorrect.

The only valid way to check for the presence of those refs is by using git commands such as rev-parse or for-each-ref.

[dscho]

Just for the record, the reproducer does not reproduce here (I did not use Portable Git, but that shouldn't matter):

PS C:\Windows\system32> git version
git version 2.55.0.windows.5
PS C:\Windows\system32> cd D:\repros\
PS D:\repros> git init missing-remote-refs-6396
Initialized empty Git repository in D:/repros/missing-remote-refs-6396/.git/
PS D:\repros> cd .\missing-remote-refs-6396\
PS D:\repros\missing-remote-refs-6396> git -c user.email=t@t -c user.name=t commit -q --allow-empty -m init
PS D:\repros\missing-remote-refs-6396> $sha = (& git rev-parse HEAD).Trim()
PS D:\repros\missing-remote-refs-6396> $sha
3da03f0e27334cb9898a80118db9d44190957f54
PS D:\repros\missing-remote-refs-6396> git update-ref refs/remotes/origin/master $sha
PS D:\repros\missing-remote-refs-6396> git rev-parse refs/remotes/origin/master
3da03f0e27334cb9898a80118db9d44190957f54
PS D:\repros\missing-remote-refs-6396>

(The internal file exists, but as I said, that's an implementation detail that is subject to change, and not part of the public contract.)

[XLF66666]

Just for the record, the reproducer does not reproduce here (I did not use Portable Git, but that shouldn't matter):顺便说明一下，这里的“复制器”实际上并不具备复制功能（我没有使用 Portable Git 工具，不过这其实并不重要）：

PS C:\Windows\system32> git version
git version 2.55.0.windows.5
PS C:\Windows\system32> cd D:\repros\
PS D:\repros> git init missing-remote-refs-6396
Initialized empty Git repository in D:/repros/missing-remote-refs-6396/.git/
PS D:\repros> cd .\missing-remote-refs-6396\
PS D:\repros\missing-remote-refs-6396> git -c user.email=t@t -c user.name=t commit -q --allow-empty -m init
PS D:\repros\missing-remote-refs-6396> $sha = (& git rev-parse HEAD).Trim()
PS D:\repros\missing-remote-refs-6396> $sha
3da03f0e27334cb9898a80118db9d44190957f54
PS D:\repros\missing-remote-refs-6396> git update-ref refs/remotes/origin/master $sha
PS D:\repros\missing-remote-refs-6396> git rev-parse refs/remotes/origin/master
3da03f0e27334cb9898a80118db9d44190957f54
PS D:\repros\missing-remote-refs-6396>

(The internal file exists, but as I said, that's an implementation detail that is subject to change, and not part of the public contract.)（该内部文件确实存在，但正如我所说，这只是实现上的细节，可能会发生变化，并不属于公开承诺的一部分。）

@dscho — thank you for looking at this directly.

You're absolutely right that loose refs are an implementation detail and that one shouldn't rely on the file existing (e.g. under reftable there is none). My repro script's Test-Path line was only a quick tell; it is not the bug. The defect is observable entirely through Git's own reference-database contract, independent of storage backend:

# git 2.55.0.windows.3 (affected PortableGit build, commit 52ca1113)
$ git update-ref   refs/remotes/origin/master <sha>  ; echo $?   -> 0
$ git rev-parse    refs/remotes/origin/master          -> fatal: unknown revision (exit 128)
$ git show-ref     refs/remotes/origin/master          -> not found (exit 1)
$ git for-each-ref refs/remotes/origin/master          -> empty

After update-ref reports success, Git itself cannot resolve the ref it just wrote — rev-parse/show-ref don't care whether the ref is loose, packed, or reftable, and they still fail. So this is a silent ref-database integrity regression between 2.45.2 and 2.55.0, not an observation about file layout.

Control on the SAME machine, system Git 2.45.2.windows.1:
$ git rev-parse refs/remotes/origin/master -> (exit 0)

On provenance: the affected binary is the official PortableGit 2.55.0.windows.3 (commit 52ca111), Authenticode-signed by Johannes Schindelin — it is the stock build shipped by Git for Windows, not modified by the bundling application. The same loss reproduces in a plain PowerShell context (no app launcher in PATH), so it is not a wrapper artifact.

To help pin it down, I'm happy to:

• reproduce with an official setup.exe install of 2.55.0.windows.3 (not the portable build) to rule out any packaging difference;
• capture GIT_TRACE2=1 for the ref-transaction subsystem;
• test with Windows Defender real-time protection disabled (early evidence suggests a filter-driver interaction, since 2.45.2 is unaffected on the same box).

Just say the word on which would be most useful.

[XLF66666]

@dscho — update with a decisive data point. I temporarily disabled Windows Defender real-time protection and re-ran the exact same update-ref + rev-parse sequence on git 2.55.0.windows.3:

# Defender real-time protection: DISABLED
$ git update-ref   refs/remotes/origin/master <sha>  ; echo $?   -> 0
$ git rev-parse    refs/remotes/origin/master          -> 22088cc3686471eb9e4815d3dbee49100981304b  (exit 0)

So with real-time protection off, the ref writes and resolves correctly. With it on (the default), the same write is silently rolled back (rev-parse -> unknown revision, exit 128). Same machine, same repo, same git binary — the only variable is Defender real-time protection.

This localizes it to an interaction between git 2.55's ref-write transaction and Defender's real-time file filter: git 2.45.2 on the same machine is unaffected, so it's a regression introduced in 2.55's I/O path (not a standalone Defender defect — Defender didn't change, git did). That matches the historical pattern you all fixed before with the stdout-buffering / filter-driver issue.

Real-time protection was re-enabled immediately after the test (verified RealTimeProtectionEnabled = True).

Next most useful step from my side: I can (a) capture GIT_TRACE2=1 for the ref-transaction subsystem to see exactly where the write is dropped, or (b) reproduce with an official setup.exe install of 2.55.0.windows.3 to rule out the portable packaging.

[dscho]

Hmm. The only course of action that would help pin this down further that comes to mind would be a highly tedious one: bisect Git itself. For that, as a first test, v2.55.0 (i.e. without .windows.3) should be built in a Git for Windows SDK to verify that this code pattern with which Defender seems to have problems is already present in upstream Git. Once that is established, a proper git bisect should be run. As I said, though, this would require a high effort to see through.

[XLF66666]

Thanks for actually running it — that's useful.

I grabbed 2.55.0.windows.5 (MinGit) since that's what you tested, and it fails here:

2.55.0.windows.3   FAIL 3/3
2.55.0.windows.4   FAIL 3/3
2.55.0.windows.5   FAIL 3/3    <- the build you tested

So it isn't the version, and it isn't portable-vs-installed either — same binary, different outcome on two machines. Given the earlier result (real-time protection off => the ref resolves fine, on => silently lost), that smells like your environment rather than the build.

Would you mind checking what this says on your box?

Get-MpComputerStatus | select RealTimeProtectionEnabled

If it's off, or you're on a different AV, that would explain it. It would also mean this only bites machines with a resident filter driver — which is most Windows desktops.

In the meantime I ran a binary search over the released MinGit builds, real-time protection on throughout, 5 runs per build near the boundary to make sure it wasn't intermittent:

2.45.2.windows.1  (system install, control)   PASS 5/5
2.50.0.windows.1                              PASS 5/5
2.50.1.windows.1                              PASS 3/3
2.51.0.windows.1                              FAIL 5/5
2.55.0.windows.3  (control)                   FAIL 5/5

There's nothing in between I could test — 2.50.2 and 2.48.0 don't exist as releases. So the range is v2.50.1..v2.51.0.

One wrinkle for the actual bisect though: if your machine doesn't have the trigger, every commit will come back good. I can't build here (no SDK), but I can run binaries quickly — so if you can point me at SDK builds, or the pure upstream 2.55.0 you mentioned, I'll test each one and report PASS/FAIL. Happy to be the machine with the antivirus switched on.

[rimrul]

We could look through the snapshot builds to narrow down the range.

2.50.0 should correspond to one of the "Mon, Jun 16, 2025, 07:26:56 PM GMT" snapshots. IDK why there are 2, though.

2.50.1 seems to have been an embargoed release, thus no snapshot.

2.51.0 should correspond to the "Tue, Aug 19, 2025, 08:17:25 AM GMT" snapshot.

[dscho]

Would you mind checking what this says on your box?

Get-MpComputerStatus | select RealTimeProtectionEnabled

PS C:\Windows\system32> Get-MpComputerStatus | select RealTimeProtectionEnabled

RealTimeProtectionEnabled
-------------------------
                     True

2.50.0 should correspond to one of the "Mon, Jun 16, 2025, 07:26:56 PM GMT" snapshots. IDK why there are 2, though.

I sometimes build extra snapshots when deploying somewhat "interesting" updates to, say, the MSYS2 runtime.

[XLF66666]

Two corrections before the new bit, both mine.

First: the AV guess was wrong. Yours is True, mine is True. Sorry about that one.

Second: my earlier harness was broken in ways that made some of my numbers garbage, so
please ignore the per-build counts in my previous comments. Two separate defects: I was
reading $? after local x=$(...), which returns local's status (always 0), so failed
updates scored as successes; and in one of the shells I was using the .exe never actually
started, and a binary that didn't run got scored as a failure. Redone from bash, with a
checker that only accepts a 40-hex sha out of rev-parse, and with a fresh directory per
case because rm -rf silently no-ops here often enough to poison a sequence.

So, what is actually happening. The ref is not lost. It gets created and then rolled back.

I polled with bash builtins while update-ref ran, so I'm sampling a few thousand times a
second instead of shelling out to ls once a second:

ref                                     result   seen during   present after
refs/heads/q            (0 new dirs)      P          yes           yes
refs/remotes/master     (1 new dir)       P          yes           yes
refs/remotes/origin/master (2 new)        F          yes           no     <- rolled back
refs/aa/bb/cc           (3 new dirs)      F          yes           no     <- rolled back

update-ref exits 0 in all four rows. In the two failing ones the loose ref genuinely gets
written — I watched .git/refs/remotes/origin/master come into existence — and then it's
gone again, along with the origin directory git had just created.

And the rollback is incomplete:

.git/logs/refs/remotes/origin/master     <- still there, for the ref that isn't

So update-ref removes the ref, leaves the reflog behind, and reports success. That reads
like the transaction hitting an error after the rename, unwinding, and losing the error
on the way out.

The threshold is the part I'd most like a second opinion on. Zero or one new directory
level under .git/refs is fine; two or more rolls back. Which is unfortunate, because
refs/remotes/<remote>/<branch> needs exactly two — so this lands precisely on
remote-tracking refs and leaves refs/heads/* alone. That matches the original symptom:
after a clone or fetch the remote-tracking refs are gone and local branches are fine.

Versions, redone (3 runs each, fresh directory per run, all under Documents):

2.50.0.windows.1   PPP
2.50.1.windows.1   PPP
2.51.0.windows.1   FFF
2.55.0.windows.5   FFF

Same window as before: (v2.50.1, v2.51.0].

Now the part I still can't explain, and I think it's why you can't see it. On this machine
the rollback fires in every directory except %TEMP%. I ran them interleaved so drift
couldn't account for it:

round 1   TEMP=P   DOCUMENTS=F
round 2   TEMP=P   DOCUMENTS=F
round 3   TEMP=P   DOCUMENTS=F

TEMP is a real directory here, not a junction. Its next-door neighbour Temp2 — which I
created just to check it wasn't an AppData\Local thing — fails, and so do Desktop,
Documents, Downloads, AppData\Local and D:. Same binary, same command, same volume,
a few hundred milliseconds apart.

Things I ruled out, so nobody has to redo them: mkdir and rename of 60 nested directories
and 60 files succeed in all of those locations with identical timings; creating 100 files
takes ~100ms in all of them, so it isn't a throughput effect; the git configs are
byte-identical between the passing and failing repos, no includeIf anywhere; no stray
parent .git; core.fscache, core.untrackedCache and core.preloadindex make no difference;
and running outside my command sandbox makes no difference either. So the difference is
not the filesystem primitives and not the configuration — it's whatever makes git's
transaction decide to unwind.

I can't read the exclusion list (not an admin on this account — Get-MpPreference refuses
and MpCmdRun -CheckExclusion returns 0x80070005), so "TEMP is excluded from scanning" is
still only my best guess, not something I've shown.

Given that, here's the thing to run, since it doesn't depend on the trigger firing at all:

git init -q . && git commit -q --allow-empty -m x
for r in refs/heads/q refs/remotes/master refs/remotes/origin/master refs/aa/bb/cc; do
  git update-ref $r HEAD
  printf '%-30s rc=%s ' "$r" "$?"
  git rev-parse --verify -q $r >/dev/null && echo OK || echo GONE
done

If you get OK OK GONE GONE, you have the same bug and the location business is incidental.
If you get four OKs, the rollback never fires for you, and then the interesting question
is what is different about this machine.

If it does fire for you, I'd start in the files-backend transaction: the ref is written
and then removed, the reflog survives, the error doesn't, and the trigger is needing two
new directory levels instead of one.

@rimrul — thanks. With the window down to one release I don't think snapshots buy much
unless you want to hunt inside it, but I'm happy to run whatever you or dscho build.

[XLF66666]

@dscho — I think I can now say why you can't see this, and it comes down to one
variable I can't control for from here.

You ran it in D:\repros and got four OKs. On this machine D:\ fails, with the
same binary (2.55.0.windows.5) and the same commands. So the difference isn't the
path — it's the machine.

The trigger here needs both halves:

• git 2.55's ref-write transaction — the window is (v2.50.1, v2.51.0]; and
• an AV real-time filter driver sitting on the I/O path

Remove either one and it passes. For the first half I have four builds and a clean
boundary. For the second half I only have one data point: on this box every directory
fails except %TEMP%, and I can't read the exclusion list to confirm why (not an
admin — Get-MpPreference refuses, MpCmdRun -CheckExclusion returns 0x80070005).

So the question I actually need answered is about your machine, not mine.
If real-time protection is off there, or D:\repros is excluded, that fully explains
the non-reproduction — and it would make "AV filter present" a necessary condition
rather than a coincidence I keep pointing at.

Would you mind running these two where you did the test?

(Get-MpComputerStatus).RealTimeProtectionEnabled
& "$env:ProgramFiles\Windows Defender\MpCmdRun.exe" -CheckExclusion -path D:\repros

(The second one doesn't need admin, unlike Get-MpPreference.)

If real-time protection is on and D:\repros is not excluded, then my two-halves
model is wrong and I'll drop the AV thread entirely — the directory-levels threshold
is the part I'd still stand behind, since that one I can reproduce at will.

And to be explicit about your implementation-detail point, because it's the fair
criticism: you're right, and the check I'm proposing doesn't depend on it. The judge
is git rev-parse --verify -q, which is the public ref-database contract — not
Test-Path on a loose ref file. The loose ref only comes in as evidence about
where in the transaction the unwind happens, not as the bug itself. My original
repro script leaned on Test-Path and that was my mistake.

For reference, the four-line version:

git init -q . && git -c user.email=t@t -c user.name=t commit -q --allow-empty -m x
for r in refs/heads/q refs/remotes/master refs/remotes/origin/master refs/aa/bb/cc; do
  git update-ref $r HEAD
  printf '%-32s rc=%d ' "$r" "$?"
  git rev-parse --verify -q $r >/dev/null && echo OK || echo GONE
done

OK OK GONE GONE here, in Documents, Desktop, Downloads, AppData\Local and D:.
Four OKs in %TEMP%. If you get four OKs everywhere, the machine is the variable.