Repository navigation
Description
Describe the bug
Ctrl+click on an assistant-rendered Markdown file link does not open the file in the VS Code integrated terminal in a Linux devcontainer on WSL2 (user-reported). Local inspection confirms that the link has a relative .md target, no URI scheme, and an existing destination file; there are no spaces, query, fragment, or line suffix in the target.
This is a recurrence of the non-clickable Markdown-link symptom in #1974, closed as resolved in v1.0.88. The same root cause is not confirmed. The generic reproduction below has not yet been tested.
Affected version
GitHub Copilot CLI 1.0.109.
Steps to reproduce the behavior
Generic reproduction candidate; not yet tested:
- In the same VS Code devcontainer terminal, prepare a disposable directory:
repro_dir=$(mktemp -d /tmp/copilot-link-repro.XXXXXX)
mkdir "$repro_dir/docs"
printf '# Example design\n' > "$repro_dir/docs/review-design.md"
cd "$repro_dir"
printf '%s\n' "$PWD/docs/review-design.md"- Ctrl+click the printed absolute path as a terminal control. Record whether it opens. Then run
copilotto start a fresh session. - Send this prompt:
Do not use tools. Reply with exactly the following text as ordinary Markdown, not inside a code block:
[review design](docs/review-design.md)
[website](https://example.com)
https://example.com
- After the reply finishes, Ctrl+click each link. Record whether the file link and both web links open, and any hover tooltip or error. Retry after scrolling the reply upward.
Reported original result: the Markdown file link does not open. Results for these generic controls are pending.
Expected behavior
Ctrl+click opens the existing file in the remote VS Code editor. Web links open the correct URL. If a destination cannot be opened, provide a clear error instead of silently doing nothing.
Additional context
Environment: Linux x86_64 devcontainer on WSL2; VS Code terminal 1.145.2; TERM=xterm-256color. No settings were changed during investigation.
Version caveat: 1.0.109 is the current copilot --version result. The original session was created with 1.0.102; its latest resume event does not record the CLI version. The exact version producing the failing reply is therefore unverified.
Related: #5196 (open, remote VS Code file-link failures); #4893 (open/reopened, VS Code links flicker or fail); #1974 (closed/completed, Markdown clicks broken; resolution comment cites v1.0.88). These establish similar symptoms, not a confirmed common cause.
The transcript records Markdown source, not mouse events or rendered terminal escape sequences. No session IDs, private paths, repository content, hostnames, or logs are included
Activity