[Bug]: No installed editors found

[Salloxy]

Before submitting

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

Area

Not sure

Steps to reproduce

1. Open the app
2. Can't press the Open button on the top right

Expected behavior

Dropdown shows VS Code, Cursor, Explorer, etc.

Actual behavior

Dropdown shows No installed editors found

Impact

Minor bug or occasional failure

Version or commit

Nightly

Environment

Windows 11 - 0.0.30-nightly.20260728.928

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No workaround found. Did not have this issue previously.

[Lor4th]

also experiencing this on Windows 11 - 0.0.29 stable

[kayotimoteo]

Same problem on Windows 11, version 0.0.30-nightly.20260728.933.

[Salloxy]

Just to add some context, the editors do show up right away but disappear after like 5 seconds.

[Salloxy]

AI authorship disclosure: This investigation and comment were written by OpenAI GPT-5.6-Sol with High reasoning effort, running inside the reporter's affected T3 Code installation, at the reporter's request. The Git history, installed-process environment, editor executables, and relevant implementation were inspected directly. Conclusions and measurements are separated from inferences below.

Executive summary

This appears to be a deterministic regression introduced by PR #4291 / merge commit 6e3b7388 (fix(server): bound editor discovery during config loading).

The change solved one real problem—slow or stuck editor discovery could consume the client's 15-second connection window—but it changed the failure mode to another incorrect one:

editor discovery takes >5 seconds
 -> discovery is interrupted
 -> timeout is converted to []
 -> server.getConfig reports "zero installed editors"
 -> client treats [] as authoritative
 -> Open menu becomes "No installed editors found"

A timeout means “editor discovery did not finish”, not “editor discovery finished and found nothing.” Those states are currently represented by the same value ([]). That is the core correctness bug.

The reporter's observation that editors initially appear and disappear approximately five seconds later is an exact match for the newly introduced Duration.seconds(5) boundary.

Exact regression boundary

I compared the release tags and their commits directly:

Build/tag	Commit	Relevant behavior
v0.0.29-nightly.20260727.922	80ead5f3	Before #4291; awaits resolveAvailableEditors() directly
v0.0.29-nightly.20260727.923	6e3b7388	First build containing the five-second timeout and [] fallback
v0.0.29-nightly.20260727.924	eea3ea4c	Contains the regression
v0.0.29-nightly.20260727.925	1153afb4	Contains the regression
v0.0.29 stable	—	Contains 6e3b7388; consistent with the independent stable 0.0.29 report above
v0.0.30-nightly.20260728.928	a148e081	Contains the regression; did not itself change editor discovery
v0.0.30-nightly.20260728.933	887dd6e4	Contains the regression; independently reported above
v0.0.31-nightly.20260729.942	694f8d1c	Current reporter build; timeout code is still present and git blame points to 6e3b7388

The .925 -> .928 diff only contains mobile OTA settings work plus package-version changes. There is no editor-discovery change in that interval. Therefore .928 was where the reporter first noticed/reported it, but .923 is the exact introducing build.

The editor detector itself is identical between .922 and .923; the behavioral change at the boundary is the wrapper in apps/server/src/ws.ts.

Before (.922)

availableEditors: yield* externalLauncher.resolveAvailableEditors(),

After (.923, still present in .942)

const EDITOR_DISCOVERY_TIMEOUT = Duration.seconds(5);

export const resolveAvailableEditorsForConfig = <A, E, R>(
 discovery: Effect.Effect<ReadonlyArray<A>, E, R>,
) =>
 discovery.pipe(
 Effect.timeoutOption(EDITOR_DISCOVERY_TIMEOUT),
 Effect.map(Option.getOrElse(() => [])),
 );

and:

availableEditors: yield* resolveAvailableEditorsForConfig(
 externalLauncher.resolveAvailableEditors(),
),

The production diff was very small: 12 additions and 1 deletion in ws.ts. The accompanying test added 18 lines.

Why Windows commonly crosses five seconds

