Crash Reports

Find crash logs and report crashes with the details needed to investigate them.

Crash logs

GitComet records Rust panics, runtime errors, and recovery information for sessions that ended unexpectedly. Logs are stored in:

Linux: $XDG_STATE_HOME/gitcomet/crashes/ (fallback: ~/.local/state/gitcomet/crashes/)
macOS: ~/Library/Logs/gitcomet/crashes/
Windows: %LOCALAPPDATA%\gitcomet\crashes\ (fallback: %APPDATA%\gitcomet\crashes\)

File	What it contains
`panic-*.log`	Rust panic details and a backtrace.
`session-in-progress-<pid>.log`	A process-specific session marker. It can remain after a native abort, terminated process, or unexpected UI exit.
`last-runtime-error-<pid>.log`	The most recent error-level runtime diagnostic, including its source location and a backtrace.
`pending-startup-report.log`	Recovered crash information kept for the next startup notification.

A session marker can belong to a still-running GitComet instance. Recovery ignores those instances instead of treating them as crashes.

Report a crash

Launch GitComet again. The next UI launch presents the recovered report; if you launched from a terminal, GitComet also prints the prefilled issue URL and log path there.
Open the report and review the prefilled GitHub issue. It includes the application version, platform, failure details, and a trimmed backtrace.
Add the steps that led to the crash and the action you were performing. Include the installation method and relevant repository characteristics, such as a large diff or an active merge.
Review any paths or other sensitive details before submitting the issue, and attach the relevant log if needed.

GitComet keeps pending-startup-report.log until you report or dismiss the notification. A failed subsequent launch does not discard the pending report.

If the app cannot stay open long enough to show a notification, open the log directory directly and create an issue manually with the same details.