Investigate file-pill relative-path base: copied paths include the current directory name #31

Report

Investigate the base used by file pills and Copy relative path. In the reported conversation, copying a relative path prefixes it with the current directory's name, making it look like a subdirectory of itself.

There are two distinct concerns here:

1. The agent emitted ambiguous relative paths for files outside the thread's current working directory. The agent should have emitted absolute paths. Resolving an unqualified relative reference against the thread cwd is a reasonable fallback; this report does not require the renderer to infer a filesystem base from surrounding prose.
2. Even under that cwd fallback, the reported Copy relative path value appears inconsistent with a cwd-relative interpretation. Confirm whether another base is intentional, and make the contract/UI explicit.

Reproduction from the user report

Thread cwd:

/home/juanbe/copilotclaw/workspace

Agent response:

Source: ~/development/tools/herdr-copilot-fork
Luffy runbooks: runbooks/install-luffy.txt and runbooks/test-luffy.txt inside that directory

Actual runbook locations:

/home/juanbe/development/tools/herdr-copilot-fork/runbooks/install-luffy.txt
/home/juanbe/development/tools/herdr-copilot-fork/runbooks/test-luffy.txt

Observed:

• The file pills resolve against the thread cwd. The supplied screenshot shows the test-luffy.txt tooltip as /home/juanbe/copilotclaw/workspace/runbooks/test-luffy.txt.
• Copy full path returns that same cwd-based path rather than the actual external file location. This is explainable by the ambiguous agent output, not proof that the renderer can recover the intended path.
• The user reports Copy relative path returns workspace/runbooks/install-luffy.txt.

The screenshot establishes the resolved tooltip. The copied clipboard values are user-reported; they were not independently exercised against the UI during issue filing.
The screenshot was supplied in the originating conversation; it is not attached to this issue.

Expected behavior / decision needed

If the base is the thread cwd, the cwd-based target should copy as runbooks/install-luffy.txt or ./runbooks/install-luffy.txt, not workspace/runbooks/install-luffy.txt.

If the intended base is a project/repository root or a parent directory instead, document that choice and expose enough context in the menu/tooltip to avoid a misleading generic "relative" label.

An absolute reference to the actual external file must preserve its full target. If relative copying is offered for that target, derive it from the documented base; do not silently substitute the thread cwd's unrelated runbooks directory.

Investigation and acceptance criteria

• Identify which base is used for parsing, opening, tooltips, Copy full path, and Copy relative path: thread cwd, worktree root, project root, or another directory.
• Ensure all actions share one documented target/base contract; explicitly distinguish display shortening from path identity.
• Add coverage for cwd-relative input, ./ input, absolute and ~ paths, external files, nested thread cwd versus project root, remote environment ownership, and Windows/WSL paths.
• Preserve any line/column suffixes consistently.
• Treat prose-relative references as ambiguous rather than claiming the UI can always infer the intended sibling project.
• Optional UX investigation: whether inaccessible/nonexistent targets should show a useful warning rather than a confident-looking file reference.

References / environment

• User report and screenshots: 2026-10-28, Copilot-provider conversation in the fork UI.
• Exact desktop/frontend build was not established. The separately inspected MLVM backend is 0.0.42-preview.20261003.2; do not assume that is the frontend build.
• Current upstream separates copy-menu values in MarkdownFileLink.logic.ts: "Copy relative path" uses workspaceRelativePath. This is a useful investigation pointer, not a confirmed root cause in the running fork.