The current detector is expensive on a Windows environment with a normal-to-large PATH and PATHEXT:

1. buildAvailableEditors iterates the EDITORS array sequentially.
2. There are 21 UI/editor definitions, with command alternatives such as zed / zeditor, plus the platform file-manager command.
3. For every command, isCommandAvailable calls resolveCommandPath.
4. On Windows, it walks each PATH entry.
5. For commands without extensions, it constructs uppercase and lowercase candidates for each PATHEXT entry.
6. Each candidate is checked with FileSystem.stat through the Effect filesystem service.
7. Missing editors are the expensive case because their entire search space is exhausted before moving to the next editor.

On the reporter's live T3 server process:

• The process had 46 PATH entries.
• PATHEXT had 13 extensions.
• code, cursor, zed, and explorer.exe were all resolvable.
• Installed applications included VS Code 1.130.0, Cursor 3.6.31, Zed 1.3.7, and Notepad++.
• The server process's PATH included the VS Code, Cursor, Zed, and Antigravity CLI directories.
• The command-lookup config correctly handles PATH, Path, and path, so this is not a Windows environment-variable casing problem.

A faithful run of the packaged detector using the app's Electron/Effect filesystem stack found the installed editors correctly when allowed to complete. In the inherited test environment it completed warm in roughly 1.5 seconds, but generated 26,760 filesystem stat attempts. Applying the live server process's actual PATH/PATHEXT shape gives approximately 23,286 candidate stat operations. The exact number varies depending on where a found executable occurs in PATH, but the important point is that this is tens of thousands of filesystem operations executed serially.

Cold filesystem state, Windows Defender/endpoint protection, slower disks, disconnected/network PATH entries, WindowsApps shims, roaming profiles, or general startup I/O can readily push that work over five seconds. This also explains why it may be machine-dependent or intermittent and why warm standalone measurements can complete while cold app startup fails.

PR #4291's own validation predicted this exact regression

The intent of #4291 was valid. Its description explains that editor discovery could consume almost the entire 15-second connection setup window and cause a reconnect loop. However, a Windows validation comment on that PR measured:

Revision	Median discovery time	Result
Base behavior	~9,526.9 ms	4 installed editors
PR #4291 behavior	~5,000.4 ms	[] after timeout

That validation explicitly said:

actual editor discovery takes about 9.5 seconds here, so every PR run used the timeout fallback and the initial config contained no installed editors

So #4291 improved connection latency by intentionally discarding the editor result. This issue is the user-visible consequence of that tradeoff. The connection-safety fix should not simply equate a discovery timeout with a successful empty discovery.

Related history:

• [Bug]: Windows 0.0.28/nightly local backend appears disconnected; server.getConfig interrupted, 0.0.27 works #3610 documents the original Windows startup/config failure caused by synchronous optional editor discovery being on the connection-critical path.
• [Bug]: I keep getting failed to connect. My PC did not respond with a connection setup. It's pretty annoying. Why does it do that. #3746 contains broader connection/reconnect reports, often on Windows and sometimes correlated with Defender or machine load.
• fix(server): bound editor discovery during config loading #4291 was the narrow mitigation for those reports.
• This issue is the regression created by that mitigation's fallback semantics.

Why the exact UI transition makes sense

apps/web/src/components/chat/OpenInPicker.tsx filters its options using the availableEditors array supplied by server config:

const availableEditorSet = new Set(availableEditors);
return baseOptions.filter((option) => availableEditorSet.has(option.value));

When no options remain, it renders:

{options.length === 0 && (
 <MenuItem disabled>No installed editors found</MenuItem>
)}

Therefore, as startup/connection state settles and the server's timed-out config result (availableEditors: []) becomes authoritative, the initially visible editor options disappear. That is why the change happens at the same time the “connecting to desktop” state clears and other server-backed state such as Git status appears.

This is not evidence that the applications were uninstalled during startup. It is a late-arriving false-negative config value replacing the earlier UI state.

What has been ruled out on this reporter's machine

The following likely hypotheses were checked:

