Feature: Add support for Infinite Scrollback #1884

@JushBJJ commented on GitHub (Jun 22, 2019):

Would the buffer content be stored inside a file?

@JushBJJ commented on GitHub (Jun 22, 2019): Would the buffer content be stored inside a file?

claunia commented

@egmontkob commented on GitHub (Jun 24, 2019):

In GNOME Terminal (VTE) we store the scrollback in a compressed and encrypted file. Storing it in memory could easily result in heavy swapping, followed by the OOM killer kicking in. We store it on disk even if it's configured to have a finite size.

The file is unlinked immediately after creating it, so it's freed up in the unlikely case that gnome-terminal (or another VTE-based terminal) crashes. During normal operation, the file handle is released (and thus the file contents get freed up) and encryption key is explicitly zeroed out in the memory when the terminal tab/window is closed.

We used to store it in unencrypted file, but people were worried about privacy / data leakage issues e.g. if the computer gets stolen, see e.g. a generic security report and the tracking bug. (A nice extension would be if we could detect if the file system is encrypted and then skip this step.)

Konsole, on the other hand, warns you in its config dialog that "When using [unlimited scrollback], the scrollback data will be written unencrypted to temporary files." If fixed scrollback is configured, Konsole stores it in memory (and again, informs the user about it and the corresponding risks).

@egmontkob commented on GitHub (Jun 24, 2019): In GNOME Terminal (VTE) we store the scrollback in a compressed and encrypted file. Storing it in memory could easily result in heavy swapping, followed by the OOM killer kicking in. We store it on disk even if it's configured to have a finite size. The file is unlinked immediately after creating it, so it's freed up in the unlikely case that gnome-terminal (or another VTE-based terminal) crashes. During normal operation, the file handle is released (and thus the file contents get freed up) and encryption key is explicitly zeroed out in the memory when the terminal tab/window is closed. We used to store it in unencrypted file, but people were worried about privacy / data leakage issues e.g. if the computer gets stolen, see e.g. a [generic security report](http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html) and the [tracking bug](https://bugzilla.gnome.org/show_bug.cgi?id=664611). (A nice extension would be if we could detect if the file system is encrypted and then skip this step.) Konsole, on the other hand, warns you in its config dialog that "When using [unlimited scrollback], the scrollback data will be written unencrypted to temporary files." If fixed scrollback is configured, Konsole stores it in memory (and again, informs the user about it and the corresponding risks).

claunia commented

@davidbIQ commented on GitHub (Sep 4, 2020):

As an easy first step is to allow a rightclick on the tab and have an option there for scrollback lines that would just apply to that tab. Then it's all in memory and fully up to the user to choose a reasonable amount (some in memory compression might be nice but likely optional). It gets around all the security issues, and other issues if you default it to every terminal that are left open for weeks - you could auto-change the tab color so they're aware that it's different than normal.

@davidbIQ commented on GitHub (Sep 4, 2020): As an easy first step is to allow a rightclick on the tab and have an option there for scrollback lines that would just apply to that tab. Then it's all in memory and fully up to the user to choose a reasonable amount (some in memory compression might be nice but likely optional). It gets around all the security issues, and other issues if you default it to every terminal that are left open for weeks - you could auto-change the tab color so they're aware that it's different than normal.

claunia commented

@naikel commented on GitHub (Jan 12, 2021):

This is a massive change.

The TextBuffer is limited to COORD coordinates which they are of short type (32767 max). Only to enable "virtual" coordinates of the TextBuffer means to change more than half of the code.

So I guess the first approach would be to change COORD to til::point, SIZE to til::size, and RECT & SMALL_RECT to... well good question. SMALL_RECT is inclusive and that could be translated to a til::rectangle. But RECT? Then you would have to call Viewport::ToInclusive() ?

It's easier to first support TextBuffer >= 32768 lines and then implement the infinite scrollback.

Buy from my perspective I think everything has to be changed, GDI renderers, UI Automation types, everything.

@naikel commented on GitHub (Jan 12, 2021): This is a **massive** change. The TextBuffer is limited to COORD coordinates which they are of short type (32767 max). Only to enable "virtual" coordinates of the TextBuffer means to change more than half of the code. So I guess the first approach would be to change COORD to til::point, SIZE to til::size, and RECT & SMALL_RECT to... well good question. SMALL_RECT is inclusive and that could be translated to a til::rectangle. But RECT? Then you would have to call Viewport::ToInclusive() ? It's easier to first support TextBuffer >= 32768 lines and then implement the infinite scrollback. Buy from my perspective I think everything has to be changed, GDI renderers, UI Automation types, everything.

claunia commented

@j4james commented on GitHub (Jan 15, 2021):

I don't think it should be necessary to replace the short ints everywhere (you're not going to be able to change the parameters of the legacy console APIs anyway). I reckon you could leave the in-memory buffer with a short limit, and just persist the oldest lines to disk whenever it is about to cycle. Then the only major complication is getting the scrollback viewer to page that data back into memory when the user scrolls past the top of the buffer. That's got to be easier than trying to rewrite everything with new types.

