Increase default scrollback limit

[jumploops]

Switched from Warp recently and was surprised to discover that the default scrollback limit is just 10MB.

Working with long agentic flows, it's great to be able to go back in time (especially as Codex CLI and Claude Code continue to increase the number of turns they run before ceding control back to the user).

I'm guessing most developers have machines with a decent amount of RAM, so I want to propose two solutions:

1. Dynamically set scrollback limit based on available machine RAM (with some upper bound)
2. Increase the default scrolllback limit to 100MB (from 10MB)

Has anyone else run into this issue upon first install?

[rhodes-b]

you are free to change it yourself the default does not need changed
https://ghostty.org/docs/config/reference#scrollback-limit

It doesn't matter if most machines have alot of ram today that is a 10x increase. I often have 3 separate instances of ghostty with 5+ tabs or splits running at the same time in all 3

that means the scrollback resources went from 5 * 3 * 10 = 150MB to 5 * 3 * 100 = 1.5G that is a huge difference. 1G is a big factor for many people especially.

A real usecase from me. I compile large c++ projects frequently 1G is the difference of builds crashing from OOM or not crashing. They can already take upwards of a few mins to compile with 20+ cores. That is a huge sacrifice to my workflow

[pluiedev]

If you realize that most of the output is junk anyways, you should understand that under normal circumstances the output volume of a single command invocation shouldn't ever be near the order of magnitude of megabytes.

It's not a matter of "oh it's 2025 now, RAM is cheap" — but rather you're standing in a distinctly privileged and wasteful position that makes you unable to see how extravagant your resource requirements are. You have the freedom to set the limit at wherever you want given the sheer amount of resources at your disposal — though I do believe they should be used for something else — but this is not and will not be the case for the vast majority of people, even "in the year 2025".

[jumploops]

you're standing in a distinctly privileged and wasteful position that makes you unable to see [..]

Hey! I'm not trying to fight here! For context, I'm forcing myself to "vibecode" (and candidly it's a painful experience).

Currently using Claude Code (and now Codex CLI) to rebuild a personal tool I use everyday. By "force" I mean I'm not even looking at the code (like I said, painful!).

I was previously using Warp, and didn't have this issue. I was able to scroll back and read the output to figure out when and where the "agent" went completely off the rails. Switched to Ghostty when Warp hit a crash, hit this issue, and so I'm just trying to provide some honest feedback (problem -> solution, compared to other projects).

Happy to be wrong here, but I'm just pointing out an issue I experienced with a tool while using the "newest hot AI tech" in 2025. Thought it was a bug at first, but was surprised to find a 10MB limit when some of my Chrome tabs are easily 100s of MBs.

And to be clear: the actual problem was that the data was lost and I couldn't easily repro it, due to the non-deterministic nature of prompting LLMs. Had to reconfigure, restart, and then run until the issue was hit.

If anything, I hope we've added enough keywords for future users to discover this discussion.

[pluiedev]

You can't really compare a terminal, which at best stores perhaps hundreds of screenfuls of cells, styles, links, etc., with a modern-day behemoth like Chrome which has to store the entire DOM, all scripts and their runtimes, styles, caches, etc.

Plus, as I said in my other comment, if you really need this much scrollback, you should already tee it into a file which can be grepped or searched through with your favorite editor. It's much more preferable and easy to use compared to making every Ghostty surface hold a ton of scrollback, especially when you can't jump into the middle of the scrollback or search for keywords in it.

You're not obligated to always use what's "newest and latest" in tech, either. Heck, every terminal emulator has basically been the same basic design that dates back to the 1970s. Don't let "agentic workflows" take over human decision making.

[00-kat]

With that said, I think for most developers, Chrome is easily taking up GBs for seemingly no reason, but their machines can easily handle it.

Many I know are already strained for memory because of browsers like Chrome; adding another application that eats up memory like there's no tomorrow is just going to make it worse.

[FlorianWendelborn]

oh it's 2025 now, RAM is cheap

that aged very poorly 😄

[pluiedev]

My 2¢ is that if you ever find yourself needing more than 10MB of scrollback you should tee it into a file. It's especially strange to me that you need such a large scrollback given Ghostty doesn't yet have a scrollbar or scrollback search, and it takes quite a while to scroll back through 10 megabytes of data with just your scroll wheel.

Maybe this will make sense once #111 and #189 are in place, but I think 10MB is more than overkill for the vast majority of users. You're always free to change the limit for your personal config.

[jumploops]

My 2¢ is that if you ever find yourself needing more than 10MB of scrollback you should tee it into a file.

For more context, the usecase is specifically Claude Code/Codex CLI + a running dev environment.

For any manually scripting, I'll certainly lean to specific files for capturing output.

In the case of LLM-assisted development, I don't want to load my local FS with a bunch of useless logs and then manually manage the files.

Because of the multi-turn nature and ability to affect the local dev output, a single user<>assistant turn can result in logs that blow way past the 10MB limit.

A single 32GB-128GB RAM dev machine will happily use 100s of MBs per Chrome tab. I'm not suggesting that this is good per se, it's just that the average hardware has a lot more capacity than a machine built 20 years ago.

given Ghostty doesn't yet have a scrollbar or scrollback search

This is something I would fix if I had more time!

[pluiedev]

This doesn't change the fact that with any other workflow 10MB is plenty enough, maybe even more than enough. This may surprise you, but not every Ghostty user has access to 32 gigs of RAM or more. In fact we have received "bug reports" from memory-constrained users that Ghostty has "memory leaks" when in reality it's their scrollback that is starting to consume more and more memory.

Again, the point isn't that you have to stick with the 10MB limit. We made it configurable for a good reason. The point is that your requirements don't match the needs of most people, for whom it's very rare to even reach 10MB. Even Mitchell, who uses coding agents somewhat often, never had to scroll back more than 10MB.

If you find yourself needing more scrollback, that's totally fine — but pretending that that's desirable for every single user, whether they use LLMs or not, is heavily misguided in my opinion.

[hworld]

I'll throw another use-case into the discussion. I just hit this issue while trying to do a system upgrade (to Fedora 43 beta). Lots of package updates, and DNF put the deleted/downgraded packages at the top of the list, which was cut off. Not so common to do a major system update like this.

I had to look for the scrollback-limit config in order to actually see what was going to be happening to my system during an update. A little frustrating, but I think with a settings UI it wouldn't have been too bad, since I could easily find the option through the program.

I think the biggest frustration I had was that I didn't quickly know how to see what the default was for scrollback-limit, so I had no clue what to set the buffer to. I didn't see a default listed on the option reference. Not sure if it's listed there and I just can't find.

Also, I have a free spinning scroll wheel, so it was pretty easy to get to the top of scrollback buffer. Just bringing it up since it was assumed to be hard to go far back without a scrollbar. Just depends on the mouse.

I'm not for updating the default, but maybe this is helpful user experience feedback for future changes to the app. Loving ghostty (especially 1.2.0 with the more stable font rendering).

Edit: Found how to see the defaults for config options: ghostty +show-config --default | grep scrollback-limit

[shurane]

I guess there's a plan for unlimited scrollback-limit. But can't we just persist stuff beyond scrollback-limit to disk and then pull it in as you scroll up via mmap() or something? Then can limit the total amount of scrollback overflow on disk to 100MB or whatever as a good default.

[jcollie]

Persisting scrollback to disk has certainly been discussed. I'd say that it's likely to be eventually be implemented but it's not a high priority to anyone right now.