Harden desktop navigation boundary for workspace Markdown links

[snowopsdev]

Harden desktop navigation boundary for workspace Markdown links

Summary

The desktop app should prevent untrusted workspace content from replacing the main Electron app document with an untrusted remote page.

The main window already gates window.open through an allowlist, but the app should also guard top-level navigation and redirects from renderer content. This matters for workspace Markdown previews because Markdown links are rendered inside the app chrome.

Why this matters

The BrowserWindow is configured with the app preload bridge. If untrusted workspace content can navigate the top-level app window away from the trusted app document, the preload/IPC boundary becomes much more exposed than intended.

This is a security hardening issue, not a feature request. It should be addressed before broader workspace-file and provider-hardening follow-ups, because navigation control is the first boundary that keeps untrusted document content out of the privileged app shell.

Relevant code

• Main BrowserWindow preload setup:
  • apps/desktop/src/main/index.ts
• Existing window.open handling:
  • apps/desktop/src/main/index.ts
• Markdown rendering in the files tab:
  • apps/desktop/src/renderer/src/components/FilesTabView.tsx
• Preload API exposure:
  • apps/desktop/src/preload/index.ts

Suggested fix

• Add a main-window navigation guard for will-navigate and redirect-style top-level navigation.
• Allow only the trusted app origin/document to remain loaded in the main BrowserWindow.
• Route external Markdown links through the existing safe external-open path instead of default top-level navigation.
• Consider a small shared sender-frame/origin helper for high-impact IPC handlers so sensitive channels can reject calls from unexpected documents.

Suggested tests

• Unit coverage for trusted-vs-untrusted navigation URL classification.
• Renderer coverage for Markdown link handling.
• Electron/main-process coverage for blocking remote top-level navigation if the current test harness supports it.

Notes

I can take this as a focused PR scoped to the navigation/preload boundary. Follow-up PRs can separately handle workspace root approval, workspace:// preview resource access, and headless browser network policy.

[github-actions]

Thank you for the detailed report and suggested fix, @snowopsdev. This is a solid security hardening issue — preventing untrusted workspace content from navigating the main Electron window away from the trusted app document is an important boundary.

Relevant code paths (from your issue and repo structure):

• apps/desktop/src/main/index.ts — main BrowserWindow setup and existing window.open allowlist
• apps/desktop/src/preload/index.ts — preload API exposure
• apps/desktop/src/renderer/src/components/FilesTabView.tsx — Markdown rendering in the files tab
• apps/desktop/src/main/preview-runtime.ts — preview runtime that may handle navigation for previews

The approach you outlined — adding a will-navigate guard, routing external links through the safe external-open path, and optionally a shared sender-frame helper for IPC — aligns well with the project's security posture (BYOK, local-first, no telemetry).

Since you intend to submit a focused PR, here are a few things to keep in mind:

• The window.open allowlist logic in main/index.ts could serve as a template for the navigation guard.
• Check if FilesTabView.tsx uses react-markdown with remark-gfm — if so, link rendering may be controlled via the linkTarget prop or custom renderers.
• For the shared sender-frame helper, the preload already uses contextBridge.exposeInMainWorld — a helper in packages/shared could validate IPC origins if needed.
• Existing tests are Vitest + Playwright; consider adding unit tests for URL classification and integration tests for navigation blocking in main process (if harness supports).

This issue doesn't overlap with any existing open/closed issues in the repo. Feel free to open a PR when ready — happy to review.

Open-CoDesign Bot