[FEATURE] Desktop app: show the GitHub issue as a footer chip next to the PR chip (statusLine and footerLinksRegexes are silently inert)

Preflight Checklist

• [x] I have searched existing requests. Closest matches are linked under Alternative Solutions; none cover the desktop case.
• [x] This is a single feature request.

Problem Statement

The desktop app's footer auto-detects and shows the PR for the current branch as a chip. There is no equivalent for the GitHub issue / ticket the branch is implementing, and no supported way to add one.

Our team's workflow is ticket-first: work is tracked on a GitHub Project board, branches are named <type>/issue-<N>-<slug>, and a session usually lives longer than the PR (planning and building happen before a PR exists). The PR chip only becomes useful late; for most of a session's life, nothing in the window says which ticket it belongs to. With several desktop sessions open across worktrees, telling them apart means asking the agent or reading the session title.

The settings that would solve this exist, and both are silently inert in the desktop app:

• statusLine — the desktop app never executes the command. Verified by making the script append a timestamp to a file on every run: zero lines after 2 minutes, across an existing session and a session started after the settings were written. The bundled CLI does contain the feature (statusLine, statusLineText in the UI store next to prStatus), and the only gate found in that path is workspace trust not accepted, which did not apply.
• footerLinksRegexes — configured with a valid entry per the shipped schema (type/pattern/url/label), in user settings (the schema explicitly restricts it to user/flag/managed, which we honored). No badge rendered.

The footerLinksRegexes test had a control: it ran in a session started after the settings were written, on a branch with an open PR, and the built-in PR chip did render — so the footer row was alive and being drawn. The configured badge simply never appeared, while the built-in chip in the same row did.

Both mechanisms appear to be TUI-only — the telemetry event for the badge path is named repl_footer_links — and #80911 independently confirms the badges do render in the terminal TUI (OSC-8 hyperlinks, verified on 2.1.218). So this is not "broken", it is "not consumed by the desktop client".

Proposed Solution

Any one of these would solve it; listed in order of preference:

1. Detect the linked issue and render it as a second footer chip, next to the PR chip. The plumbing is already there: prUrlTemplate takes {host} {owner} {repo} {number} {url} placeholders, and GitHub exposes the PR's closingIssuesReferences. When a PR is detected, its closing issue could become a chip; before a PR exists, the issue number could come from the branch name via a configurable pattern.
2. Honor footerLinksRegexes in the desktop footer, alongside the built-in chips. The config format, validation, telemetry and 5-badge cap already exist — this is wiring an existing setting into another renderer.
3. Honor statusLine in the desktop app, or document explicitly that it is TUI-only. Today it fails silently: valid config, executable script, no output, no warning, no log.

Whatever the outcome, documenting which settings the desktop client ignores would have saved this entire investigation. footerLinksRegexes documents its precedence rules precisely (ignored in project and local settings) but says nothing about being TUI-only.

Alternative Solutions

Tried and rejected:

• Session title — the ticket number can be put in the title, and it does show in the picker. It is the current workaround, but it is not a link, and it competes with the title's real job of describing the work.
• Closes #N in the PR body — puts the issue one click behind the PR chip via GitHub's sidebar. Indirect, and only works once a PR exists.
• statusLine / footerLinksRegexes — the subject of this request.

Related issues:

• #80911 — footerLinksRegexes badges: enroll in the Footer keyboard-selection ring. Confirms the badges render in the TUI; asks for keyboard parity there.
• #83675 — Custom statusLine never renders in the native terminal install. Same setting, different surface: there it is a bug, here it looks like a gap.
• #74190 — Desktop app: show which folder a session is running in. Same family — the desktop footer shows repo and branch only, and users want more session context in it.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Ticket-driven team, several desktop sessions open in parallel git worktrees, one per ticket. Branch feat/issue-5054-zoom-and-context-menu, ticket #5054.

Wanted: a #5054 chip in the footer, clickable, from the moment the branch exists — next to the PR chip when a PR shows up.

What we configured (user settings), which renders nothing in the desktop app:

{
  "statusLine": { "type": "command", "command": "~/.claude/statusline-ticket.sh" },
  "footerLinksRegexes": [
    {
      "type": "regex",
      "pattern": "github\\.com/ORG/REPO/issues/(?<n>[0-9]+)",
      "url": "https://github.com/ORG/REPO/issues/{n}",
      "label": "ticket #{n}"
    }
  ]
}

Additional Context

• Desktop app bundled CLI: 2.1.237 (~/Library/Application Support/Claude/claude-code/2.1.237/claude.app/Contents/MacOS/claude) — this is the binary that actually runs desktop sessions.
• Separate terminal install: 2.1.220 (~/.local/share/claude/versions/2.1.220).
• macOS 15 (Darwin 25.3.0), arm64.
• Worth noting for anyone debugging the same thing: the two installs are different builds, so inspecting the terminal binary tells you nothing reliable about what the desktop app does.
• The statusLine script itself was verified independently: exit 0, correct stdout on a realistic payload, 58 ms.