In-app thread notifications blur the composer during macOS dictation

What happened

On T3 Code Desktop for macOS, writing or dictating in the prompt composer is interrupted when an in-app notification arrives. The composer loses focus, which is especially disruptive when using macOS speech-to-text.

This has been observed with notifications such as a thread taking longer than expected and a thread completing.

Diagnosis

The local server trace contains no related crash or server-side error.

In current main source (used as an approximate reference for this nightly), ThreadNotificationCoordinator creates an in-app toast only when the document is visible and focused. The toast includes interactive controls: an Open thread action and a dismiss button. The reporter observes that the composer loses focus when these focused-window notification toasts appear.

The exact desktop-app build could not be independently read from the local environment endpoint in this triage session, so the source references are approximate for the reported nightly.

Steps to reproduce

On macOS, open T3 Code Desktop and a thread with an active composer.
Focus the composer and begin typing or start macOS dictation.
Cause an in-app thread notification, for example by waiting for a running thread to trigger a taking longer than expected notice or complete.
Observe that the composer loses focus and dictation/input is interrupted.

Version

0.1.3-nightly.20261023.3553 local server; affected desktop-app build reported as the latest nightly, exact build unknown.

Environment

macOS, Apple Silicon (darwin arm64)
OS kernel: 27.2.0
Node: v26.12.1
Local T3 server: 0.1.3-nightly.20261023.3553
Triage CLI: 0.1.2 (not the affected-app version)

Evidence

Server trace: no crash or server-side error correlated with notification delivery.
Current-main source reference: apps/web/src/components/ThreadNotificationCoordinator.tsx emits in-app toasts only while document.visibilityState is visible and document.hasFocus() is true, and attaches an Open thread action.
Toast renderer: apps/web/src/components/ui/toast.tsx renders a focusable dismiss button and a focusable Toast.Action.

Related issues

No matching open issue was found in triage search. Discussion #12976 covers notification preference granularity, not composer focus loss.

Fix applied or workaround

No machine changes made. Suggested workaround: disable Settings → In-app notifications, which should suppress these toast alerts while leaving the separate notification mode/sound setting available.

Filed by

Codex (GPT-5) via t3 triage

I tried to reproduce this with real macOS Dictation and couldn't. The toast shows up and dictation keeps going.

Setup: T3 Code Nightly 3553 (5127302), the build in this report, on a Mac mini. The Mac has no mic, so Dictation listened to a virtual audio input (BlackHole) playing speech. In-app notifications were on and Thread notifications was set to "Notifications with sound". I dictated into a new thread's composer while a turn in another thread finished.

The "Thread completed" toast appeared mid-dictation. Every word after it still landed in the composer, and focus never left it: no focusout and no window blur fired.

Recording: https://files.catbox.moe/ore6ru.mp4 (toast at about 0:38)
Frame with the toast up while dictation is still writing: https://files.catbox.moe/8tfi31.png

In the code, the toast doesn't take focus when it opens. Base UI only moves focus into the toast area on F6, or when you close a toast that already has focus.

Could you share:

A screen recording of it happening, with the Dictation indicator visible.
Which mic Dictation uses (built-in, AirPods or another Bluetooth headset, USB) and how you start it (Globe key, shortcut, or menu).
Whether it still happens with Thread notifications set to "Notifications only" (no sound) and in-app notifications still on.

If it stops without the sound, the chime is the trigger rather than the toast. A Bluetooth headset switching audio modes when the chime plays could do that.

[Opus 5.5][Claude Code] on behalf of shivam.

Tried again on current main (ad068d7c93), web client in Chromium, In-app notifications on:

Typed into a new thread's composer while a Codex turn in another thread finished. The "Thread completed" toast appeared and closed. Focus stayed in the composer the whole time: no focusin/focusout events, and the caret and selection did not move.
Called the app's toast manager directly while the composer had focus: one toast, two stacked, auto-close, and the dismiss button. Same result in each case.

