This was generated by AI during triage.
Before submitting
Area
apps/web
Steps to reproduce
- Open a thread whose workspace is one directory.
- Ask the agent to read a text or Markdown file at an absolute path outside that workspace.
- Have the agent cite the file in its response, for example
C:/other-project/XYZ.md:35.
- Click the rendered file link.
Expected behavior
The file opens at the cited line in the right-hand file preview, just like a file inside the current workspace.
Actual behavior
The click falls back to the preferred external editor because the link has no workspace-relative path. When no editor is available, T3 Code shows:
Unable to open file
No available editor can open C:/other-project/XYZ.md:35 ...
The user is offered a copy action instead of seeing the file in the right-hand panel.
Technical investigation
resolveMarkdownFileLinkMeta intentionally sets workspaceRelativePath to null for absolute paths outside cwd. MarkdownFileLink.handleOpenInFilePreview treats that as a reason to call handleOpenInEditor() rather than onOpenInPanel(...).
The right-panel file surface currently stores only a workspace-relative path, and ChatView always supplies the active workspace root to FilePreviewPanel. Supporting this safely requires the file surface to retain the root used for the selected file, so the existing workspace file API can still receive a relative path and preserve traversal/symlink checks.
Acceptance criteria
- Clicking a text/Markdown file reference outside the current workspace opens it in the right-hand file preview.
- A cited line is revealed.
- Existing in-workspace links behave unchanged.
- External-editor actions remain available as secondary actions where supported.
- Existing relative traversal and symlink escape protections remain unchanged.
Related issues
Before submitting
Area
apps/web
Steps to reproduce
C:/other-project/XYZ.md:35.Expected behavior
The file opens at the cited line in the right-hand file preview, just like a file inside the current workspace.
Actual behavior
The click falls back to the preferred external editor because the link has no workspace-relative path. When no editor is available, T3 Code shows:
The user is offered a copy action instead of seeing the file in the right-hand panel.
Technical investigation
resolveMarkdownFileLinkMetaintentionally setsworkspaceRelativePathtonullfor absolute paths outsidecwd.MarkdownFileLink.handleOpenInFilePreviewtreats that as a reason to callhandleOpenInEditor()rather thanonOpenInPanel(...).The right-panel file surface currently stores only a workspace-relative path, and
ChatViewalways supplies the active workspace root toFilePreviewPanel. Supporting this safely requires the file surface to retain the root used for the selected file, so the existing workspace file API can still receive a relative path and preserve traversal/symlink checks.Acceptance criteria
Related issues