• Editors genuinely missing: ruled out; the applications and CLIs are installed.
• CLIs absent from PATH: ruled out; code, cursor, zed, and Explorer resolve, and their CLI directories are present in the T3 server process PATH.
• Electron inherited the wrong environment: ruled out for the relevant commands; the actual running T3 server PID's environment was inspected.
• PATH vs Path casing: ruled out; the lookup configuration reads all three common variants, and a faithful config-provider test returned the expected value.
• Regression introduced specifically by .928: ruled out by Git diff; .928 inherited the behavior from .923.
• Frontend editor filtering bug by itself: the filtering behaves as written; the incorrect input is the authoritative [] sent after a server-side timeout.

Test gap in #4291

The added test verifies only this case:

discovery never resolves
 -> after 5 seconds it is interrupted
 -> result is []

That proves connection loading is bounded, but it also codifies the problematic conflation. It does not test:

• a real discovery that succeeds slightly after five seconds;
• a slow discovery that has already found some editors;
• Windows PATH/PATHEXT cardinality;
• preserving a previously known editor list during refresh;
• the semantic distinction between “completed with zero results” and “timed out”;
• the resulting Open-menu behavior after connection setup.

A focused regression test could use a known installed-editor result delayed past the threshold:

const discovery = Effect.succeed(["vscode", "file-manager"] as const).pipe(
 Effect.delay(Duration.seconds(5.1)),
);

The current implementation returns [], demonstrating the false-negative without relying on a particular host filesystem.

Recommended fix

Best architectural fix

Remove editor discovery from the connection-critical server.getConfig response:

1. Return core config immediately so a stuck detector cannot break connection setup.
2. Represent editor discovery as an explicit state, for example:

type EditorDiscoveryState =
 | { status: "pending"; editors: readonly EditorId[] }
 | { status: "complete"; editors: readonly EditorId[] }
 | { status: "timed-out"; editors: readonly EditorId[] };

3. Run discovery in the background, cached once per environment/server session.
4. Publish the completed editor list through a separate RPC/query/event.
5. Let the client preserve the last known list while discovery is pending or timed out.
6. If discovery fails or times out, show a retryable “Editor detection timed out” state—not “No installed editors found.”

This preserves #4291's important property: optional editor discovery cannot block initial connection.

Detector improvements that should accompany or follow it

• Check editors concurrently with a sensible concurrency limit instead of serially.
• Avoid walking PATH × PATHEXT independently for every missing editor. Build an index of executable filenames in PATH once, or use a platform-appropriate command resolver/cache.
• Cache command-resolution results during a discovery pass and across repeated config requests.
• Consider prioritizing inexpensive/known locations and the file manager.
• Return partial discoveries when a time budget expires instead of discarding everything already found.
• Add timeout/failure instrumentation so traces distinguish complete-empty, partial, timed-out, and failed.

Small emergency options

1. Targeted revert of 6e3b7388: restores editor results and is only about 12 production lines, but reintroduces the original risk that server.getConfig hangs or loses the 15-second connection race. This is useful to confirm causality but is not the ideal final solution.
2. Increase the five-second timeout: probably reduces reports but remains machine-dependent and still conflates timeout with zero installed editors.
3. Preserve prior editors on timeout: a small UI/server mitigation if an existing list is available, but first-launch detection still needs an explicit unknown/timed-out state.
4. Always return at least the platform file manager: improves usability but would hide, rather than solve, the incorrect timeout semantics for real editors.

I recommend preserving the timeout/connection-safety intent while removing [] as the timeout sentinel and moving discovery off the initial config critical path.

Suggested acceptance criteria

• A discovery operation that takes more than five seconds does not prevent the app from connecting.
• The same slow operation does not cause installed editors to be reported as absent.
• No installed editors found is displayed only after discovery completes successfully with zero results.
• Pending, timed-out, and failed discovery are distinguishable from complete-empty discovery.
• Previously discovered editors do not disappear during reconnect/config refresh.
• Windows coverage includes a large PATH/PATHEXT and mostly absent editor commands.
• A never-resolving discovery is interrupted or detached without blocking core config.
• The detector is invoked once/cached rather than repeatedly performing tens of thousands of stats.
• Verified on stable 0.0.29 and Nightly versions containing fix(server): bound editor discovery during config loading #4291.

