[Bug]: Windows T3 Connect relay client install fails with EBUSY while staging cloudflared #16945

Activity

1. BramTops

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 7, 2026
2. juliusmarminge commented on Oct 7, 2026

   

   juliusmarminge

   on Oct 7, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the ProcMon capture. Triage: confirmed on current main. The installer renames the freshly executed cloudflared.exe once, right after the validation run exits, and nothing retries a transient Windows lock.

   Mechanism (packages/shared/src/relayClient.ts on main):

   1. The download is checksummed in memory, then written to .install-XXXX\cloudflared.exe inside a scoped temp directory (L397-L409).
   2. That same file is run as cloudflared version to validate it (L422-L425). runCommand waits only for the exit code (L263-L278).
   3. The very next step renames that executable to cloudflared.exe.<uuid>.tmp, with a single fileSystem.rename call. Any failure becomes write_failed / "Could not stage the relay client." (L427-L431). The second rename into place has the same single-shot shape (L432-L437).

   So any process still holding the just-run image without delete sharing makes the install fail outright. That matches the SHARING VIOLATION on T3's delete-access open in your log. Your log doesn't show which process held the handle; Defender (MsMpEng.exe) mapping the file just before is a plausible candidate, but it isn't proven. The only retry loop in this installer is for the install lock file (L328-L351), not for the renames. The repo already handles this Windows behaviour elsewhere: the CLI archive smoke test retries cleanup because "Windows can keep t3.exe locked (EBUSY) for a moment" after it exits (scripts/smoke-cli-archive.ts L78-L88).

   This code is unchanged in behaviour since 0.0.45. The only diffs between v0.0.45 and main in this file are Effect import renames and a lint-only catchTags change.

   Fix direction

   • Retry both renames on Windows when they fail with EBUSY/EPERM/EACCES, using a short bounded backoff. The smoke script's Effect.retry with Schedule.spaced is the existing pattern.
   • Or avoid renaming an image that just ran: validate a separate copy, and stage and activate the copy that was never executed.

   Workaround

   t3 connect skips the installer whenever a file already exists at the managed path (resolve, L236-L243; apps/server/src/cli/connect.ts L247-L249). Until this is fixed, you can install the binary by hand:

   1. Download cloudflared-windows-amd64.exe 2026.5.2.
   2. Check that its SHA-256 is 20b9638f685333d623798e733effbad2487093f15ba592f6c7752360ff3b7ab7 (the pinned checksum).
   3. Save it as %USERPROFILE%\.t3\tools\cloudflared\2026.5.2\win32-x64\cloudflared.exe (that's under the default T3 home; use your own base directory instead if you pass --base-dir).
   4. Rerun npx t3 connect.

   You can also point T3CODE_CLOUDFLARED_PATH at that file.

   Related

   • fix(shared): validate cloudflared with the version subcommand #9880 (merged) switched the validation run to cloudflared version. That is the run right before the failing rename, and it was already in 0.0.45.
   • [Bug]: T3 Connect relay client cannot be installed on Windows ARM64 (no win32-arm64 cloudflared asset) #14836, fix(shared): install the relay client on Windows ARM64 #16715 and fix(shared): install the T3 Connect relay client on Windows ARM64 #14840 add a win32-arm64 asset mapping and don't touch staging.
   • fix(connect): Restore the pinned relay client before connecting #16607 (open) restructures these two renames but adds no retry, so a fix here should coordinate with it.
   • [Bug]: T3 Connect managed endpoint provisioning fails for Windows environment #13681 and [Bug]: T3 Connect managed endpoint provisioning fails repeatedly on Windows 11 #14070 were relay-side managed_endpoint_provisioning_failed errors, not install failures. They aren't related.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 7, 2026
4. steverosky commented on Oct 8, 2026

   

   steverosky

   on Oct 8, 2026

   More actions

   Reproduced on Windows 11 Pro with T3 Code (Nightly) desktop 0.0.46-nightly.20261008.2801, using the Settings → Connections toggle rather than npx t3 connect. The managed relay client is 2026.5.2.

   • 11 consecutive attempts, from 01:48 to 03:07 local time, each left a complete .install-*\cloudflared.exe (same SHA-256, valid Cloudflare Authenticode signature). Each attempt then failed with EBUSY: resource busy or locked, rename '...\.install-r1b3um\cloudflared.exe' -> '...\win32-x64\cloudflared.exe.<uuid>.tmp'.
   • Windows Defender real-time protection is the only antivirus. Controlled folder access is off.
   • Manual recovery: Moving one staged copy to win32-x64\cloudflared.exe works. t3 connect status then reports Relay client: available via managed install.
   • Preventing a repeat: Adding a Defender exclusion for %USERPROFILE%\.t3\tools stops it from recurring.

   The Codex CLI 0.161.0 daemon installer failed the same way on this machine. Copying a freshly written binary into its staging folder returned "Access is denied", which also points to Defender holding a transient lock. A short retry on the rename, as proposed above, would cover this case.
5. ScottN-PV commented on Oct 8, 2026

   

   ScottN-PV

   on Oct 8, 2026

   Contributor

   More actions

   Thanks, this fills two gaps in the report. Defender real-time protection is the lock holder, since an exclusion for %USERPROFILE%\.t3\tools stops the failure, and the desktop Settings → Connections toggle hits the same staging rename as npx t3 connect.

   #16998 covers this case: on Windows it retries both renames on EBUSY/EPERM/EACCES for about 10 seconds before reporting the existing error. Its verification held the lock with a PowerShell script, so it has not been run against Defender. A run of the fix on a Defender-only machine would show whether that window is long enough. When a lock outlasts it, the install still fails with the same message and leaves the staged copy under .install-*, as it does today.

   Written by Claude Fable 5.1 on behalf of ScottN-PV.
6. juliusmarminge

   added a commit that references this issue on Oct 8, 2026

   fix(shared): relay client install waits out a brief Windows file lock

   ...

   This issue will close once commit 712926a is merged into the 'main' branch.

   712926a
7. juliusmarminge

   closed this as completedin #16998on Oct 8, 2026