[Bug]: Windows 0.0.28/nightly local backend appears disconnected; server.getConfig interrupted, 0.0.27 works

[SivanTechDev]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. On Windows 11, install T3 Code desktop 0.0.28 using winget.
2. Open the desktop app.
3. Try to add a local project, for example C:\Users\<user>\code\test.
4. The app shows an error that the local machine is not connected.
5. Uninstall 0.0.28 and install T3 Code desktop 0.0.27.
6. Repeat the same flow with the same local project.
7. In 0.0.27, the project is added normally.

Expected behavior

The desktop app should connect to the local backend and allow adding or opening the selected local project.

Actual behavior

In T3 Code desktop 0.0.28, the app opens but does not properly connect to the local machine.

Observed behavior:

• Previously opened project history does not load.
• The configured provider does not appear to load.
• Adding a local project fails with a message like:

<machine-name> is not connected.

The same machine, same project, and same provider setup work correctly after downgrading to T3 Code desktop 0.0.27.

I also see repeated DevTools CORS errors for https://api.axiom.co/v1/traces, but those appear to be telemetry related and may not be the main cause.

Impact

Major degradation or frequent failure

Version or commit

No response

Environment

OS: Windows 11 Desktop app: T3 Code 0.0.28 Install method: winget Working previous version: T3 Code 0.0.27 PowerShell 7: pwsh.exe, version 7.6.3 Windows PowerShell 5.1: powershell.exe Provider: Codex

Logs or stack traces

A/B check between 0.0.27 and 0.0.28 on the same Windows machine and same local project.

0.0.27:
Process diagnostics can time out, but the app still works and server config succeeds.

Relevant 0.0.27 trace:

runProcess
  exit: Failure
  cause: ProcessDiagnosticsError: Failed to query process diagnostics. timed out.

ws.rpc.server.getConfig
  exit: Success

0.0.28:
The same workflow fails. The UI reports that the local machine is not connected.

Relevant 0.0.28 trace:

runProcess
  exit: Failure
  cause: ProcessDiagnosticsQueryTimeoutError: Process diagnostics query 'powershell.exe' timed out after 1000ms

shell.resolveCommandPath
  exit: Failure
  cause: CommandResolutionError

shell.resolveCommandPathForPlatform
  exit: Failure
  cause: CommandResolutionError

externalLauncher.resolveAvailableCommand
  exit: Interrupted

externalLauncher.buildAvailableEditors
  exit: Interrupted

externalLauncher.resolveAvailableEditors
  exit: Interrupted

ws.rpc.server.getConfig
  exit: Interrupted
  cause: InterruptError: All fibers interrupted without error

Conclusion:
The PowerShell/process diagnostics timeout is not new by itself. In 0.0.27 it is tolerated and the app works. In 0.0.28 it appears to become fatal to config/editor discovery, causing the desktop app to report that the local machine is disconnected.

Screenshots, recordings, or supporting files

No response

Workaround

Downgrade to T3 Code desktop 0.0.27. The same local project opens correctly in 0.0.27.

[SivanTechDev]

I reproduced the issue with npx -y t3@nightly, so this does not appear to be only an Electron packaging issue.

The server starts successfully:

• migrations complete
• server listens on http://127.0.0.1:3773
• pairing URL is generated

Provider environment:

• Node: v26.4.0
• npm: 11.18.0
• codex --version: codex-cli 0.142.4
• where.exe codex finds:
  • C:\Users\<user>\AppData\Roaming\npm\codex
  • C:\Users\<user>\AppData\Roaming\npm\codex.cmd

Focused failure chain from the nightly server trace:

ProcessDiagnosticsQueryTimeoutError:
Process diagnostics query 'powershell.exe' timed out after 1000ms in 'C:\Users<user>'.

Then command/editor discovery becomes slow or interrupted:

shell.resolveCommandPathForPlatform
exit: Failure
cause: CommandResolutionError

shell.resolveCommandPath
exit: Failure
cause: CommandResolutionError

externalLauncher.resolveAvailableCommand
exit: Interrupted

externalLauncher.buildAvailableEditors
exit: Interrupted

externalLauncher.resolveAvailableEditors
exit: Interrupted

Finally config loading is interrupted:

ws.rpc.server.getConfig
exit: Interrupted
cause: InterruptError: All fibers interrupted without error