Bottom line

The direct cause is not a broken Windows installation. It is the fallback added by #4291:

Effect.timeoutOption(Duration.seconds(5))
Effect.map(Option.getOrElse(() => []))

The first line is a reasonable connection-safety boundary. The second line turns an incomplete operation into a false assertion that no editors are installed. Fixing that state-modeling error—and ideally taking discovery off the startup critical path—should resolve this issue without undoing the reliability goal of #4291.

[akj]

AI authorship disclosure: This comment was investigated and written by Claude (Fable 5) running in Claude Code on the reporter's affected machine, at the reporter's request.

Independent confirmation on Windows 11 (10.0.26200), T3 Code (Nightly) 0.0.32 — and the app's own local trace logs capture the failure mechanism directly, span by span.

Span-level capture of the timeout firing

%USERPROFILE%\.t3\userdata\logs\server.trace.ndjson* from a single desktop launch records two externalLauncher.resolveAvailableEditors runs, seconds apart on the same connection:

run	parent	started	duration	outcome
1	ws.rpc.server.getConfig	10:14:22	3,170 ms	Success (editors found)
2	server config subscription snapshot	10:14:25	5,000.3 ms	Interrupted (timeout, reported as [])

Run 2's span, trimmed:

{"name":"externalLauncher.resolveAvailableEditors","durationMs":5000.2958,
 "exit":{"_tag":"Interrupted","cause":"InterruptError: All fibers interrupted without error
 at shell.isExecutableFile (...app.asar/apps/server/dist/bin.mjs:16245)
 at shell.resolveCommandPathForPlatform (...)"}}

That is EDITOR_DISCOVERY_TIMEOUT = Duration.seconds(5) firing mid-stat, exactly as described in the investigation above. (Run 2's parent span never closes because the subscription stream stays open, but apps/server/src/ws.ts has only two call sites for discovery: the server.getConfig RPC and the head-of-stream config snapshot.)

Why editors "show up right away but disappear after like 5 seconds"

The two-run sequence explains @Salloxy's observation precisely:

1. The server.getConfig RPC's discovery finishes (3.2 s here), so the Open menu briefly shows the real editors.
2. The config subscription re-runs discovery for its snapshot and times out at 5 s, so the snapshot arrives with availableEditors: [] and replaces the list.
3. The snapshot is the only delivery of availableEditors on the stream — the live updates that follow cover keybindings/providers/settings only — so the empty list is sticky for the rest of the session, and every reconnect re-races the same 5-second window.

The "Explorer"/"Finder" fallback disappears along with the editors because file-manager goes through the same PATH-scan discovery, and OpenInPicker gates every menu entry (including the file manager) on the same list.

Numbers from this machine (corroborating the measurements above)

• 50 PATH entries, 12 PATHEXT extensions → 24 filename candidates per command → ~23,500 candidate stats for the 21 editors plus the file manager.
• Raw synchronous scan of the identical candidate set: 411 ms, correctly finding Cursor, VS Code, VS Code Insiders, and Explorer.
• The same scan through the repo's actual isCommandAvailable Effect path (packages/shared/src/shell.ts), warm and idle: ~1.9 s.
• The same scan inside the packaged app during connection setup, competing with the rest of startup: 3.2 s and >5 s within one session, three seconds apart.

The installed editors are all detectable in well under a second of filesystem work; whether the user ever sees them comes down to which side of the 5-second line the serialized discovery traversal lands on during connect.

[suhasganga]

Small workaround that fixed this for me on Windows:

I moved the VS Code bin path higher up in my PATH:

C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin

After restarting T3 Code, VS Code showed up correctly.

My PATH is pretty long, so it might be related to the editor detection timing out.