[Feature]: Link threads to issues and auto-settle when the issue closes

[dortort]

Problem

Threads can already link to a pull request and settle themselves when it merges or closes. A lot of work starts from a ticket rather than a PR, though: a GitHub/GitLab issue, a Jira ticket, a Linear issue. Today that thread stays in the active list after the ticket is done unless someone settles it by hand, and nothing in the thread shows the ticket's state.

Adjacent asks already in Ideas: #8334 (name threads from linked tickets), #6752 (import Linear issues), #7056 (start worktrees from a Linear issue), #6833 (separate settle toggles). This proposal is the piece those all lean on: a thread that knows which issue it is about.

Proposal

• Link a thread to an issue, manually (paste a URL in the palette or the linked-work panel, right-click an issue link in the conversation) or from an agent (MCP link_issue / unlink_issue / list_linked_issues).
• Show the issue's title and open/closed state on the thread, and include its identifier in thread search.
• Auto-settle the thread when the issue closes, behind a setting (sidebarAutoSettleOnIssueClose, default on, per-project override) that sits next to the existing merge/inactivity settings.
• Providers: GitHub, GitLab, Forgejo, and Azure DevOps issues through the CLIs the app already uses for pull requests; Jira and Linear through API tokens configured under Settings, redacted before they reach a client.

How it fits the existing design

• A sibling ThreadIssueLink beside ThreadPullRequestLink, not a generalised "work item". The PR link's shape (branches, checks, stacks, merged) is load-bearing across every host adapter and both clients; issues have an open | closed lifecycle and, for Jira/Linear, no repository at all.
• Links are resolved server-side at link time to a durable identity (Jira's numeric id, Linear's UUID, org-scoped Azure work-item ids, repo + number for the git hosts) with the display key kept separately, so key changes and repository transfers do not break the link.
• An issue sync reactor mirrors the PR sync reactor: one-minute sweep, grouped by issue so a host is asked once per issue, writes only on change, batch reads for Jira, Azure and Linear (one request per tracker per sweep), read failures surfaced on the link with retry and unlink instead of an endless unsynced state.
• Settlement reuses thread.auto-settle unchanged. The policy separates "which triggers participate" from "does the sweep run", so turning issue settlement on cannot re-arm PR-close settlement for anyone who had merge and inactivity settlement off. Any open linked item (PR or issue) blocks settlement; an open PR on the thread's branch still vetoes issue-driven settlement; an issue with an unknown close time never settles a thread on its own.
• Repo-host issues route through a project on that host for credentials and rate limiting, exactly as PR reads do. Jira and Linear route through the verified tracker config.
• Outbound polling only. No webhooks, so nothing changes for remote, relay or tunnel setups.

Surfaces

Web and desktop: link, unlink, refresh, linked-work panel, palette, autolink, status indicator, settings (flag plus an Issue trackers panel for Jira/Linear). Mobile: linked-issue display with open-in-browser and the settle toggle, synced across environments like the existing auto-settle settings. Docs: a Linked issues section beside Linked pull requests, one sentence in the sidebar guide.

Out of scope

Bitbucket issues (the Cloud tracker is legacy), Atlassian scoped/OAuth tokens, following GitLab issue moves automatically, inbound webhooks, and linking or secret entry from mobile.

Status

Implemented in a fork; I will add the PR link here once it is up. Very happy to shrink, split, or drop this if it is not a direction you want.

[Jardo-51]

Just a note on the issue links: The link should be displayed in the open thread under the composer, next to the PR link (there is plenty of space). But it should also be displayed in the sidebar. The sidebar usually doesn't have enough space to show the issue and the PR link side by side. So there should be a setting where the user can choose whether they want to see the PR link or the issue link in the sidebar.Or potentially both, if they have a wide-enough sidebar (there should be a toggle for each, so they can be turned on/of independently).

[Molinar17]

+1 to this. One thing I'd add: being able to actually read and work with the issue inside the thread, like the PR panel already lets you do.

My case: the agent creates and updates issues as part of the work (e.g. it writes up an analysis in an issue and keeps it updated). Right now I have to jump over to GitLab/GitHub to check what it posted and to keep up with comments. With PRs I never have to leave the app, so it's a bit of a gap.

There's no workaround today either. If you pass an issue URL like https://gitlab.com/org/repo/-/issues/123 to link_pull_request you get "This is not a recognised pull request URL. Pass repository and number instead." And passing repo + number would just register it as an MR, which it isn't.

What I'd love in the panel:

• description, comments, open/closed state, labels and task checkboxes, same idea as the PR view
• replying to comments and ticking tasks from there
• maybe a draft mode: before the agent creates an issue or posts a comment, show me the text in the panel and only publish once I OK it. It's writing to a shared place, so a quick review step would be nice

Totally fine if this comes after the linking part, it builds on the same thing anyway. Thanks!

[PixPMusic]

+1 to this. I'd already been thinking about GitHub issues: we can link a PR to a thread, but we can't link the issue that the work came from. That feels like an obvious gap, especially when several threads are working toward the same issue.

I found this discussion while thinking through durable access to Jira. T3 already uses CLIs like gh and glab for source control, and Atlassian's new Teamwork Graph CLI (twg) seems like a natural fit for Jira. It would let T3 reuse an authenticated CLI on the environment host for the issue viewer. Agents could also read Jira directly through twg, as they already use gh and glab for PRs and MRs.

I did a read-only check against a Jira Service Management ticket, and TWG returned the issue fields, custom fields, and comments, including both public replies and internal notes with an explicit visibility flag. Comment pagination worked too, so there seems to be a practical path to reading the issue inside T3, similar to the PR view.

I'd be interested in starting with linking/unlinking, issue details, and the comment timeline. Agent-facing T3 tools could mirror the existing PR link/unlink/list tools; agents would use twg directly for issue and comment reads. Would TWG fit the direction you're considering for the Jira side of this?

[SeoFood]

I'd like to link issues alongside PRs. I have a lot of issues I'd want to attach to T3 threads before a PR exists.

I'd then work on the issue in that thread, create a PR from the work, and link it to the same thread. Keeping both the original issue and the resulting PR attached, with their status visible, would make it easier to follow the work from report to fix.