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

[T3sT3ro]

Yup, very similar use case: journalctl -b -1 --no-pager for investigating logs since the boot.

Right now working with having to eyeball the limit is pretty painful, especially because the limit is given in bytes, so you have to do mental calculation of "ok, so 10k lines, at wha average line width and times what average size per character?" Other terminals have scrollback buffer config set with the number of lines, so I can easily understand what I'm working with.

Not to mention that it incomprehensible to me how this limit is enforced and how it's calculated:
On a fullscreen terminal (239x56) if I set scrollback-limit = 10000000 (10e7) and I use for i in {0..5000}; do echo $i: $i $i $i $i $i $i $i $i; done I can scroll back to 1744, and when I do for i in {0..5000}; do echo $i; done I can scroll back to... 1785??? Which is less lines even though there is less text to print??? Am I misunderstanding something??? Now after I decrease the terminal size to 50x20, clear it and use the second for loop again I can now suddenly scroll to the beginning?! Does the terminal store zeroes for empty cells in the buffer or what???

The setting and behavior are very confusing.

[pluiedev]

There's something you should use for this use case: it's called a pager. And you seem to be aware of this too, given how you manually turned on --no-pager to even justify why this is necessary.

Just use a pager.

[T3sT3ro]

That's... valid... It may have been a poorly chosen example originating in the fact that I may have misconfigured pager or terminal (or defaults are bad?), which doesn't scroll on wheel but rather scrolls terminal, so I just default to long scrollback and CTRL+F in terminal directly.

Nevertheless, a case where you have a long-running task which requires interactive user input, for instance do-release-upgrade, may be a better fit. Sometimes you may also not know before hand if the toool you are running will spam your console with thousands of lines and require interaction.

Also I must admit that I was far more concerned with the second part — the ease and inttuitiveness of configurability — the default doesn't really concern me much. I would just want some intuitive way to set scrollback buffer like I could for instance in gnome terminal — by setting number of lines instead of bytes (also a PITA that I can't use SI units for size :/). As for the amount I always set the scrollback to 10k and never again thought about scrollback buffer consciously afterwards.

[pluiedev]

I would just want some intuitive way to set scrollback buffer like I could for instance in gnome terminal — by setting number of lines instead of bytes

I agree this is something that could probably be improved, but that's not really the subject of this discussion — open a new discussion if you have more input.

SI units for size

Fair enough, that's definitely something we can consider (along with KiB vs KB, GiB vs GB, etc). We already do this for e.g. durations. Still not what this discussion is about, though

[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.

[marcelovital]

For me, scrollback-limit doesn't even work. No matter what I put in there, a very small or a very large number, the output is still the same. I lose a lot of information when doing something like a terraform plan on a large infrastructure. Each person's use case and the "you should not have a large scrollback buffer" shouldn't be the point here.
I'm running in macOS, v1.2.3, installed via brew.
The settings file is located in ~/Library/Application Support/com.mitchellh.ghostty/config , as described in the documentation and tested by me. If I put any invalid key in that file, Ghostty complains.
There is #9982 which doesn't seem to have clarified this. Isn't there anyone else having this issue?

[pluiedev]

Please open a new discussion with the proper requisite details.

[T3sT3ro]

After changing it reopen the terminal tab. I suspect the buffer is allocated on start. I also dont see a difference if I run in the same one, but after I create new it does change.

[jvican]

If you came here looking for a way to set your own default, set it as such:

The scrollback-limit as of Feb 2026 is 10000000, and to set it to triple that:

scrollback-limit = 30000000

P.S. automatic Google AI search results suggested me to set it by setting the same option to "30MB" as the option value, which is an invalid value and will fail.

[T3sT3ro]

I set mine to 200000000 (200_000_000) which lets me confortably read journal logs since last boot at fullscreen terminal size (journalctl -b -1 --no-pager).

[jadeops]

what's the config to set it to "Unlimited Scrollback" like xfce4-terminal ?

eg:

cd /
tree -a

# I want this entire thing to be viewable on ghostty. xfce4-terminal handles this fine.

[pluiedev]

Going to close this particular request (bumping the default scrollback limit) as not planned.

However, just to affirm/reject some other related requests brought up here (note: for requests marked "yes", please open new discussions so we can discuss them further):

• Scrollback persisted to disk: Yes, we just need to come up with a format that's both efficient and forward-compatible (or at least, migratable) so that old scrollback data is still usable in new terminal versions.

• "Unlimited scrollback" i.e. automagically loading previous scrollback from disk: Maybe. That would need some architectural work on our internal PageList implementation, but maybe it can be done. We appreciate ideas and proposals for how it should work.

• Better/more intuitive UX for scrollback-limit

  • SI units: Yes.
  • Lines instead of bytes: Maybe. Would need some internal plumbing.

• Increasing the default scrollback limit just because you can't use a pager or "memory is cheap and I have lots of it": no.