This matches the UI behavior: prior history/provider/local-machine state does not load, and the app reports that the local machine is disconnected.

Important comparison:
On 0.0.27, process diagnostics can also time out, but ws.rpc.server.getConfig succeeds and the app works. On 0.0.28/nightly, the same class of timeout appears to become fatal to config/editor discovery.

[SivanTechDev]

Additional isolation result.

Nightly is still unusable for me, including via the CLI/nightly path, which is why I dug into diagnostics and startup/config behavior.

I now think the direct connection failure is not the PowerShell diagnostics timeout itself. The diagnostics timeout is real, but the more direct issue is that server.getConfig depends synchronously on optional editor discovery.

Current path:

• apps/server/src/ws.ts

  • loadServerConfig
  • includes availableEditors: yield* externalLauncher.resolveAvailableEditors()

Local test:

If I patch buildAvailableEditors in apps/server/src/process/externalLauncher.ts to immediately return:

return ["file-manager"];

then:

ws.rpc.server.getConfig: Success
duration: ~1.5 ms

So server.getConfig should probably not block on editor discovery. Editor discovery should be lazy, cached, timeout-bounded, or allowed to fall back.

This looks like the same reliability class as #3611: startup/preflight accepts a problematic local environment, then the app gets stuck instead of degrading gracefully or showing a recoverable error.

The diagnostics issue is still worth fixing separately. Current Windows diagnostics use an N+1 CIM pattern:

Get-CimInstance Win32_Process | ForEach-Object {
  Get-CimInstance Win32_PerfFormattedData_PerfProc_Process -Filter "IDProcess = $($_.ProcessId)"
}

On my machine:

Get-CimInstance Win32_Process: ~380 ms
Get-CimInstance Win32_PerfFormattedData_PerfProc_Process: ~645 ms
Current per-process diagnostics shape: times out
Two-query bulk shape: ~866 ms

Suggested fixes:

• Do not let editor discovery interrupt server.getConfig
• Keep diagnostics isolated/non-fatal during startup/config
• Replace the Windows diagnostics N+1 CIM query with a bulk query plus join
• Consider raising the diagnostics timeout above 1000 ms

This matters because slower WMI/CIM, many processes, endpoint protection, WindowsApps shims, roaming profiles, or unusual PATH/PATHEXT are normal Windows/enterprise conditions. Optional discovery and diagnostics should not make the local backend appear disconnected.

[gazzetta]

Environment

• Windows 11, x64
• Host name shown as Gazza-Desktop
• Official desktop: broken since 0.0.28 with:
  … did not respond during connection setup / reconnect banner
• 0.0.27 works as a workaround
• Latest tested base: 0.0.29-nightly.20260716.824 + cherry-picked PR fix(server): speed up Windows diagnostics and editor discovery #3911

What we measured

Stock 0.0.28 / nightlies:

• ws.rpc.server.getConfig often ~15s then Interrupted while stuck in
  externalLauncher.resolveAvailableEditors → shell.resolveCommandPath /
  shell.isExecutableFile
• Client CONNECTION_ESTABLISHMENT_TIMEOUT is 15s
  (packages/client-runtime/src/connection/supervisor.ts)
  → UI: “did not respond during connection setup”

With only PR #3911 applied on top of latest nightly:

• getConfig usually Success, but still often ~8–17s
• Still races the 15s setup timeout on this machine
• Matches the PR note that Windows sync FS can block the event loop so
  Effect.timeout on editor discovery may not fully preempt work

What actually made connect reliable (local only)

1. Skip editor discovery in loadServerConfig:
   availableEditors: [] instead of withEditorDiscoveryTimeout(resolveAvailableEditors())
   → getConfig dropped to ~2ms Success
2. (Optional safety) raise setup/probe timeout 15s → 45s

So #3911 is directionally correct and necessary, but not sufficient on this
Windows host unless editor discovery is non-blocking in practice (or skipped /
hard-capped without sync PATH walks).

Happy to provide more log excerpts from
%USERPROFILE%\.t3\userdata\logs\server.trace.ndjson if useful.

Related symptom issue: #3746

[maria-rcks]

Also reproducible on macOS 27 arm64 with nightly .877.

getConfig is interrupted after ~14.5s because resolveAvailableEditors consumes nearly the entire 15s connection timeout. This
causes a permanent reconnect loop.

Looks like the same root cause as #3911, but it’s cross-platform.