@j4james commented on GitHub (Jan 15, 2021): I don't think it should be necessary to replace the short ints everywhere (you're not going to be able to change the parameters of the legacy console APIs anyway). I reckon you could leave the in-memory buffer with a short limit, and just persist the oldest lines to disk whenever it is about to cycle. Then the only major complication is getting the scrollback viewer to page that data back into memory when the user scrolls past the top of the buffer. That's got to be easier than trying to rewrite _everything_ with new types.

claunia commented

@naikel commented on GitHub (Jan 15, 2021):

I reckon you could leave the in-memory buffer with a short limit, and just persist the oldest lines to disk whenever it is about to cycle.

You still need the virtual position to be at least a LONG (but a til::point will be better). The Viewport "moves" around this TextBuffer using these coordinates. Even if the buffer is not complete in memory and it is on disk, you need to know where in the buffer you are. The resulting screen has to be SHORT since like you're saying it is calling an API that only accepts that.

That still means changing everything except probably GdiEngine.

@naikel commented on GitHub (Jan 15, 2021): > I reckon you could leave the in-memory buffer with a short limit, and just persist the oldest lines to disk whenever it is about to cycle. You still need the virtual position to be at least a LONG (but a til::point will be better). The Viewport "moves" around this TextBuffer using these coordinates. Even if the buffer is not complete in memory and it is on disk, you need to know where in the buffer you are. The resulting screen has to be SHORT since like you're saying it is calling an API that only accepts that. That still means changing everything except probably GdiEngine.

claunia commented

@j4james commented on GitHub (Jan 15, 2021):

You still need the virtual position to be at least a LONG

But that's the only thing that needs to be LONG. The in-memory buffer really just needs to be the size of the visible viewport, with the relevant section of the on-disk buffer loaded into it.

Anyway, this was just a suggestion. Whoever is actually implementing this feature will no doubt have their own ideas on how to approach the problem. I just wouldn't recommend trying rewrite the entire conhost framework unless it was absolutely necessary, and I don't think it is.

@j4james commented on GitHub (Jan 15, 2021): > You still need the virtual position to be at least a LONG But that's the only thing that needs to be LONG. The in-memory buffer really just needs to be the size of the visible viewport, with the relevant section of the on-disk buffer loaded into it. Anyway, this was just a suggestion. Whoever is actually implementing this feature will no doubt have their own ideas on how to approach the problem. I just wouldn't recommend trying rewrite the entire conhost framework unless it was absolutely necessary, and I don't think it is.

claunia commented

@DSloaneNGPVAN commented on GitHub (Jun 24, 2021):

Infinity is a really big number - personally I would love to see a 10x or 100x increase, from the current 32767 max!
And/or a reference to 32767 in the https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#history-size documentation.
And/or an max value validation in the historySize field under Advanced Settings.

@DSloaneNGPVAN commented on GitHub (Jun 24, 2021): Infinity is a really big number - personally I would love to see a 10x or 100x increase, from the current 32767 max! And/or a reference to 32767 in the https://docs.microsoft.com/en-us/windows/terminal/customize-settings/profile-advanced#history-size documentation. And/or an max value validation in the historySize field under Advanced Settings.

