feat(web): reveal chat file chips in the system file manager#7140

🟠 High

https://github.com/pingdotgg/t3code/blob/56c6aba15a41487991c002f5a24bcdd7265c6a10/apps/web/src/components/ChatMarkdown.tsx#L1405

revealFileInFileManager and the reveal capability label use the globally active environmentId, so a file chip rendered for a thread on another environment sends the reveal RPC to the wrong server and presents that server’s platform label. Derive the effective environment from threadRef?.environmentId first, while still calling useActiveEnvironmentId() unconditionally to satisfy the Rules of Hooks.

✅ Resolved in 3f25c284b6906dc1ffce04fa063cb087dfc1146d

Windows reveal breaks with spaces

Medium Severity

Windows reveal builds a single /select,${path} argument without quoting the path or enabling verbatim Windows spawn args. Through Node’s default argument escaping, explorer.exe often fails to parse paths that contain spaces and silently opens Documents instead of selecting the file. Spawn still succeeds, so the client shows no error toast.

^{Reviewed by Cursor Bugbot for commit 3f25c284b6906dc1ffce04fa063cb087dfc1146d. Configure here.}

Fixed in 9760c9fd4 — the Windows reveal now goes through Windows PowerShell 5.1's Start-Process with a verbatim argument string (the same pattern this file already uses for Windows browser launches), so explorer receives /select,"<path>" with only the path quoted and paths with spaces select correctly.

WSL reveal kind ignores Explorer command

Medium Severity

When WSL has explorer.exe but not interop PowerShell, and WSLg’s xdg-open is usable, fileManagerRevealKindForPlatform advertises files while resolveUsableFileManagerCommand still returns explorer.exe. Reveal then opens the parent folder in File Explorer, so the menu says Reveal in Files but the action never uses the Linux file manager that kind was chosen for.

^{Reviewed by Cursor Bugbot for commit 7f9f72a0061d9c63b5d2a107c9e1d156272e4b53. Configure here.}

components/ChatMarkdown.tsx:1459

The file-manager wording here comes from navigator.platform (the viewing machine), but the menu item's RPC runs on environmentId's server — the same environment whose config drives revealInFileManagerLabel two lines below. When the preferred editor resolves to file-manager (the only editor a file-manager-only host advertises, or a previously persisted choice), a Mac client browsing a Linux environment renders "Open in Finder" directly above "Reveal in Files", naming a file manager the target machine does not have.

Consider keying the file-manager name off the environment's reported OS instead — e.g. an OS-keyed variant in editorLabels.ts next to revealInFileExplorerLabelForOs, fed from serverConfig.environment.platform.os (and falling back to the generic label when serverConfig is null). The other editor names are OS-independent, so they can keep using the current helper.

No longer relevant as of 201b21afb073f1858bd2f30b8e3d3bb9453c9a4c

Open label uses client platform

Medium Severity

preferredEditorMenuLabel builds the file-chip open item with navigator.platform, but openInPreferredEditor runs on the bound environment via RPC. When the preferred editor is file-manager and the client OS differs from the server (or WSL advertises Explorer), the menu can say Finder while the same menu’s reveal item correctly says Files, and the open action hits the server’s file manager.

^{Reviewed by Cursor Bugbot for commit 3e24ad7606a4d56d224d963d8e06e9ec45a3dd08. Configure here.}

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Use the target environment platform for the file-manager label.

When "file-manager" is preferred, a macOS browser that renders a Linux environment shows Open in Finder at Line 1459. useOpenInPreferredEditor then sends the "file-manager" action to the Linux environmentId. Derive this label from the same server configuration used for the action, including the server-selected reveal kind when available. Add coverage where browser and target-environment platforms differ.

As per coding guidelines, “Capability gating, action dispatch, and user-facing labels must all read from the same environment's server config that the action will execute against.”

Source: Coding guidelines

✅ Addressed in commit 201b21a

🟠 High components/ChatMarkdown.tsx:1659

For bare filenames such as ChatView.tsx, “Reveal” sends the unresolved <cwd>/ChatView.tsx path to the file manager, even when the file actually lives at src/ChatView.tsx; the normal panel-open path performs a workspace lookup and opens the correct file. Make the reveal action use that same basename lookup or share the resolved path before calling revealFileInFileManager.

✅ Resolved in f128de8a7144aa10dd95cdf1fa64840d7de2a713

WSL open label mismatches Explorer

Medium Severity

On WSL, plain file-manager open still prefers explorer.exe whenever that bridge exists, but the chat chip open label is derived from shellRevealInFileManagerKind or the Linux OS fallback. When PowerShell is missing (kind files) or reveal is not advertised, the menu can say Open in Files while the RPC still launches File Explorer, so the label and the action disagree.

^{Reviewed by Cursor Bugbot for commit 965756caaf6e52a7e1a45fa7c6aa774cc54b5308. Configure here.}

Reveal probe can stall config

Medium Severity

loadServerConfig wraps editor and remote-open discovery in a 5s timeout, but resolveFileManagerRevealKind runs afterward with no cap. On WSL hosts that fall back to the Linux file manager, that path re-runs the xdg-mime probe (up to 2s) on every config load even when the editor list is served from cache, so server.getConfig / config subscriptions can exceed the discovery budget the rest of this change protects.

^{Reviewed by Cursor Bugbot for commit c46b39a0308341bac6e61a471beafeb8ad54a45d. Configure here.}

components/ChatMarkdown.tsx:1769

Dropping onOpen for non-local-exec environments leaves the chip with no click handler at all on surfaces that lack the panel fallback: handleOpenInFilePreview forwards to handleOpenInEditor whenever threadRef or workspaceRelativePath is missing, and that now returns early when onOpen is undefined. So a chip in a pull request panel (never has threadRef) or a non-workspace absolute path in a thread renders with the full link affordance (anchor, hover, path tooltip) and does nothing when clicked, with no toast — previously it at least reported a failure.

Elsewhere the app keeps this action working for remote environments instead of removing it: OpenInPicker routes remote-links through buildRemoteOpenUrl + openRemoteEditorUrl and only disables the control for remote-unavailable. Consider gating just onReveal (which genuinely needs a local server-side file manager) on canUseShellActions and sending onOpen through the same remote-links deep-link path, or at minimum surfacing a failure toast, so the chip never presents itself as clickable while doing nothing.

No longer relevant as of 216c39be06621dbcd6fc1647676f6390245fdf1b

components/ChatMarkdown.tsx:1479

canOpenInPanel tests workspaceRelativePath !== null, but handleOpenInFilePreview (line 1291) bails on any falsy value and forwards to handleOpenInEditor, which now returns early when onOpen is undefined. A workspace-root link written with a trailing separator (e.g. [repo](/workspace/repo/)) yields workspaceRelativePath === "", so on a surface where the shell actions are suppressed (non-local-exec environment) the chip still renders the full link affordance — anchor, cursor-pointer, hover background — and clicking it does nothing. Consider matching the guard used by the click path so those chips fall into the non-interactive <span> branch.

No longer relevant as of 177bd32a45ffffdf096997baaf2591fcdf2dd14d

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Keep file path copy actions keyboard accessible.

When no primary action exists, this branch renders a non-focusable span. The context menu is then the only way to copy paths. Keyboard-only users cannot focus the chip and invoke that menu. Provide a focusable, accessible menu trigger for this branch.

✅ Addressed in commits 216c39b to 063b398

components/ChatMarkdown.tsx:1540

Now that onOpen is optional, this fall-through can leave the chip inert. For an .html/.htm link (so onOpenInBrowser is defined) whose workspaceRelativePath is null — an absolute path outside the workspace — in an environment where shell actions are suppressed: onOpen is undefined, this branch is skipped because only .pdf opens in the browser by default, and handleOpenInFilePreview forwards to handleOpenInEditor, which now returns early. hasPrimaryAction is still true, so the chip renders the full link affordance (anchor, cursor-pointer, hover, focus ring, path tooltip) and activation — mouse or keyboard — does nothing.

Consider letting the browser action take the click when it is the only primary action available:

No longer relevant as of ba1b4435e0bd8007122fef5856f9ed252c9c3fd3

src/editorLabels.ts:12

This re-implements getLocalFileManagerName(platform), which already lives in ~/lib/utils — the same module this file imports isMacPlatform/isWindowsPlatform from. Keeping two copies of the Finder/Explorer/Files wording means a future change (e.g. "File Explorer" on Windows) can land in one and not the other.

Suggest replacing the body with return getLocalFileManagerName(platform); and importing that helper instead of the two platform predicates.

No longer relevant as of ba1b4435e0bd8007122fef5856f9ed252c9c3fd3

components/ChatMarkdown.tsx:1578

The chip is rendered with selectable, but Chromium/WebKit UA stylesheets apply -webkit-user-select: none to button, so this fallback chip's label cannot be selected or dragged from, unlike the <a> branch and the surrounding markdown prose. That matters here because .chat-markdown's copy handler works from a DOM selection over the prose, so the chip visually drops out of a paragraph selection in this surface.

Suggest restoring the selection behavior at the call site:

No longer relevant as of 81058beca8251f73d4e191520819707e911c7838

Shell actions miss known environment

Medium Severity

ChatMarkdown now resolves shell scope only from threadRef or an explicit environmentId prop, with no other fallback. Pull request surfaces were updated to pass that prop, but ProposedPlanCard and MessagesTimeline still omit it even though they already have the owning environment. When threadRef is absent, open and reveal stay hidden despite a known local-exec environment.

^{Reviewed by Cursor Bugbot for commit d7ad5d143f194a2458eda1b21b9b2816913af327. Configure here.}