[BUG] Expanded Markdown Preview breaks relative file links (resolved against /tmp instead of workspace)

[ChanochShayner]

Problem (one or two sentences)

When opening a chat message in VS Code's Markdown Preview via the "Open in preview" button, all relative file links (e.g., helper) are broken because they resolve against /tmp instead of the workspace directory.

Context (who is affected and when)

Affects all users who click the "Open in preview" (expand) button on AI responses that contain relative file path links. The links appear correct in the webview chat but break when opened in VS Code's native Markdown Preview.

Reproduction steps

1. OS: macOS (also affects Linux). Extension version: latest.
2. Start a conversation that produces a response with relative file links, e.g., ask the AI to explain a file, and it responds with markdown like helper.
3. Click the "Open in preview" button (SquareArrowOutUpRight icon) on the AI's response message.
4. In the opened Markdown Preview, hover over or click any relative file link.
5. Observe that the link resolves to /tmp/src/utils/helper.ts:42 instead of /src/utils/helper.ts:42.

Expected result

Relative file links in the Markdown Preview should resolve against the workspace root, making them clickable and functional.

Actual result

All relative file links are prefixed with /tmp (the OS temp directory) because the temp markdown file is written to os.tmpdir() in webviewMessageHandler.ts (openMarkdownPreview case, line ~3451).

Variations tried (optional)

Root cause identified in src/core/webview/webviewMessageHandler.ts, the "openMarkdownPreview" case:

const tmpDir = os.tmpdir() // <-- This is the problem
const tempFilePath = path.join(tmpDir, tempFileName)

VS Code's Markdown Preview resolves relative links relative to the document's directory. Since the file is in /tmp, all relative links resolve against /tmp.

Suggested fix: Write the temp file to the workspace directory (using getCurrentCwd() already available in the handler) instead of os.tmpdir(). Use a dot-prefixed filename (.roo-preview-.md) to minimize workspace pollution.

App Version

Latest (bug exists since PR #10773)

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

No errors in logs — the file is written and preview opens successfully.
The issue is that VS Code's markdown preview resolves relative paths
relative to the temp file location (/tmp/) instead of the workspace.

Affected code: src/core/webview/webviewMessageHandler.ts lines 3448-3466
Introduced by: PR #10773 (feat: add button to open markdown in VSCode preview)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause: In src/core/webview/webviewMessageHandler.ts (the "openMarkdownPreview" case around line 3279), the temp markdown file is written to os.tmpdir() (e.g. /tmp). VS Code's Markdown Preview resolves relative links against the document's directory, so all relative file links like [helper](src/utils/helper.ts:42) resolve against /tmp instead of the workspace root.

Proposed Fix:

1. In the "openMarkdownPreview" case, replace os.tmpdir() with the workspace directory obtained via getCurrentCwd() (already defined at line 102 in the same file).
2. Use a dot-prefixed filename (.roo-preview-<timestamp>.md) so the temp file is less visible in the workspace and can be gitignored.
3. Add cleanup logic: delete the temp file after a short delay (e.g. 2 seconds) using setTimeout + fs.unlink, so the workspace isn't polluted with leftover preview files. The markdown preview will have already loaded the content by then.
4. Add a .roo-preview-*.md entry to the extension's default .gitignore recommendations or document it, so these transient files don't accidentally get committed.
5. Add/update tests for the openMarkdownPreview handler to cover the new behavior.

Changes:

• src/core/webview/webviewMessageHandler.ts: Modify the openMarkdownPreview case to write the temp file to the workspace directory and add cleanup.

This approach directly solves the issue by ensuring relative links resolve against the workspace root, while minimizing workspace pollution via dot-prefixed naming and automatic cleanup.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.