claunia commented

@davidbIQ commented on GitHub (Jun 25, 2021):

yea, the way putty does it works very well, its default of 2000 lines and then if you need more you can set it higher I think I've put 2M in there before I know with certainty 200,000 works fine which is plenty. Regarding security of disk writes, I think if the windows not open the file not existing would be fine but I'm not a security expert, if it's an issue having it be encrypted shouldn't be much of an additional step as only that window would need to understand how to unencrypt.

@davidbIQ commented on GitHub (Jun 25, 2021): yea, the way putty does it works very well, its default of 2000 lines and then if you need more you can set it higher I think I've put 2M in there before I know with certainty 200,000 works fine which is plenty. Regarding security of disk writes, I think if the windows not open the file not existing would be fine but I'm not a security expert, if it's an issue having it be encrypted shouldn't be much of an additional step as only that window would need to understand how to unencrypt.

claunia commented

@ghost commented on GitHub (Dec 9, 2021):

I agree that this is an extremely useful feature that every proper terminal should have. Leaving a long verbose process running just to come back and see that most of the output was lost is very frustrating.

@ghost commented on GitHub (Dec 9, 2021): I agree that this is an extremely useful feature that every proper terminal should have. Leaving a long verbose process running just to come back and see that most of the output was lost is very frustrating.

claunia commented

@AkikoOrenji commented on GitHub (Jul 5, 2022):

for the love of god please fix this. You've provided an amazing terminal (finally comparable to linux apps) and then make it next to useless with no external logging or ability to have unlimited history (yes surely 'unlimited' is not that difficult to do in 2022). Back to Linux i suppose.....

@AkikoOrenji commented on GitHub (Jul 5, 2022): for the love of god please fix this. You've provided an amazing terminal (finally comparable to linux apps) and then make it next to useless with no external logging or ability to have unlimited history (yes surely 'unlimited' is not that difficult to do in 2022). Back to Linux i suppose.....

claunia commented

@CCCAUCHY commented on GitHub (Oct 28, 2023):

It is been long time.
Just make a log file feature please.

@CCCAUCHY commented on GitHub (Oct 28, 2023): It is been long time. Just make a log file feature please.

claunia commented

@martingalvan-volue commented on GitHub (Mar 19, 2024):

Hi, this issue still exists.

Tagging @DHowett-MSFT @carlos-zamora @zadjii-msft

@martingalvan-volue commented on GitHub (Mar 19, 2024): Hi, this issue still exists. Tagging @DHowett-MSFT @carlos-zamora @zadjii-msft

claunia commented

@zadjii-msft commented on GitHub (Mar 19, 2024):

Yep. We'll make sure to update this thread when there is an update to share. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

@zadjii-msft commented on GitHub (Mar 19, 2024): Yep. We'll make sure to update this thread when there is an update to share. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

claunia commented

@martingalvan-volue commented on GitHub (Mar 22, 2024):

Ah, I see the latest comments by me, @CCCAUCHY and @zadjii-msft have been marked as "spam" and "off-topic". Very nice.

@martingalvan-volue commented on GitHub (Mar 22, 2024): Ah, I see the latest comments by me, @CCCAUCHY and @zadjii-msft have been marked as "spam" and "off-topic". Very nice.

claunia commented

2026-01-30 22:41:01 +00:00

@zadjii-msft commented on GitHub (Mar 22, 2024):

Yep. There are plenty of people following the thread for updates. Just commenting stuff like "are there any updates", "this still hasn't been added", etc, sends everyone who's following the thread a notification, but doesn't really contribute to the discussion of how to actually implement this. I'm pretty liberal with collapsing comments to keep discussions on-topic.

@zadjii-msft commented on GitHub (Mar 22, 2024): Yep. There are plenty of people following the thread for updates. Just commenting stuff like "are there any updates", "this still hasn't been added", etc, sends everyone who's following the thread a notification, but doesn't _really_ contribute to the discussion of how to actually implement this. I'm pretty liberal with collapsing comments to keep discussions on-topic.

