カスタムスレッドサブスクリプションが廃止予定にCustom thread subscriptions are being deprecated

GitHub is deprecating custom thread subscriptions, removing the ability to configure notification behavior for individual notification threads. The change matters to developers, maintainers, and teams who fine-tune how they receive updates from issues, pull requests, and discussions, because it alters one of the more granular controls in GitHub's notification system.

According to the company's changelog, GitHub will remove support for custom thread subscription settings as part of a rollout. Once the change takes effect, users will no longer be able to set custom subscriptions on a per-thread basis. GitHub says affected users should review how they receive thread updates and adjust their preferences to match the notification options that remain available.

To understand the impact, it helps to recall how GitHub notifications are structured. A thread is the running notification stream tied to a specific object, such as an issue, a pull request, a discussion, or a commit conversation. A subscription governs whether a user is notified about new activity in that thread and, in some cases, why. Subscriptions can be created automatically — for example, when someone opens or comments on a thread, is assigned, is mentioned, or watches the surrounding repository — or set manually by subscribing to or unsubscribing from a particular thread.

Custom thread subscriptions sit at the more detailed end of this system, letting users override default behavior on a single thread rather than across an entire repository. With the deprecation, that per-thread customization appears to be going away, leaving the broader subscription and watch controls in place. GitHub's notice frames this as the removal of a specific setting rather than a wholesale change to notifications, so the core inbox and repository-level controls are likely to continue functioning as before.

Users who want to keep close control over their notifications still have several options. Repository watch settings allow a choice between receiving all activity, only participating-and-mentions notifications, ignoring a repository entirely, or selecting a custom mix of event types such as issues, pull requests, releases, and security alerts. The notifications inbox on github.com lets users subscribe or unsubscribe from individual threads, mark items as done, and filter by reason. GitHub's REST API also exposes notification and subscription endpoints, which some teams use to build custom triage tools or route alerts into external systems.

The deprecation follows a broader pattern in which GitHub periodically retires narrow or lightly used configuration options in favor of a simpler, more maintainable notification model. Consolidating settings can reduce edge cases, make behavior more predictable, and lower the surface area that has to be supported across the web interface, mobile apps, email, and the API. For power users who had tuned specific threads, however, the trade-off is a loss of granularity that may require reworking established habits.

Teams that depend heavily on notification hygiene should audit their current setup before the change lands. That includes checking which threads currently rely on custom subscriptions, confirming that repository-level watch settings and per-thread subscribe or unsubscribe actions cover the same needs, and updating any documentation or onboarding guidance that references the deprecated option. Organizations that pipe GitHub notifications into tools such as Slack, email filters, or issue-tracking integrations should verify that those workflows do not assume custom thread subscription behavior.

As with other changelog entries, GitHub typically provides a timeline and, where relevant, migration guidance for deprecations, so users should consult the official changel