Feature request: chat links that open workspace files in the preview pane

[colin715]

Feature Request: Chat links that open workspace files in the right-side preview pane

Feature Description

Add a supported markdown link format in Hermes WebUI chat messages that opens a workspace file directly in the right-side workspace preview pane.

For example, an assistant could respond with:

[Open product research file](workspace://sample-pantry-product-research-results.md)

or another agreed internal scheme, and clicking the link would call the existing workspace file preview behavior rather than opening the file as a browser attachment/download.

Motivation

Agents often create files in the active workspace, then need to point the user to the result. Today, the assistant can show a path or attach it with MEDIA:/absolute/path, but neither is ideal:

• A plain path is not clickable.
• A MEDIA: attachment opens/renders as an attachment, not in the workspace pane.
• file:// markdown links are rewritten to /api/media?..., which serves the file but does not use the workspace preview pane.

For workflows like client product research, plans, generated reports, markdown summaries, or edited workspace files, the ideal UX is:

1. Agent creates/updates a file in the current workspace.
2. Agent sends a concise clickable link in chat.
3. User clicks the link.
4. Hermes WebUI opens that file in the existing right-side workspace preview pane.

This would reduce friction for non-technical users who do not want to hunt through the file tree.

Current Behavior / Findings

While researching the WebUI code, I found:

• The workspace pane already has an openFile(path) function in static/workspace.js that opens files in the preview pane.
• The file tree calls openFile(item.path) when a file row is clicked.
• The chat markdown renderer supports normal links and supports file:// links, but file:// is rewritten through _markdownHref(...) to api/media?path=...&inline=1.
• There does not appear to be a supported chat link scheme that routes a click to openFile(path).

Proposed Solution

Support a custom internal link scheme for workspace files, such as:

[Open file](workspace://relative/path/to/file.md)

When the user clicks one of these links in a chat message:

1. Prevent default navigation.
2. Decode the relative workspace path.
3. Validate/sanitize the path using the same rules as existing workspace file APIs.
4. Call the existing openFile(path) function.
5. Open/show the workspace panel in preview mode if it is currently closed or hidden.

[nesquena-hermes]

Summary

Reasonable feature and the description has the layout right. The constraint to keep in mind is that the renderer is wholly synchronous and runs on agent-streamed markdown, so the scheme handler needs to coexist with the existing safety pipeline at static/ui.js:3083-3094 (_isSafeUrl) rather than bypass it. The cleanest landing spot is the existing _markdownHref helper at static/ui.js:3072-3082, the same place file:// is rewritten.

Code references

The two link-rendering passes that need updating are at static/ui.js:2963 (the inner table-cell path) and static/ui.js:3056 (the outer paragraph path):

t=t.replace(/\[([^\]]+)\]\(((?:https?:\/\/|file:\/\/|mailto:|tel:)[^\s\)]+)\)/g,
  (_,lb,u)=>{ _link_stash.push(`<a href="${_markdownHref(u)}" target="_blank" rel="noopener">${esc(lb)}</a>`); return ... });

Both regexes whitelist schemes explicitly — workspace: won't even be captured today, so the bracket form falls through and gets HTML-escaped. The streaming path has the same shape at static/messages.js:1055-1077 (_SMD_SAFE_URL_RE + _smdFileHref + _sanitizeSmdLinks). Both pipelines need symmetrical updates or the behaviour will differ depending on whether streaming-markdown was loaded in time.

The target side already exists: static/workspace.js:469 is the openFile(path) you found, and openArtifactPath at static/workspace.js:258-262 is the closest existing parallel — it does the path normalization (replace(/^~\//,'').replace(/^\.\//,'')), forces the panel tab to "files" via switchWorkspacePanelTab('files'), then calls openFile(rel). Reusing that helper is the right move.

Diagnosis / Recommendation

Three coordinated edits:

1. Capture the scheme in both renderer passes (static/ui.js:2963 and :3056) by extending the alternation:

/\[([^\]]+)\]\(((?:https?:\/\/|file:\/\/|workspace:\/\/|mailto:|tel:)[^\s\)]+)\)/g

2. Route workspace:// through _markdownHref at static/ui.js:3072 so it emits a synthetic data- attribute the click handler can spot, e.g.:

function _markdownHref(raw){
  const href=String(raw||'').replace(/"/g,'%22');
  if(/^workspace:\/\//i.test(href)){
    try{
      const rel=decodeURIComponent(href.replace(/^workspace:\/\//i,'')).replace(/^~\//,'').replace(/^\.\//,'');
      // Emit as a hash-only href + dataset so the existing _isSafeUrl check passes
      // and a click delegate can hand off to openFile(rel).
      return '#workspace=' + encodeURIComponent(rel);
    }catch(_){ return '#'; }
  }
  if(/^file:\/\//i.test(href)){ ... existing ... }
  return href;
}

Then update _isSafeUrl at static/ui.js:3083-3094 to allow #workspace= (it already allows bare #).

3. Add a single delegated click handler somewhere boot-level (e.g. alongside the existing handlers at static/ui.js:529 / :611):

document.addEventListener('click', e => {
  const a = e.target.closest('a[href^="#workspace="]');
  if (!a) return;
  e.preventDefault();
  const rel = decodeURIComponent(a.getAttribute('href').slice('#workspace='.length));
  if (typeof switchWorkspacePanelTab === 'function') switchWorkspacePanelTab('files');
  if (typeof openFile === 'function') openFile(rel);
});

4. Streaming-markdown parity — add workspace: to _SMD_SAFE_URL_RE at static/messages.js:1056 and handle the scheme in _smdFileHref (rename to _smdLinkHref). Without this, the same link rendered through streaming-markdown would lose its href via _sanitizeSmdLinks at line 1068-1074.

Using a #workspace=... synthetic href instead of a raw workspace:// URL means the link survives _tag() / _isSafeUrl sanitization, doesn't trigger a browser navigation, doesn't show as a "blocked scheme", and degrades to a no-op anchor if JS is off — same robustness profile as the existing MEDIA: and file:// handling.

Test plan

• Send [Open](workspace://notes/plan.md) from the agent → click renders, no navigation, file opens in the workspace preview pane with the panel switched to the Files tab.
• Send the same link inside a fenced code block → not rewritten (stash protection preserves it as literal text).
• Send [a](workspace://../../etc/passwd) → openFile already does workspace-relative resolution server-side via the existing /api/file endpoints (api/file/raw, /api/file), so traversal is rejected at the API layer; worth confirming the rel path normalization in step 2 doesn't accidentally re-introduce a way to bypass that. A test that asserts .. paths are still rejected end-to-end is the one regression check worth writing.
• Verify both rendering paths (initial render uses renderMd, in-flight streaming uses streaming-markdown).
• Verify non-previewable extensions still trigger download (the DOWNLOAD_EXTS branch at static/workspace.js:473).

Small, contained change; the per-file changes I'd review are roughly: static/ui.js (~25 lines), static/messages.js (~10 lines), one new delegated handler. Worth filing as a PR.