claunia commented

@martingalvan-volue commented on GitHub (Mar 22, 2024):

Yep. There are plenty of people following the thread for updates. Just commenting stuff like "are there any updates", "this still hasn't been added", etc, sends everyone who's following the thread a notification, but doesn't really contribute to the discussion of how to actually implement this. I'm pretty liberal with collapsing comments to keep discussions on-topic.

Ah, I didn't realize it was you who collapsed even your own comments. That is fine.

If there's a way to ping only MS maintainers without affecting all other readers of this, please let me know. Otherwise, I'm afraid that it will keep happening as people lose more time hitting this issue over and over.

@martingalvan-volue commented on GitHub (Mar 22, 2024): > Yep. There are plenty of people following the thread for updates. Just commenting stuff like "are there any updates", "this still hasn't been added", etc, sends everyone who's following the thread a notification, but doesn't _really_ contribute to the discussion of how to actually implement this. I'm pretty liberal with collapsing comments to keep discussions on-topic. Ah, I didn't realize it was you who collapsed even your own comments. That is fine. If there's a way to ping only MS maintainers without affecting all other readers of this, please let me know. Otherwise, I'm afraid that it will keep happening as people lose more time hitting this issue over and over.

claunia commented

2026-01-30 22:41:01 +00:00

@martingalvan-volue commented on GitHub (May 24, 2024):

Hi @zadjii-msft, are there any updated for this feature? Do we have an ETA? Thanks.

@martingalvan-volue commented on GitHub (May 24, 2024): Hi @zadjii-msft, are there any updated for this feature? Do we have an ETA? Thanks.

claunia commented

@lhecker commented on GitHub (May 24, 2024):

There's no ETA and no updates. If you subscribe to this issue, you'll be notified once that changes.
Work towards this feature is currently ongoing, but it will take a very long time to finally get there.

@lhecker commented on GitHub (May 24, 2024): There's no ETA and no updates. If you subscribe to this issue, you'll be notified once that changes. Work towards this feature is currently ongoing, but it will take a very long time to finally get there.

claunia commented

@martingalvan-volue commented on GitHub (May 24, 2024):

There's no ETA and no updates. If you subscribe to this issue, you'll be notified once that changes. Work towards this feature is currently ongoing, but it will take a very long time to finally get there.

Thanks for the response. I'm subscribed to the issue, but thought I'd ping it anyway to see if there's any activity.

@martingalvan-volue commented on GitHub (May 24, 2024): > There's no ETA and no updates. If you subscribe to this issue, you'll be notified once that changes. Work towards this feature is currently ongoing, but it will take a very long time to finally get there. Thanks for the response. I'm subscribed to the issue, but thought I'd ping it anyway to see if there's any activity.

claunia commented

@ramapcsx2 commented on GitHub (Jul 16, 2024):

Hey ho, how about u64 instead of i32? Would already cover most cases :)

@ramapcsx2 commented on GitHub (Jul 16, 2024): Hey ho, how about u64 instead of i32? Would already cover most cases :)

claunia commented

@martingalvan-volue commented on GitHub (Jul 19, 2024):

Work towards this feature is currently ongoing, but it will take a very long time to finally get there.

Thanks for the response. Is this work being done on a public branch of this repository? It would be nice to be able to keep track of it, since it's such an essential feature.

@martingalvan-volue commented on GitHub (Jul 19, 2024): > Work towards this feature is currently ongoing, but it will take a very long time to finally get there. Thanks for the response. Is this work being done on a public branch of this repository? It would be nice to be able to keep track of it, since it's such an essential feature.

claunia commented

https://github.com/user-attachments/assets/e3791a86-8c06-4232-9108-a5d353f30edc

@o-sdn-o commented on GitHub (Jul 20, 2024):

As a workaround, you can try using vtm to instantly get this feature (an arbitrary large ring-buffer in memory with incremental growth to a fixed maximum) inside Windows Terminal.

Run pwsh with a scrollback buffer ready to hold, for example, up to 1M lines (this will take up some RAM):

vtm.exe --tui --config "<config/term/scrollback size=1000000 growstep=100000/>" --run pwsh

