Before submitting
Area
apps/desktop, Windows notifications, thread lifecycle, and T3 Connect
Problem or use case
When I start a long-running task in T3 Code on Windows, I often switch to another application while the agent works. I want T3 Code to notify me through the native Windows notification system when the task is actually finished so I do not have to keep checking the app.
This is especially useful for long-running Claude Code, Codex, and other provider sessions where the work may take several minutes or more.
Proposed solution
Add native Windows completion notifications for settled agent runs.
When a thread finishes its current logical task and no longer has active work, T3 Code should send a Windows toast notification using the normal Windows notification center.
Expected behavior
- Send a native Windows notification when an agent task/run genuinely finishes.
- Include enough context to identify the result, such as:
- project or general-chat name;
- thread title;
- provider when useful;
- a short message such as Task completed.
- Clicking the notification should open T3 Code directly to the relevant thread.
- Notifications should work even when T3 Code is minimized or not focused, as long as the desktop app is still running.
- Respect Windows notification permissions and Focus/Do Not Disturb settings.
- Provide a T3 Code setting to enable or disable task-completion notifications.
- Avoid duplicate notifications for the same completed run.
- Work consistently for local and remote/T3 Connect sessions being viewed from the Windows desktop client.
Completion semantics
The notification should represent a meaningful user-facing stopping point, not every internal provider lifecycle transition.
Do not send a completion notification when:
- the parent agent is temporarily waiting on active subagents;
- a provider process rotates or restarts internally;
- the agent is still running tools or delegated work;
- the thread has not actually settled.
A notification should fire when:
- the logical run has completed and the final result is ready;
- the run fails and requires user attention, if error notifications are enabled;
- the agent is waiting for explicit user input or approval, if attention notifications are enabled.
Why this matters
The value of long-running agent workflows is reduced if I have to keep polling the app to see whether the work is done. Native Windows notifications let T3 Code behave like other background productivity tools and make it much easier to supervise several concurrent tasks.
Smallest useful scope
- Native Windows toast on final task completion.
- Notification includes the thread title.
- Clicking it opens the relevant thread.
- One on/off setting for completion notifications.
- No notification while subagents or other work are still active.
Related issue
Risks or tradeoffs
- Windows notification APIs may behave differently depending on installation method or application identity.
- Notification routing must identify the correct thread and environment when several T3 Connect environments are active.
- The app should not expose sensitive model output in notification previews by default; a short generic completion message is sufficient for the first version.
Before submitting
Area
apps/desktop, Windows notifications, thread lifecycle, and T3 ConnectProblem or use case
When I start a long-running task in T3 Code on Windows, I often switch to another application while the agent works. I want T3 Code to notify me through the native Windows notification system when the task is actually finished so I do not have to keep checking the app.
This is especially useful for long-running Claude Code, Codex, and other provider sessions where the work may take several minutes or more.
Proposed solution
Add native Windows completion notifications for settled agent runs.
When a thread finishes its current logical task and no longer has active work, T3 Code should send a Windows toast notification using the normal Windows notification center.
Expected behavior
Completion semantics
The notification should represent a meaningful user-facing stopping point, not every internal provider lifecycle transition.
Do not send a completion notification when:
A notification should fire when:
Why this matters
The value of long-running agent workflows is reduced if I have to keep polling the app to see whether the work is done. Native Windows notifications let T3 Code behave like other background productivity tools and make it much easier to supervise several concurrent tasks.
Smallest useful scope
Related issue
Risks or tradeoffs