[BUG] Kaku sometimes quits cleanly without a crash report

[Sure-Will]

Summary

Kaku sometimes disappears without a crash dialog, and the retained macOS logs suggest it is exiting through a normal quit path rather than crashing.

Steps to reproduce

I do not have stable reproduction steps yet.

Observed twice so far:

• 2026-03-16 12:55:03 +0800
• 2026-03-20 17:19:59 +0800

In both cases, Kaku disappeared unexpectedly while I was using the machine. On the second occurrence, I manually reopened it later at around 2026-03-20 17:44 +0800.

Expected vs actual

• Expected: Kaku should remain open unless I explicitly quit it.
• Actual: Kaku sometimes disappears unexpectedly, but system logs show a clean quit path instead of a crash.

Environment

• Kaku version: 0.7.1
• macOS version: 26.3.1 (25D2128)
• Machine: Apple Silicon (arm64)
• Shell: zsh

Optional details

What I checked locally:

• My user config does not override quit/close behavior; it only loads bundled defaults.
• /Applications/Kaku.app was not updated on the incident day. Current app bundle mtime is 2026-03-14 22:14:17 +0800.
• There is no Kaku crash report in ~/Library/Logs/DiagnosticReports or ~/Library/Logs/CrashReporter.

Relevant logs for the most recent incident (2026-03-20 17:19:59 +0800):

• 17:19:59.850 WindowServer: a kCGSEventKeyDown was still being delivered to Kaku (pid 66786)
• 17:19:59.937 WindowServer: Process death ... (Kaku) ... pid: 66786
• 17:19:59.937 kaku-gui: Entering exit handler.
• 17:19:59.957 runningboardd: termination reported by launchd (0, 0, 0)
• 17:19:59.959 launchservicesd: QUITTING: pid=66786

An earlier retained occurrence looks similar:

• 2026-03-16 12:55:03.528 runningboardd: Kaku (pid 23148) termination reported by launchd (0, 0, 0)
• 2026-03-16 12:55:03.522 WindowServer: closing Kaku connection for pid 23148
• 2026-03-16 12:55:23.660 launchservicesd: a new Kaku instance (pid 34270) checked in

Why this looks suspicious:

• This does not look like a crash.
• This does not look like an app update/replacement.
• It looks more like Kaku unexpectedly entered a normal quit path while focused.

One config detail that may matter:

• bundled config maps Cmd+Q to QuitApplication
• bundled config maps Cmd+W to HideApplication when only one window/tab remains
• bundled config sets quit_when_all_windows_are_closed = false

So the observed process death matches a quit path much more than a simple hide/close-window path.

Questions:

1. Is there any known path in Kaku / WezTerm on macOS that can unexpectedly trigger QuitApplication while the app is focused?
2. Could focus switching, IME/input-method interaction, or a specific macOS lifecycle callback lead to this?
3. Would it be possible to add more explicit logging for quit origin (keyboard shortcut, menu action, internal callback, etc.)?

[tw93]

@Sure-Will

I finished the macOS-side observability work for this issue. The next update will include explicit quit-origin logging for the main clean-exit paths, including AppKit terminate, app-scope QuitApplication, window-scope QuitApplication, and the confirm-quit overlay, together with window/fullscreen context.

This does not change the default quit behavior yet. The goal of this pass is to make this class of clean exits diagnosable if it happens again, especially around focus switching, IME state, or an unexpected quit path.

Please wait for the next update and try again after upgrading. If you still see the same behavior after updating, please reopen this issue with the new logs and I will continue from there.