[Bug]: SnapShots keep triggering while typing even though the feature is turned off (stable 0.0.42, macOS) #12769

Activity

1. gabbywelson commented on Sep 20, 2026

   

   gabbywelson

   on Sep 20, 2026

   Author

   More actions

   Screenshots of the huge stack of Snapshot notifications. This keeps happening even when the app is in the background with zero interaction

   
2. juliusmarminge commented on Sep 20, 2026

   

   juliusmarminge

   on Sep 20, 2026

   Member

   More actions

   Triage

   Confirmed against current main. This is a real desktop SnapShot bug, still present, and not a “settings failed to save” issue.

   client-settings.json with snapShotEnabled: false is doing what it should. The remaining flood is leftover pending captures plus a renderer coordinator that never looks at that flag.

   What the traces and screenshots show

   The two captures in today’s desktop trace (10:27:21, 11:14:09) are real shortcut captures (desktop.snapShot.shortcutActivated → capture → persistCapture). The second one sits next to checkShortcut, so it happened while Settings was still checking/recording the both-Shift pair, i.e. while the feature was still on.

   After the last applySettings / configure at 11:32:48 there are no further shortcutActivated / capture spans. That matches applySettings: when snapShotEnabled flips off it calls releaseShortcut() (kills the macOS osascript both-Shift poller) and capture() fails closed.

   The symptoms that continue after that — sound, motion, and the toast stack, including with the app in the background — are a second path:

   SnapShotCoordinator is always mounted in __root.tsx. It is not gated on snapShotEnabled. On mount, focus, visibility, "ready", and any effect-dep change (thread/draft store updates count, even in the background) it calls listPendingSnapShots(). That is the 150+ desktop:list-pending-snap-shots polls with the feature off.

   For each pending file it:

   1. Plays the capture sound (playCaptureSound) before it knows whether delivery can succeed.
   2. If there is no attach target, toasts Snapshot taken, but no project is available / Add a project, then capture the window again.
   3. Does not acknowledge the file, and removes the id from the “already sounded” set.

   So the same leftover ~/.t3/userdata/snap-shots/*.json is retried forever. Each retry is another whoosh + another toast. The screenshots on this issue are exactly that toast, on Settings → SnapShots with the toggle off.

   On the Settings route there is no thread/draft, so resolveExistingSnapShotTarget often misses, and if defaultProjectRef is empty the coordinator takes the “no project” branch every time.

   Docs say turning capture off releases the shortcut. The main process does that. The renderer does not stop draining, sounding, or toasting.

   Not a duplicate

   • fix(desktop): ignore snapshot shortcut repeats during flight #11037 — ignore shortcut repeats while a capture is in flight. Different bug.
   • fix(web): attach SnapShots to the open question instead of the hidden composer #12293 — attach to the open question instead of a hidden composer. Different delivery target.
   • fix(desktop): restore SnapShot shortcuts after portal restarts #11495 / fix(desktop): enable SnapShots shortcuts on GNOME 45–47 #12596 — Linux portal/GNOME shortcut registration. Not this macOS disable path.

   No open issue or PR covers “disabled SnapShots still toast/sound from leftover pendings.” DesktopSnapShot.ts / SnapShotCoordinator.tsx are unchanged in the relevant paths since v0.0.42.

   Suggested fix

   1. Gate SnapShotCoordinator drain / sound / toast on snapShotEnabled. When the flag is off, do not listPending on every chat-state effect, and do not play capture feedback.
   2. On disable (or on the “no project” / hard-fail path), either acknowledge/discard the pending files or back off. Do not continue after toasting and then immediately allow the same id to sound again.
   3. Add a macOS regression: configure({ snapShotEnabled: false }) must kill() the osascript both-Shift poller. Today we only assert teardown for Niri / Hyprland / portal.
   4. Optional: put enabled on desktop.snapShot.applySettings / configure spans, as the report asked. Would have made this trace one read.

   Workaround

   Fully quit T3 Code, then delete leftover captures under ~/.t3/userdata/snap-shots/ (*.json / *.png). Turning the toggle off is not enough while those files remain.

   Accepting as a desktop SnapShot bug.
3. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 20, 2026
4. cestercian commented on Sep 21, 2026

   

   cestercian

   on Sep 21, 2026

   Contributor

   More actions

   I'd like to take this — focused fix so the SnapShots shortcut listener is torn down when the feature is off.
5. cestercian commented on Sep 21, 2026

   

   cestercian

   on Sep 21, 2026

   Contributor

   More actions

   stepping back — #12775 already covers this