Feature: give plugins a seam for the chat link context menu

[xiaoliuzhuan666]

Problem

There is no extension point for the context menu of a link in the chat, so a
plugin cannot offer "Reveal in Finder" / "Copy file path" on a file mention.

Two things block it, and both are structural rather than bugs:

1. The Electron main-process menu never sees the link.
app/lib/main.js builds the menu from webContents.on("context-menu", params => …)
and reads only isEditable and selectionText:

window.webContents.on("context-menu", (_event, { isEditable, selectionText, editFlags }) => {
  const items = [];
  if (isEditable) items.push(/* undo/cut/copy/paste/selectAll */);
  else if (selectionText.length > 0) items.push({ role: "copy", … });
  …
});

params.linkURL is never consulted — and even if it were, it would be empty
for dsh's file mentions.

2. File mentions are not anchors.
ui-chat renders a file reference as a <button>, not <a href>:

// dsh-client-ui-chat / ui-tool ToolRow
<button type="button" className={css.fileLink} onClick={openFile}>
  {summaryText}
</button>

Chromium only fills linkURL for real <a href> elements, so the main process
sees "" on every file mention. Verified in DevTools: right-clicking a file
mention reports {"linkURL":"","selectionText":"…","isEditable":false}, and
document.elementFromPoint(x, y) returns CODE < BUTTON < P < DIV.

Scrollback makes it worse: the click handler closes over openFile, which
knows the path, but the path never reaches the DOM, so nothing outside the
component can read it.

What a plugin has to do today

To get a working reveal, four separate edits are needed, two of them inside
the shipped app:

1. patch dsh-web-frontend/dist/assets/index-*.js to stamp
   data-dsh-file-path / data-dsh-file-abs on the rendered button;
2. patch dsh-client-ui-chat so the markdown delegate context carries cwd
   (a relative path is rejected by the Host — see below);
3. patch app/lib/main.js because setWindowOpenHandler(() => ({action:"deny"}))
   silently swallows every window.open, which is how a chat link opens a URL;
4. write a client plugin that listens for contextmenu and calls
   remote.session.openWorkspacePath({ path, action: "reveal" }).

Step 4 alone is right; steps 1–3 exist because there is no seam.

Proposal

Expose the link data a plugin needs, in the layer that already has it.

a. Stamp the path on the rendered element.

<button
  data-dsh-file-path={path}          // as displayed (may be relative)
  data-dsh-file-abs={absolutePath}   // workspace-resolved
  onClick={openFile}
>

<a href> for external links is already fine — linkURL works there.

b. Add a context-menu extension point.

Either of these is enough:

• a slots seat, e.g. conversation.link.contextMenu, rendered with the
  clicked link's descriptor ({ kind: "file" | "url", path?, href?, sessionId });
• or a Host Remote call a plugin can make on context-menu, for the case where
  the plugin owns the whole menu.

c. Fix setWindowOpenHandler in app/lib/main.js.

contents.setWindowOpenHandler(({ url }) => {
  try {
    const u = new URL(url);
    if ((u.protocol === "https:" || u.protocol === "http:") && !u.username && !u.password)
      shell.openExternal(url).catch(() => {});
  } catch {}
  return { action: "deny" };
});

A deny-only handler makes every chat link dead with no error and no log. The
WebContentsView handler a few hundred lines above already does this
correctly, so this looks like an oversight rather than a policy.

One more thing the docs could state

session.openWorkspacePath({ path }) requires an absolute path:

// dsh-api-session-controller
async verifyDesktopPath(path, signal) {
  const hostPath = resolve(path);
  const mapped = fs.processPathFromHostPath(hostPath);
  if (mapped === undefined || …) throw new RemoteError("gateway/bad-request",
    "Path has no verified Host path", {});
}

// dsh-fs-local
processPathFromHostPath(hostPath) {
  return isAbsolute(hostPath) ? resolve(hostPath) : undefined;
}

