Thread notifications: say which project the thread belongs to

[AdEx-Partners-DE]

Area: apps/web (in-app toast and desktop/browser notification)

Problem

When a thread finishes or needs input, the toast and the OS notification show the status and the thread title. They do not say which project the thread is in.

With several projects open at once that is the first thing I need to know, because it decides whether I switch now or later. Thread titles do not carry it: "Fix failing tests" or "Update the docs" exist in every project. Today I have to click the notification to find out where it came from.

Proposal

• In-app toast: show the project's icon and name above the thread title, the same icon the sidebar uses.
• OS notification: put the project name on the first line of the body, the thread title on the second. The title line (status) stays as it is.
• Threads without a project keep today's text.

No new setting; it is one more line of information the app already has in the shell snapshot.

Prototype

Web client, about 30 lines in ThreadNotificationCoordinator.tsx: https://github.com/AdEx-Partners-DE/t3code/tree/feat/thread-notification-project

In use for a day on Windows 11 with about ten projects. Not covered: mobile push notifications, which are built elsewhere and would need the same line.

Open questions

• Should the project lead the OS notification's title instead of the body? Windows truncates long bodies; the title is always visible.
• Is the environment worth naming too when more than one is connected, or is that too much for a toast?

Posted by Claude (AI) on behalf of @AdEx-Partners-DE; not reviewed by a human.

[TheKelvinPerez]

I'd find this useful on macOS too. My previous terminal setup identified notifications by tmux session name followed by window name, so I could tell which project needed attention without opening it.

I'd like to keep plain thread titles in the sidebar while notifications dynamically show the project and current thread title, for example:

Input needed
Dashboard • Billing settings

The status heading and click-through to the thread could stay as they are. A project rename or thread rename should be reflected in subsequent notifications. An optional setting would also work for me if keeping the existing presentation is preferred.

I'm planning to try this in my own fork. Is the project name in the notification body still the preferred direction for an upstream change?

[AdEx-Partners-DE]

Thanks, @TheKelvinPerez — keeping the sidebar title plain and adding the project only to the notification is still the shape proposed here. There is no maintainer approval in this discussion yet, so I cannot speak for the upstream direction.

I checked the prototype source today: when emitting a notification it finds the project from the shell snapshot and builds the body from project.title and thread.title, on separate lines. It does not rename the thread. The status heading and click-through stay in place; a missing project falls back to the thread title. That is a useful starting point for the rename behavior you describe, although I have not run a rename scenario or checked this on macOS.

If you try it in your fork, could you check project rename, thread rename, and a long project/title pair on macOS? That would add evidence the Windows prototype does not provide, particularly around notification truncation.

Posted by Codex (GPT-6 Astra, Codex harness via T3 Code) on behalf of @AdEx-Partners-DE.