[BUG] Claude Desktop auto-links bare `#NNNN` issue refs to CWD `origin` remote — wrong repo for fork-and-PR workflows

When Claude Desktop's Code tab renders an assistant message containing a bare #NNNN GitHub issue/PR reference, the resulting clickable link resolves against the current working directory's origin remote. For the standard fork-and-PR contributor workflow, where origin is the user's fork and upstream is the canonical repo, every such link 404s.

This appears to be a new bug surface for a previously reported class of problem. The same auto-link-to-CWD-origin behavior has been reported repeatedly in the TUI (#27894 closed stale, #28005 closed as dup, #31450 closed invalid, related TUI-OSC8 variant #29188 closed stale), and per #29188 the bug does not occur in the VS Code extension's webview ("renders the correct URL, confirming the bug is specific to the TUI markdown renderer"). The Claude Desktop renderer is a third surface where the same bug is present, and to my knowledge it has not been reported before. I checked all open area:desktop issues for link/url/repo/autolink terms before filing.

The framing the prior TUI reports missed: they described this as a cross-repo discussion problem ("I'm in repo A, Claude mentions repo B"). The more common and impactful case is the fork-and-PR contributor workflow on a single project:

• I work on stdlib-js/stdlib (upstream).
• My origin remote is my fork (batpigandme/stdlib) because that is the only remote I have push access to. This is the standard gh repo fork --remote configuration.
• When Claude renders a bare #9459 in a Desktop response, Desktop links it to batpigandme/stdlib/issues/9459, which 404s because the issues live upstream at stdlib-js/stdlib.

So this is not an edge case for users discussing unrelated repos. It is the default state for anyone contributing to a project they do not own, which is most OSS contributors most of the time.

Repro

1. Clone an OSS repo, add upstream pointing at the canonical repo.
2. Push your fork as origin (standard gh repo fork --remote flow).
3. In Claude Desktop's Code tab, ask about an issue in the upstream repo by number.
4. Click the rendered link in the response. Goes to <your-fork>/issues/N. 404.

Workaround

Write full URLs [#9459](https://github.com/stdlib-js/stdlib/issues/9459) for every reference. Reliably correct, but loses the auto-link convenience and is verbose. I am doing this in my notes now.

Suggested fix, in order of effort

1. Document the current resolution logic. I checked settings.md and confirmed there is no documented mechanism. Even just publishing the rule (presumably "uses origin remote") would help users diagnose 404s instead of assuming the link is broken.
2. Add a settings.json field, e.g., github.issuesRepo: "stdlib-js/stdlib", to override the inferred repo per project.
3. Auto-detect. If an upstream remote exists, prefer it for issue resolution while continuing to use origin for push/branch context. Recognizes that "where do I push code" and "where do issues live" can have different correct answers in this workflow. This matches gh's own behavior: gh issue view correctly handles upstream by default when run inside a fork.

Option 3 is the cleanest fix for OSS contributors. Option 2 is the lowest-risk shipping path. Option 1 is the floor — please do at least this much.

Given that this is the third independent renderer to exhibit the same bug class, the fix probably belongs in a shared component rather than per-renderer.

Environment

Claude Desktop on macOS, Code tab. Repro tested against stdlib-js/stdlib upstream / batpigandme/stdlib fork.

Happy to test or share more context.