The request field is documented as "Path after best-effort Session workspace
resolution, in Host filesystem syntax", which reads as if a workspace-relative
path would be resolved for you. It is not. The error text is also opaque — a
plugin author sees "Path has no verified Host path" and cannot tell that the
problem is relativity. Suggest either resolving relative paths against the
session root, or naming the reason in the message.

Environment

• dsh 0.2.1-rc.5 (desktop, macOS 26 / arm64)
• The plugin that hit this: a client plugin adding a right-click menu to chat
  links (reveal in Finder, copy path, open in browser, copy link address).
  Happy to share the implementation as a reference.

Alternatives considered

• Main-process only: impossible, linkURL is empty for buttons.
• Selector matching on the rendered class: works but brittle; CSS-module
  class names carry a per-build hash (_fileLink_1ypvv_59).
• Reading the React fiber from the DOM node: works, but relies on React
  internals and would break on a React major.

[xiaoliuzhuan666]

Correction to two claims in the post above

After further investigation I have to retract two things. The core ask (a
plugin seam for the link context menu) still stands, but the evidence I gave
for it was partly wrong, and one of the claims would have sent a maintainer to
the wrong file.

1. The main window already forwards http(s) — I read the wrong handler.

The post says the main window's setWindowOpenHandler is deny-only. It is
not. In 0.2.1-rc.5 the chat window is created by createWindow() and its
handler already does the right thing:

// app/lib/main.js, inside createWindow()
window.webContents.setWindowOpenHandler(({ url }) => {
  if (["http:", "https:"].includes(new URL(url).protocol)) shell.openExternal(url);
  return { action: "deny" };
});

The deny-only handler I quoted is a different call in a different class:

// app/lib/main.js — inside `DesktopPolicyTestAuth`, the login window
contents.setWindowOpenHandler(() => ({ action: "deny" }));

There are seven setWindowOpenHandler calls in main.js. I matched on line
proximity to the context-menu handler instead of finding the enclosing
function, so I attributed the login window's policy to the chat window.

→ Section "c. Fix setWindowOpenHandler" should be dropped. There is no
bug there. Sorry for the noise.

2. A plugin can reach the path and the workspace root without any patch.

The post claims the path "never reaches the DOM". In the shipped bundle the
file-mention button carries it in title:

// baseline dsh-web-frontend/dist/assets/index-*.js — no patch applied
d.jsxs("button", {
  type: "button",
  className: he(St.fileMention, St.fileLink),
  title: l === void 0 ? e.path : void 0,      // ← the path, already rendered
  onClick: () => { i(e.path, ...) },
  children: [...]
})

And a client plugin can read the workspace root off the sessions store:

const rows = ctx.sessions.list.getSnapshot().byId
const cwd = rows?.[sessionId]?.cwd
const abs = path.startsWith("/") ? path : `${cwd.replace(/\/+$/, "")}/${path}`

remote.session.openWorkspacePath({ path: abs, action: "reveal" }) accepts that
absolute path today.

Several plugins already ship exactly this, with no app patch at all —
ltsone9/dsh-filemenu, dengsixue-stack/dsh-file-context-menu,
youshuyuki/dsh-link-context-menu. So proposal (a) "stamp the path on the
rendered element" is a convenience, not a blocker.

What is still missing, and still worth fixing: there is no native
context-menu entry. A plugin has to draw its own popup over shell.overlay
and preventDefault() the real one. That works, but it means every plugin in
this space reimplements a menu, and none of them get the OS-native look. A
conversation.link.contextMenu slot (proposal b) is the part of this
request that has real value.

And one documentation fix that survives: openWorkspacePath's field
comment says "Path after best-effort Session workspace resolution", which
reads as if a relative path would be resolved. It is not —
fs.processPathFromHostPath returns undefined for anything relative, and the
error is just "Path has no verified Host path". Naming the reason would save
plugin authors a debugging round. That part of the post was correct, and I hit
it myself.