[BUG] Bare #NNN issue refs linkify to a stale, pre-transfer repo owner despite correct remote/gh config

Status Open
Reported on v2.1.278
Maintainer reply None cached
Activity 0 comments · opened Sep 19, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

After a GitHub repository was transferred to a new owner/name, bare #NNN issue references in Claude Code's rendered output still link to the old owner/repo URL — which now returns 404. Expected: bare refs resolve against the repository's current remote.

Everything the user can inspect points at the new repo:

  • git remote -v → new repo
  • gh repo set-default --view → new repo
  • all on-disk config (see "Evidence") → new repo

A session restart did not clear it.

Writing a fully-qualified ref (Owner/Repo#123) or a full URL links correctly — so it is specifically the bare-ref resolver that is using a stale root.

What Should Happen?

A #nnn GitHub issue link should link to the issue number in the correct current remote owner/repo as reflected in the git settings in the directory claude code is running from.

Error Messages/Logs

Steps to Reproduce

  1. Have a repo transferred on GitHub to a new owner/name (old URL now 404s; GitHub's transfer redirect covers git operations, not issue-page URLs).
  2. Update the origin remote and gh repo set-default to the new slug.
  3. In Claude Code, have the assistant emit a bare #123 in a reply.
  4. Click it → the URL uses the old owner/repo → 404.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.278 (CLI entrypoint) · macOS (darwin arm64)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Evidence / what was ruled out

An exhaustive search for any stale project→repo mapping found none on disk for this project:

  • ~/.claude/settings.json, ~/.claude/{cache,sessions,session-env,ide,daemon,jobs} — no stale slug; sessions/<pid>.json cwd is correct.
  • Desktop app storage ~/Library/Application Support/Claude/{git-shadow,claude-code-sessions} — no stale entry for this project (the only old-owner hits belonged to unrelated projects or conversation transcripts).
  • git config --list --show-origin — nothing stale.

Conclusion: the stale root appears to be internal client state not exposed on disk, captured before the transfer and never re-derived from the live remote.

Concrete example: old swizzlevixen/Cinedex → transferred to a private repo under the Vixen-Labs org. Bare #266 linked to https://github.com/swizzlevixen/Cinedex/issues/266 (404) instead of the current repo.

Suggested fix

Resolve bare #NNN against the current origin remote (or gh repo set-default) at render time, or invalidate the cached project→repo mapping when the remote URL changes.

Request IDs (for tracing)

  • req_011CfDDiG8HqYBAP6PsLZnKq
  • req_011CfDDks1a7LfbBKqx3HNiZ
  • req_011CfDDo7CuS5k6ecWKCAkpM

Session

649c0d20-bdda-45bb-a5d8-1ba66dea8740 (bridge session_01XrUTcEA5H5qNstHwWybemm)

View original on GitHub ↗