Windows inbox ssh-agent 9.5.6.2 remains Running after its named-pipe listener disappears

Environment

• Windows 11 25H2, build 26200.9457; KB5129195 installed 15 September 2026.
• Windows inbox OpenSSH client: file version 9.5.6.2, product version OpenSSH_9.5p2 for Windows.
• Microsoft-signed System32 ssh-agent.exe; signature valid.
• Agent SHA-256: 53ce3461bf894bf420f9097c6fb2d24bda6ce89ed0531aca7139a7336bcfda9f.
• Exact Microsoft public PDB: GUID 92942979-8afc-4deb-bf1a-ba6792826bbd, age 1.
• No alternate OpenSSH installation or preview binary substituted.

Actual versus expected behavior

The agent's named-pipe listener disappears while the same ssh-agent process remains alive and SCM reports Running with zero service exit fields. A bounded ssh-add query returns exit 2. Expected: the agent should retain its listener or fail visibly so its service state accurately reflects availability.

Four recurrences were observed on 18 September 2026. Metadata-only captures showed two waiting threads and 101 handles. One controlled restart after each of the first three failures restored the endpoint and authentication temporarily; the failure returned. No automatic restart loop is configured. Narrow OpenSSH/SCM event queries provided no causal record.

Reproduction and diagnostic limits

There is not yet a deterministic reproduction on the installed binary. Availability checks now enumerate pipe names without opening the agent pipe.

On an unrelated disposable named pipe, PowerShell Test-Path established a client connection. Closing that client before ConnectNamedPipe produced Win32 error 232 (ERROR_NO_DATA). However, 40 sequential queries and four bursts of eight analogous queries against the installed agent did not reproduce its failure. This remains a candidate race, not an established cause.

Offline disassembly of the exact installed binary shows an unexpected-ConnectNamedPipe-error branch: return-site RVA 0x1ac0 obtains the Win32 error, 0x1af9 calls SetEvent, and listener cleanup begins at 0x1dd0. No runtime evidence connects these sites to the observed failures.

No debugger was attached to the real agent. A metadata-only tracing configuration using Microsoft CDB 10.0.26100.9169, -pd and a hardware execution breakpoint passed orderly detach on a disposable fixture but failed abrupt-debugger-termination qualification: the fixture subsequently exited 0x80000004. That configuration was rejected for live use. No process dumps or key inspection were performed.

Requested guidance

Is there a supported correction applicable to this Windows inbox build, or a safe metadata-only way to establish the listener exit branch and Win32 error without dumps, key inspection or persistent instrumentation? If this belongs in a separate Windows servicing channel, please identify the appropriate route.

Related issue #2235 appears to concern client/agent version mismatch; it does not establish the cause of this same-process listener disappearance. A service restart restores availability temporarily but does not resolve the recurrence.

No source file, test, or implementation entry point is identified, and the installed Windows inbox binary has no deterministic reproduction. Start by reviewing the exact build metadata, named-pipe observations, and rejected tracing setup; completion would require supported servicing guidance or safe evidence identifying the listener failure path.