You can run it in a separate window using -g/--gui cli option to see the scrollback buffer state in real time if you need to.

vtm.exe --gui --config "<config/term/scrollback size=1000000 growstep=100000/>" --run pwsh

@o-sdn-o commented on GitHub (Jul 20, 2024): As a workaround, you can try using [vtm](https://github.com/directvt/vtm) to instantly get this feature (an arbitrary large ring-buffer in memory with incremental growth to a fixed maximum) inside Windows Terminal. Run `pwsh` with a scrollback buffer ready to hold, for example, up to 1M lines (this will take up some RAM): ```bash vtm.exe --tui --config "<config/term/scrollback size=1000000 growstep=100000/>" --run pwsh ``` https://github.com/user-attachments/assets/e3791a86-8c06-4232-9108-a5d353f30edc You can run it in a separate window using `-g`/`--gui` cli option to see the scrollback buffer state in real time if you need to. ```bash vtm.exe --gui --config "<config/term/scrollback size=1000000 growstep=100000/>" --run pwsh ```

claunia commented

2026-01-30 22:41:03 +00:00

@martingalvan-volue commented on GitHub (Jul 26, 2024):

As a workaround, you can try using vtm to instantly get this feature (an arbitrary large ring-buffer in memory with incremental growth to a fixed maximum) inside Windows Terminal.

Run pwsh with a scrollback buffer ready to hold, for example, up to 1M lines (this will take up some RAM):
vtm.exe -c "<config><term><scrollback size=1000000 growstep=100000/></term></config>" -r vtty pwsh
PowerShell.2024-07-20.21-34-38.mp4

You can run it in a separate window using -g/--gui cli option to see the scrollback buffer state in real time if you need to.
vtm.exe -g -c "<config><term><scrollback size=1000000 growstep=100000/></term></config>" -r vtty pwsh

Thanks for the info. I haven't tried this yet, but hopefully it can serve as a workaround until Microsoft fixes Windows Terminal.

@martingalvan-volue commented on GitHub (Jul 26, 2024): > As a workaround, you can try using [vtm](https://github.com/directvt/vtm) to instantly get this feature (an arbitrary large ring-buffer in memory with incremental growth to a fixed maximum) inside Windows Terminal. > > Run `pwsh` with a scrollback buffer ready to hold, for example, up to 1M lines (this will take up some RAM): > > ```shell > vtm.exe -c "<config><term><scrollback size=1000000 growstep=100000/></term></config>" -r vtty pwsh > ``` > > PowerShell.2024-07-20.21-34-38.mp4 > > You can run it in a separate window using `-g`/`--gui` cli option to see the scrollback buffer state in real time if you need to. > > ```shell > vtm.exe -g -c "<config><term><scrollback size=1000000 growstep=100000/></term></config>" -r vtty pwsh > ``` Thanks for the info. I haven't tried this yet, but hopefully it can serve as a workaround until Microsoft fixes Windows Terminal.

claunia commented

2026-01-30 22:41:03 +00:00

@martingalvan-volue commented on GitHub (Nov 7, 2024):

Hi, just wanted to check whether there's been any progress on this issue.

@martingalvan-volue commented on GitHub (Nov 7, 2024): Hi, just wanted to check whether there's been any progress on this issue.

claunia commented

2026-01-30 22:41:03 +00:00

@effleurager commented on GitHub (Nov 8, 2024):

If there's a way to ping only MS maintainers without affecting all other readers of this, please let me know. Otherwise, I'm afraid that it will keep happening as people lose more time hitting this issue over and over.

You do realise you're the only person affecting this effect?

@effleurager commented on GitHub (Nov 8, 2024): > If there's a way to ping only MS maintainers without affecting all other readers of this, please let me know. Otherwise, I'm afraid that it will keep happening as people lose more time hitting this issue over and over. You do realise you're the only person affecting this effect?

claunia commented

@martingalvan-volue commented on GitHub (Nov 8, 2024):

You do realise you're the only person affecting this effect?

I don't understand what you mean by this. I just thought I'd ping this to see if there's been any progress, as it's been over 5 years since it was reported and people are still tripping over it.

@martingalvan-volue commented on GitHub (Nov 8, 2024): > You do realise you're the only person affecting this effect? I don't understand what you mean by this. I just thought I'd ping this to see if there's been any progress, as it's been over 5 years since it was reported and people are still tripping over it.

claunia commented

@andre-m-coquim-alb commented on GitHub (Nov 24, 2024):

Is it possible for an issue as old as this one to be considered a priority and be put out of the backlog, or will it be one of those issues that will remain in backlog forever independently of how many people come here and put a thumbs up or comment on it? Is there anything we, common users can do to give it some kindo of priority?
To me it affects me every day since I have to do compilations that easily pass the current scrollback limit and obligates me to use an alternative terminal, since if an error occurs it will possibly be lost due to the limited scrollback in windows terminal.

@andre-m-coquim-alb commented on GitHub (Nov 24, 2024): Is it possible for an issue as old as this one to be considered a priority and be put out of the backlog, or will it be one of those issues that will remain in backlog forever independently of how many people come here and put a thumbs up or comment on it? Is there anything we, common users can do to give it some kindo of priority? To me it affects me every day since I have to do compilations that easily pass the current scrollback limit and obligates me to use an alternative terminal, since if an error occurs it will possibly be lost due to the limited scrollback in windows terminal.

claunia commented

@ramapcsx2 commented on GitHub (Nov 24, 2024):

To add to that, we'll take interim workarounds as well. If the full proper fix is too involved, then at least bolt something on in the meanwhile?
Cheers :p

@ramapcsx2 commented on GitHub (Nov 24, 2024): To add to that, we'll take interim workarounds as well. If the full proper fix is too involved, then at least bolt something on in the meanwhile? Cheers :p

claunia commented

@martingalvan-volue commented on GitHub (Jun 20, 2025):

Hi, I just got hit by this issue once again. I saw that @DHowett has set a milestone for this, does that mean there's work being done here?

@martingalvan-volue commented on GitHub (Jun 20, 2025): Hi, I just got hit by this issue once again. I saw that @DHowett has set a milestone for this, does that mean there's work being done here?

claunia commented

@evilZardoz commented on GitHub (Jul 29, 2025):

macOS user here transitioning to Windows - this is a significant thing holding me back. The macOS terminal can hold around 2GB of scrollback (before it crashes). Understand that we need to throw memory at this problem (how efficient would it be? Will I need more than 16 or 32GB RAM in my device for it?).

Glad it's being worked on, at least!

Features for usefulness could include a "save buffer and clear" feature to export the entire buffer to a text file. "Open windows from previous session" would probably want to truncate any buffers that may be stored - macOS terminal does this.

@evilZardoz commented on GitHub (Jul 29, 2025): macOS user here transitioning to Windows - this is a significant thing holding me back. The macOS terminal can hold around 2GB of scrollback (before it crashes). Understand that we need to throw memory at this problem (how efficient would it be? Will I need more than 16 or 32GB RAM in my device for it?). Glad it's being worked on, at least! Features for usefulness could include a "save buffer and clear" feature to export the entire buffer to a text file. "Open windows from previous session" would probably want to truncate any buffers that may be stored - macOS terminal does this.

claunia commented

@lhecker commented on GitHub (Jul 29, 2025):

I apologize, I accidentally forgot about finishing the PR, as I was working on another project since earlier this year (msedit). I'll see if I can finish it up in the near term.

@lhecker commented on GitHub (Jul 29, 2025): I apologize, I accidentally forgot about finishing the PR, as I was working on another project since earlier this year (msedit). I'll see if I can finish it up in the near term.

claunia commented

@andre-m-coquim-alb commented on GitHub (Oct 9, 2025):

Hi, lhecker, your PR #18290 seems to have failed some checks, can you please take a look when you have time?

@andre-m-coquim-alb commented on GitHub (Oct 9, 2025): Hi, [lhecker](https://github.com/lhecker), your PR #18290 seems to have failed some checks, can you please take a look when you have time?

claunia commented