Add real background/tray mode (don't kill agent sessions on window close) #2412

Activity

1. baxen

   added a parent issue on Jul 23, 2026

   • Windows Support #2388
2. mgonzalezdidesa commented on Jul 24, 2026

   

   mgonzalezdidesa

   on Jul 24, 2026

   More actions

   Confirming this on macOS 15 (Darwin 25.5.0), Buzz Desktop, Apple Silicon — so it isn't Windows-specific. Same behavior, same cause, and I have unified-log evidence for the exact sequence.

   A user clicked the red close button while several agent sessions were running. The app terminated ~3.3 s later, taking every session with it. From log show --predicate 'processIdentifier == 70488' (buzz-desktop):

   19:39:15.008  (AppKit) trackMouse send action on mouseUp
   19:39:15.009  window <TaoWindow: 0x7fc9b2613b70> windowNumber=1abf windowShouldClose: prevented close
   19:39:18.457  CMIO_DAL_CMIOExtension_PlugIn.mm ... AtExit has already fired
   19:39:18.466  [com.apple.CoreAnalytics:client] Entering exit handler.
   19:39:18.466  [com.apple.CoreAnalytics:client] Exiting exit handler.
   

   Two things worth noting in that trace:

   1. windowShouldClose: prevented close — the Tauri window (TaoWindow) does intercept the AppKit close, so the hook is already there. It just proceeds to tear down the whole process instead of hiding the window. The interception point needed to fix this exists today.
   2. The exit is clean — atexit handlers ran, window state was persisted. This is a deliberate exit(), not a crash. No .ips crash report is generated, which is also why it looks to the user like the app "closed itself for no reason."

   Filtering the full hour before the exit for the same event, there was exactly one trackMouse / windowShouldClose pair, and no miniaturize event — so the close path is unambiguously what fired.

   The ergonomics angle, which I think raises the severity: on macOS the red close button sits ~20 px from the yellow minimize button. As @abduosmanaj notes, minimize keeps everything alive and close destroys everything — with no dialog, no undo, and no crash report to explain it afterwards. In our case the user was aiming for minimize. A 20-pixel miss silently killed in-flight agent work.

   So there are really two fixes, and the cheap one is worth doing even before the tray work:

   • Short term: when one or more agent sessions are active, intercept the close (the prevented close hook above already fires) and show a confirmation — "N agent sessions are running. Quit anyway?" Most apps with work in progress do this, and it turns a destructive misclick into a recoverable one.
   • Long term: the real background/tray mode this issue asks for.

   Happy to test a patch on macOS if that's useful.
3. jhedlund

   added a commit that references this issue on Aug 31, 2026

   feat(desktop): keep Buzz running in the Windows tray on window close

   ...

   fb1f76a
4. nikeruga commented on Sep 7, 2026

   

   nikeruga

   on Sep 7, 2026

   More actions

   기능 요청: Windows 시스템 트레이 상주와 백그라운드 알림

   Windows에서 Buzz를 업무용 메신저처럼 사용할 수 있도록 다음 동작을 요청합니다.

   1. ‘닫을 때 시스템 트레이로 숨기기’ 옵션을 제공해 주세요. 활성화한 경우 X 버튼은 창만 숨기고 메시지 수신을 유지해야 합니다.
   2. 시계 옆 시스템 트레이 아이콘에서 ‘Buzz 열기’와 ‘완전 종료(Quit)’를 제공해 주세요.
   3. 창이 숨겨진 상태에서도 사용자가 허용한 멘션·DM·참여 스레드 답글이 Windows 알림으로 전달되고, 알림 클릭 시 해당 대화가 열리게 해 주세요. 음소거와 알림 해제 선택은 존중해야 합니다.
   4. 트레이 설정과 알림 설정을 앱 재실행 후에도 유지하고, 명시적 Quit이나 Windows 종료·업데이트는 정상 처리해 주세요.

   검증 시나리오: X로 숨기기 → 새 멘션 알림 수신 → 알림 클릭으로 대화 열기 → 재실행 후 설정 유지 → Quit으로 실제 종료.

   트레이 제안 #6893과 알림 관련 #2445, #4660, #7275, #6876을 함께 검토해 주시면 좋겠습니다. 트레이 상주와 알림 권한 처리는 별개이므로 두 기능 모두 정상이어야 위 흐름이 완성됩니다.

   중복 이슈 대신 기존 요청에 필요한 동작을 추가합니다. 감사합니다.