January 10, 2026
A few months ago, users started reporting that Ghostty was consuming absurd amounts of memory, with one user reporting 37 GB after 10 days of uptime. Today, I'm happy to say the fix has been found and merged. This post is an overview of what caused the leak, a look at some of Ghostty's internals, and some brief descriptions of how we tracked it down.1
The leak was present since at least Ghostty 1.0, but it is only recently that popular CLI applications (particularly Claude Code) started producing the correct conditions to trigger it at scale. The limited conditions that triggered the leak are what made it particularly tricky to diagnose.
The fix is merged and is available in tip/nightly releases, and will be part of the tagged 1.3 release in March.
The PageList
To understand the bug, we first need to understand how Ghostty manages terminal memory. Ghostty uses a data structure called the PageList to store terminal content. PageList is a doubly-linked list of memory pages that store the terminal content (characters, styles, hyperlinks, etc.).
PageList: A doubly-linked list of memory pages Page 1 oldest scrollback Page 2 Page 3 Page 4 newest active screen
The underlying "pages" are not single virtual memory pages but they are a contiguous block of memory aligned to page boundaries and composed of an even multiple of system pages.2
These pages are allocated using mmap . mmap isn't particularly fast, so to avoid constant syscalls, we use a memory pool. When we need a new page, we pull from the pool. When we're done with a page, we return it to the pool for reuse.
The pool uses a standard size for pages. Think of it like buying standard-sized shipping boxes: most things people ship fit in a standard box, and having a standard box comes with various efficiencies.
... continue reading