[BUG] Copy Path on a rendered relative file link resolves against cwd, not the linked file's own directory

Summary

"Copy Path" (right-click context menu) on a rendered relative markdown file link resolves the path against the session working directory (cwd) instead of against the directory the linked document actually lives in. Copying a relative link to a file outside cwd therefore yields a wrong, nonexistent path.

Repro steps

1. In a session with working directory C:\projects, render a clickable relative markdown link to a file that lives outside cwd -- e.g. a memory-index entry: [Delegate easy searches](feedback_delegate_easy_searches.md). The actual file is at C:\Users\user\.claude\projects\C--projects\memory\feedback_delegate_easy_searches.md.
2. Right-click the rendered link and choose "Copy Path".
3. Paste the clipboard contents.

Expected

Clipboard holds the real path of the linked document:
C:\Users\user\.claude\projects\C--projects\memory\feedback_delegate_easy_searches.md

Actual

Clipboard holds C:\projects/feedback_delegate_easy_searches.md (cwd + the bare relative href). That path does not exist; a downstream tool refused to open it, which is how it was noticed. (Note the mixed separators too: backslash cwd joined to a forward-slash href.)

Root-cause hypothesis

"Copy Path" joins the relative href to the session working directory (C:\projects) rather than to the directory of the document the link was rendered in. The base used for resolution is cwd, not the linked file's own location.

Affected scope

Any rendered relative file link pointing to a file outside cwd. Invisible for normal in-repo links because cwd happens to be the correct base. The common trigger is memory-file links (entries surfaced from MEMORY.md), whose relative hrefs are meant to resolve against the memory directory, not cwd.

Related

• #27672 (Windows "Copy link" on chat markdown links) -- related surface, different bug
• #10846, #51015 -- other markdown-link handling issues