Logs & Crash Reports
Where Kunkun keeps its local logs and crash reports, how to read them after a crash, and how to attach a diagnostic bundle to a bug report.
Kunkun records what it's doing to local log files on your machine, and it records its own crashes — including native crashes that would otherwise leave no trace. This page explains where those files live and how to use them when something goes wrong.
Local logs and crash dumps stay on your device. Kunkun does not upload them anywhere — you decide what to share when you file a bug.
The easy way: Settings → Logs
Open Settings → Logs in the app. From there you can:
- Open the logs folder in your file manager.
- Search and filter recent log entries by level and text.
- Export a diagnostic bundle — a single file to attach to a bug report.
If you can open the app at all, this is the fastest path.
Where the files are
Logs are written to a logs/ folder inside Kunkun's user-data directory, one file per day named YYYY-MM-DD.kunkun.jsonl (JSON Lines — one event per line). Local logging is on by default.
| OS | Logs folder |
|---|---|
| macOS | ~/Library/Application Support/Kunkun/logs/ |
| Windows | %APPDATA%\Kunkun\logs\ |
| Linux | ~/.config/Kunkun/logs/ |
Native crash dumps (minidumps) are written to a separate crash-dumps folder in the same user-data directory. You rarely need to find it by hand — when a crash is detected, the log points at the exact minidump path (see below).
After a crash: what to look for
A native crash kills the process before it can finish writing, so the crash itself shows up on the next launch, not in the session that died. When you reopen Kunkun, the log records what happened to the previous session.
Search the current day's log for these markers:
# macOS example
grep -i "Previous session\|process-gone\|crash-observability" \
~/Library/Application\ Support/Kunkun/logs/$(date +%F).kunkun.jsonlWhat you might see, and what it means:
| Log message | Meaning | Where the details are |
|---|---|---|
Previous session ended on an uncaught main-process exception | A JavaScript error crashed the app | The full stack is in the log entry |
Previous session terminated abnormally (no JS exception captured) | A native crash, forced kill, or power loss | Open the minidump path in the log entry, or your OS crash report |
render-process-gone | A window's renderer died | reason / exitCode in the entry |
child-process-gone | A helper process (utility/GPU) died | type / reason in the entry |
The render-process-gone and child-process-gone entries are recorded live, in the same session — you don't need to relaunch for those.
On macOS, native crashes are also captured by the system at ~/Library/Logs/DiagnosticReports/ (files named like Electron-*.ips). That's the deepest source of truth for a native crash stack.
Filing a bug report
The most useful thing you can attach is a diagnostic bundle: open Settings → Logs → Export diagnostic bundle. It packages the recent logs (and crash markers) into one file. Attach that to your issue instead of copying individual lines.
For extension developers
When running the desktop app from a terminal in development, crash and fault lines are also printed to that terminal in real time (prefixed [Crash]), so you don't have to wait for the next launch or open a log file. Worker-view and headless plugins can additionally be exercised without the full app — see the plugin testing guide for the headless smoke harness.