On the desktop app, the in-app toast runs the same code. So we still can't separate the toast from the notification sound. The questions in the comment above are what would settle it, especially:

Does plain typing (not dictation) also lose focus when the toast appears?
Does it still happen with Thread notifications set to "Notifications only" (no sound)?
Which mic Dictation uses, and a screen recording if you can.

Thanks for taking the time to investigate this! I use the MacBook’s built-in microphone and start Dictation by double-pressing the Globe key.

It happened twice in quick succession today while I was typing normally, without Dictation. Text stopped appearing and the cursor disappeared. I clicked back into the composer, resumed typing, and it lost focus again shortly afterwards. I didn’t notice any notification this time, so my original assumption about notifications may have been wrong.

We’ve set up a local focus-event recorder to catch what happens next time, but unfortunately it wasn’t active during today’s incidents. There’s no clear cause yet. It could be something on my system, although I haven’t noticed this in Claude Code, Codex, or other apps.

I’ll follow up if I can capture it again with a recording and matching focus-event logs.

Thanks, that helps. Since it also happens without Dictation and without a toast, I tested plain typing on current main (67661cfbb5) with a recorder for focusin/focusout, window blur/focus, and changes to document.activeElement:

Web client (Chromium): typed into a new thread's composer while turns in other threads ran and finished, first with In-app notifications off, then on. Two "Thread completed" toasts appeared mid-typing. Nothing was logged and every character landed.
Web client, reconnect: restarted the server while the composer had focus. Focus stayed put.
Desktop app (Linux Electron): typed real keystrokes into the composer while three turns in other threads finished, with In-app notifications on. Three toasts appeared. Nothing was logged and all 1,135 characters landed.

So the notification and reconnect paths haven't reproduced it. When your recorder catches it again, these would narrow it down:

The focus log, especially which element or window gets focus right after the composer loses it.
What T3 Code was doing at that moment: was an agent driving the Browser panel (preview_* tools), was a terminal or preview panel open, and was a turn streaming in the thread you were typing in?
The desktop build, from T3 Code → About.

A screen recording alongside the log would still help.

I’ve now caught the focus loss on video, attached here. It happened several times today, including again shortly after I clicked back into the input.

Unfortunately, our focus-event logger wasn’t running. It hadn’t restarted automatically after T3 restarted, so we don’t have matching logs for these occurrences. It’s active again now, and I’ll continue investigating.

I also briefly saw a blue microphone icon near the top of the screen, but it disappeared when I started capturing, so I couldn’t document that. We’ve considered whether background agent activity could be involved, but there’s no evidence establishing that yet. The first occurrence also happened before the investigating agent started interacting with the UI.

Thanks for catching it on video. The recording didn't make it into the comment, though: the upload failed (only a Failed to upload "Screen Recording 2026-10-29 at 12.28.31.mov" placeholder is there). GitHub caps video attachments at 10 MB on free accounts, so a trimmed clip or a conversion to .mp4 should fit. Zipping it or linking it from any file host also works.

What I ran this time, on current main (e6ca17001d) with the desktop app (Linux Electron) and a recorder for focusin/focusout, window blur/focus, and document.activeElement:

Typed 1,809 characters into a new thread's composer over 2.5 minutes while a Codex turn ran in another thread and repeatedly used the Browser tools on a hidden tab. Every character landed. Nothing was logged.
Typed 1,107 characters into the composer of the thread whose turn was running, until it finished. Same result.

One known cause of this exact symptom is still open: https://git.cafe/pingdotgg/t3code/issues/21954. When an agent clicks in the Browser panel (preview_click), focus moves out of the composer, even in a different thread and even when the browser tab is hidden. In a thread, that shows up as "Used browser" or "Clicking in the preview browser". Your first occurrence came before your investigating agent touched the UI, so this may not be it, but it's the first thing to rule out.

For the next occurrence, these would settle it:

The video, re-attached.
Whether any thread showed "Used browser" or "Clicking in the preview browser" in the minute before focus left. Check all threads, not just the one you were typing in.
If the blue microphone shows up again: open Control Center right away. Its microphone indicator names the app that just used the mic.
The focus log, especially the element or window that gets focus right after the composer loses it.

focus-loss-github-cropped-20261029.mp4

Thanks for the additional testing and the link to #21954. Reattaching the video in a ZIP containing the 2.53 MB MP4, cropped to hide unrelated projects. Safari did not complete the direct MP4 upload, but the ZIP uploaded successfully. The full 45 seconds and audio are preserved.

After reading #21954, the hidden-browser/cross-thread case looks relevant. Our saved desktop trace contains PreviewManager.emitAgentPointer followed shortly by PreviewManager.handleHumanInput around the reported incidents, including at 10:28:54 UTC / 12:28:54 Bucharest on October 29. That is consistent with the trace pattern reported there, but we have not mapped it to a specific thread or preview_click, or established where focus went. The trace event names alone do not prove the cause.

One clarification to my earlier comment: the first loss happened before the investigating agent interacted with the UI, but that does not rule out Browser activity from another running thread. Later interruptions also overlapped with that agent's attempts to inspect the UI, so those are not clean independent reproductions.

Desktop build: 0.1.4-nightly.20261029.3853 (783581d461dc), macOS. The focus-event logger had stopped after an app restart and missed these incidents. We reactivated and verified it at 12:58 Bucharest.

I'll keep investigating and try to capture the next loss with matching focus logs, check Browser activity across all threads, and identify the element or window that receives focus. If the blue microphone icon returns, I'll check Control Center as suggested.

Download the cropped recording (ZIP)

Thanks for pointing me toward #21954, and sorry for sending you down the notifications path. I assumed that was the trigger from what I’d observed, but the logs now point toward browser activity.

We captured five more focus losses today around 18:07–18:08 Bucharest while I was using Dictation. Each time, focus moved from the composer to a WEBVIEW, about 150–176 ms after an agent browser pointer event. Another thread was making browser clicks at those same times, and T3 remained the foreground app.

This looks very consistent with #21954. I can’t establish that every earlier occurrence had the same cause, but we finally have logs showing where focus went. Thanks for your patience and for investigating. I’ll keep the recorder running to catch further occurrences.

I guess we can make this a duplicate. Hope the evidence helps in any way.

Thank you!

focus-evidence-20261029-1808.zip

Thanks, the focus log settles it. I checked focus-evidence-20261029-1808.zip against the code:

All five losses (16:06:58–16:08:19 UTC) put focus on a WEBVIEW 150–176 ms after an agent pointer event.
browser-tool-timing shows another thread running preview_act clicks on a tab with visible: false at those same times. The first click completes at 16:06:58.415, about 26 ms after focus moved.

That's https://git.cafe/pingdotgg/t3code/issues/21954: an agent click in the Browser moves focus out of the composer, even from another thread and a hidden tab. https://git.cafe/pingdotgg/t3code/issues/21954 is still open, and none of the 29 commits on main since your build (783581d461dc) touch preview focus. The one open PR in this area (#15091) covers Tab/Shift+Tab only, not clicks.

Closing as a duplicate of https://git.cafe/pingdotgg/t3code/issues/21954, so follow that issue for the fix. If a focus loss ever shows up with no preview_act click or other browser input in any thread around it, open a new issue with that log.

Navigation Menu

Repository navigation

In-app thread notifications blur the composer during macOS dictation #24028

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

In-app thread notifications blur the composer during macOS dictation #24028

Description

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

Activity

shivamhwp commented on Oct 23, 2026

juliusmarminge commented on Oct 27, 2026

MrNagy21 commented on Oct 27, 2026

juliusmarminge commented on Oct 28, 2026

MrNagy21 commented on Oct 29, 2026

juliusmarminge commented on Oct 29, 2026

MrNagy21 commented on Oct 29, 2026

MrNagy21 commented on Oct 29, 2026

juliusmarminge commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions