Crash Reports

When Wintty crashes, it writes a crash report to disk before exiting. The report is a self-contained file you can inspect locally or attach to a bug report. Reports are saved by default and never uploaded automatically: you decide whether to share them.

Reports are written to the Wintty state directory under ghostty/crash:

Platform	Path
Linux	$XDG_STATE_HOME/ghostty/crash, falling back to ~/.local/state/ghostty/crash
Windows	%LOCALAPPDATA%\ghostty\crash

The directory is created on first crash. Each crash produces a separate file, named by timestamp, so older reports are preserved.

You can browse the directory directly, or use the crash-report subcommand to list what is there:

wintty crash-report

wintty +crash-report does the same thing. The + form is inherited from Ghostty and still works everywhere the bare verb does.

The list shows each report's filename and how long ago it was written, newest first. Use it to find a recent crash, then copy the file off-machine or attach it to a GitHub issue.

Note

Listing is all the subcommand does today. Viewing a report's contents and sending one from the command line are not implemented yet, so read the file directly if you want to see what is in it.

Crash reports use the Sentry envelope format internally. They contain:

• Wintty version and build info
• The platform and OS version
• The thread that crashed and a stack trace
• A breadcrumb log of recent events (config reloads, focus changes, etc.) leading up to the crash
• The crash type (assertion failure, segfault, panic, etc.)

Reports do not include the contents of your terminal scrollback, your config file contents, or your environment variables. The data collected is intended to be enough to debug a crash without exposing arbitrary state from your system.

Note

Even with these safeguards, take a look at a crash report before posting it publicly. Stack traces can occasionally include file paths (such as the path to a font you have installed) that you may consider private.

Crash report uploading is opt-in. Wintty will never send a crash report without your action. The recommended workflow is:

1. Reproduce the crash and locate the latest report in the crash directory.
2. Open a new issue at github.com/deblasis/wintty describing what you were doing when the crash happened.
3. Attach the report file (drag-and-drop into the GitHub comment box, or paste the contents in a fenced code block).

Including the report file gives the maintainers the stack trace they need to diagnose the crash.

For testing crash report capture, the crash action will deliberately crash Wintty. You can wire it to a keybinding or include it in a command palette entry:

command-palette-entry = title:Crash on Main Thread, description:Causes a crash on the main (UI) thread., action:crash:main

This is mostly useful for development. There's no reason to trigger it in normal use.

There is currently no configuration to disable crash reporting (because reports are written locally and never uploaded automatically). You can delete files from the crash directory at any time if you don't want to keep them.