starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Feature Request: Remember Command History #9016

New Issue
Closed
opened 2026-01-31 01:43:52 +00:00 by claunia · 18 comments
claunia commented 2026-01-31 01:43:52 +00:00
Owner
Copy Link

Originally created by @srana2000 on GitHub (Jun 14, 2020).

Just like in Linux how can Terminal (for CMD.exe) remember the command line history across multiple instances. It is very frustrating to type commands again.

Originally created by @srana2000 on GitHub (Jun 14, 2020). Just like in Linux how can Terminal (for CMD.exe) remember the command line history across multiple instances. It is very frustrating to type commands again.
claunia added the Needs-Tag-FixResolution-Won't-Fix labels 2026-01-31 01:43:52 +00:00
claunia commented 2026-01-31 01:43:53 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 14, 2020):

This is the shell's job. PoweerShell and Bash (and zsh, fish, ...) already do this! The terminal can't do anything about shells that cannot save their history. Sorry!

@DHowett commented on GitHub (Jun 14, 2020): This is the shell's job. PoweerShell and Bash (and zsh, fish, ...) already do this! The terminal can't do anything about shells that cannot save their history. Sorry!
claunia commented 2026-01-31 01:43:54 +00:00
Author
Owner
Copy Link

@mcgov commented on GitHub (Aug 6, 2020):

This feature request should be re-enabled. This is a legitimate feature request. You can't think of a way to write a program which just remembers history and passes the commands to a cmd shell?

@mcgov commented on GitHub (Aug 6, 2020): This feature request should be re-enabled. This is a legitimate feature request. You can't think of a way to write a program which just remembers history and passes the commands to a cmd shell?
claunia commented 2026-01-31 01:43:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 6, 2020):

@mcgov cmd.exe is very much in maintenance-only mode. If you'd like a shell that can remember command history across reboots, I recommend looking into powershell, zsh, yori, click, cmder, or pretty much any other shell.

@zadjii-msft commented on GitHub (Aug 6, 2020): @mcgov `cmd.exe` is very much in maintenance-only mode. If you'd like a shell that can remember command history across reboots, I recommend looking into powershell, zsh, yori, click, cmder, or pretty much any other shell.
claunia commented 2026-01-31 01:43:54 +00:00
Author
Owner
Copy Link

@mcgov commented on GitHub (Aug 6, 2020):

This is going to sound crazy but I'd like to have this feature in windows terminal

@mcgov commented on GitHub (Aug 6, 2020): This is going to sound crazy but I'd like to have this feature in windows terminal
claunia commented 2026-01-31 01:43:55 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 6, 2020):

I think there might be a bit of a misunderstanding here - there are two different kinds of applications we're talking about here:

  • shell applications, like cmd.exe, powershell, zsh, etc. These are text-only applications that emit streams of characters. They don't care at all about how they're eventually rendered to the user. These are also sometimes referred to as "commandline client" applications.
  • terminal applications, like the Windows Terminal, gnome-terminal, xterm, iterm2, hyper. These are graphical applications that can be used to render the output of commandline clients.

On Windows, if you just run cmd.exe directly, the OS will create an instance of conhost.exe as the terminal for cmd.exe. The same thing happens for powershell.exe, the system will creates a new conhost window for any client that's not already connected to a terminal of some sort. This has lead to an enormous amount of confusion for people thinking that a conhost window is actually a "cmd window". cmd can't have a window, it's just a commandline application. Its window is always some other terminal.

Any terminal can run any commandline client application. So you can use the Windows Terminal to run whatever shell you want. I use mine for both cmd and powershell, and also WSL:
image

It's not the Terminal's responsibility to remember the commands executed by a commandline client. That's the responsibility of the shell. How would the terminal remember commands executed by something like emacs or vim? Those are both applications where the user is typing input and hitting enter, like they would at a cmd prompt, but without something that resembles a command history.

@zadjii-msft commented on GitHub (Aug 6, 2020): I think there might be a bit of a misunderstanding here - there are two different kinds of applications we're talking about here: * shell applications, like `cmd.exe`, `powershell`, `zsh`, etc. These are text-only applications that emit streams of characters. They don't care at all about how they're eventually rendered to the user. These are also sometimes referred to as "commandline client" applications. * terminal applications, like the Windows Terminal, gnome-terminal, xterm, iterm2, hyper. These are graphical applications that can be used to render the output of commandline clients. On Windows, if you just run `cmd.exe` directly, the OS will create an instance of `conhost.exe` as the _terminal_ for `cmd.exe`. The same thing happens for `powershell.exe`, the system will creates a new conhost window for any client that's not already connected to a terminal of some sort. This has lead to an enormous amount of confusion for people thinking that a conhost window is actually a "`cmd` window". `cmd` can't have a window, it's just a commandline application. Its window is always some other terminal. Any terminal can run any commandline client application. So you can use the Windows Terminal to run whatever shell you want. I use mine for both cmd and powershell, and also WSL: ![image](https://user-images.githubusercontent.com/18356694/89556758-79d27e80-d7d7-11ea-84e2-10710e09ef4a.png) It's not the Terminal's responsibility to remember the commands executed by a commandline client. That's the responsibility of the _shell_. How would the terminal remember commands executed by something like `emacs` or `vim`? Those are both applications where the user is typing input and hitting enter, like they would at a cmd prompt, but without something that resembles a command history.
claunia commented 2026-01-31 01:43:55 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020):

You already have src/host/history.cpp and src/host/history.h, for programs like cmd.exe or netsh.exe that don't implement their own line editing. Surely it would be technically possible to make the console host save and restore this history, or extend the pseudoconsole channel to let WindowsTerminal.exe do it.

@KalleOlaviNiemitalo commented on GitHub (Aug 6, 2020): You already have [src/host/history.cpp](https://github.com/microsoft/terminal/blob/4d00019a9b7f4552d9414a44c9ab6c7641b478f7/src/host/history.cpp) and [src/host/history.h](https://github.com/microsoft/terminal/blob/4d00019a9b7f4552d9414a44c9ab6c7641b478f7/src/host/history.h), for programs like cmd.exe or netsh.exe that don't implement their own line editing. Surely it would be technically possible to make the console host save and restore this history, or extend the pseudoconsole channel to let WindowsTerminal.exe do it.
claunia commented 2026-01-31 01:43:55 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2020):

The console host maintaining an application’s history is an architectural mistake the likes of which we are not intending to make again.

@DHowett commented on GitHub (Aug 6, 2020): The console host maintaining an application’s history is an architectural mistake the likes of which we are not intending to make again.
claunia commented 2026-01-31 01:43:55 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 6, 2020):

That includes extending it in any way that would make it more enticing or more featureful such that an application would prefer to use it over its own line editing and history management.

We maintain that code because we have to, not because it was good or worthwhile.

@DHowett commented on GitHub (Aug 6, 2020): That includes extending it in any way that would make it _more enticing_ or more featureful such that an application would prefer to use it over its own line editing and history management. We maintain that code because we have to, not because it was good or worthwhile.
claunia commented 2026-01-31 01:43:55 +00:00
Author
Owner
Copy Link

@alibarut commented on GitHub (Dec 6, 2022):

You can use https://mridgers.github.io/clink/

@alibarut commented on GitHub (Dec 6, 2022): You can use [https://mridgers.github.io/clink/](url)
claunia commented 2026-01-31 01:43:55 +00:00
Author
Owner
Copy Link

@NewtonChutney commented on GitHub (Dec 29, 2023):

I daily drive pwsh, so I don't exactly need cmd's history but I'd like to see this bit of code in action..
Where is the feature toggle present? 😂

You already have src/host/history.cpp and src/host/history.h, for programs like cmd.exe or netsh.exe that don't implement their own line editing. Surely it would be technically possible to make the console host save and restore this history, or extend the pseudoconsole channel to let WindowsTerminal.exe do it.

@NewtonChutney commented on GitHub (Dec 29, 2023): I daily drive pwsh, so I don't exactly need cmd's history but I'd like to see this bit of code in action.. Where is the feature toggle present? 😂 > You already have [src/host/history.cpp](https://github.com/microsoft/terminal/blob/4d00019a9b7f4552d9414a44c9ab6c7641b478f7/src/host/history.cpp) and [src/host/history.h](https://github.com/microsoft/terminal/blob/4d00019a9b7f4552d9414a44c9ab6c7641b478f7/src/host/history.h), for programs like cmd.exe or netsh.exe that don't implement their own line editing. Surely it would be technically possible to make the console host save and restore this history, or extend the pseudoconsole channel to let WindowsTerminal.exe do it.
claunia commented 2026-01-31 01:43:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 3, 2024):

Sorry, still foggy from the holidays. Re:

Where is the feature toggle present? 😂

Could you elaborate? Which feature toggle?

@zadjii-msft commented on GitHub (Jan 3, 2024): Sorry, still foggy from the holidays. Re: > Where is the feature toggle present? 😂 Could you elaborate? Which feature toggle?
claunia commented 2026-01-31 01:43:56 +00:00
Author
Owner
Copy Link

@NewtonChutney commented on GitHub (Jan 3, 2024):

@zadjii-msft, KalleOlaviNiemitalo had said:

You already have src/host/history.cpp and src/host/history.h, for programs like cmd.exe or netsh.exe that don't implement their own line editing. Surely it would be technically possible to make the console host save and restore this history, or extend the pseudoconsole channel to let WindowsTerminal.exe do it.

But I couldn't find references of this setting/toggle..
This just piqued my interest, and I wanted to see it in action.. 😅

@NewtonChutney commented on GitHub (Jan 3, 2024): @zadjii-msft, KalleOlaviNiemitalo had said: > You already have [src/host/history.cpp](https://github.com/microsoft/terminal/blob/4d00019a9b7f4552d9414a44c9ab6c7641b478f7/src/host/history.cpp) and [src/host/history.h](https://github.com/microsoft/terminal/blob/4d00019a9b7f4552d9414a44c9ab6c7641b478f7/src/host/history.h), for programs like cmd.exe or netsh.exe that don't implement their own line editing. Surely it would be technically possible to make the console host save and restore this history, or extend the pseudoconsole channel to let WindowsTerminal.exe do it. But I couldn't find references of this setting/toggle.. This just piqued my interest, and I wanted to see it in action.. 😅
claunia commented 2026-01-31 01:43:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 3, 2024):

I mean, it's not really a "terminal" feature, so to speak. It's an artifact of the console API. If a console application enables ENABLE_PROCESSED_OUTPUT (e.g., cmd.exe, python.exe), then conhost itself (the console API server) will maintain an internal history of commands that were entered. This history is only in conhost's memory, and is lost when the console is closed. Other applications, like PowerShell, which might want a more elaborate line-editing experience than what conhost provides, disable that mode, and manage all input and history themselves.

@zadjii-msft commented on GitHub (Jan 3, 2024): I mean, it's not really a "terminal" feature, so to speak. It's an artifact of the console API. If a console application enables [ENABLE_PROCESSED_OUTPUT](https://learn.microsoft.com/en-us/windows/console/high-level-console-modes) (e.g., `cmd.exe`, `python.exe`), then `conhost` itself (the console API server) will maintain an internal history of commands that were entered. This history is only in conhost's memory, and is lost when the console is closed. Other applications, like PowerShell, which might want a more elaborate line-editing experience than what conhost provides, disable that mode, and manage all input and history themselves.
claunia commented 2026-01-31 01:43:56 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jan 3, 2024):

@NewtonChutney if you run cmd.exe in conhost (with or without Windows Terminal), and type a few commands, then you can use the up and down arrow keys to revisit those commands; that uses the history feature that is implemented in those files. There is also some function key that pops up a menu based on this history; that is implemented in some other part of conhost. The console API can manipulate the history programmatically and IIRC the DOSKEY command uses those functions.

@KalleOlaviNiemitalo commented on GitHub (Jan 3, 2024): @NewtonChutney if you run cmd.exe in conhost (with or without Windows Terminal), and type a few commands, then you can use the up and down arrow keys to revisit those commands; that uses the history feature that is implemented in those files. There is also some function key that pops up a menu based on this history; that is implemented in some other part of conhost. The console API can manipulate the history programmatically and IIRC the DOSKEY command uses those functions.
claunia commented 2026-01-31 01:43:56 +00:00
Author
Owner
Copy Link

@NewtonChutney commented on GitHub (Jan 3, 2024):

Ahhh, those files were related to session history.. Sorry for misinterpreting them as cross-session history handling.. ᓚᘏᗢ

@NewtonChutney commented on GitHub (Jan 3, 2024): Ahhh, those files were related to session history.. Sorry for misinterpreting them as cross-session history handling.. ᓚᘏᗢ
claunia commented 2026-01-31 01:43:57 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jan 3, 2024):

IIUC, it would be possible to fork conhost from this repository, add the history save/restore feature, install the binary in Windows, and register it as DelegationConsole so that Windows runs it when you start a console application. Even if Microsoft won't accept a pull request with such a change. If you changed its CLSID, then it would be installable side by side with openconsole of Windows Terminal, and would be able to launch Windows Terminal for the UI.

@KalleOlaviNiemitalo commented on GitHub (Jan 3, 2024): IIUC, it would be possible to fork conhost from this repository, add the history save/restore feature, install the binary in Windows, and [register it as DelegationConsole](https://github.com/microsoft/terminal/blob/a7ab17571b525c3643b18d1ad03a2ae2cf9b5503/doc/specs/%23492%20-%20Default%20Terminal/spec.md) so that Windows runs it when you start a console application. Even if Microsoft won't accept a pull request with such a change. If you changed its CLSID, then it would be installable side by side with openconsole of Windows Terminal, and would be able to launch Windows Terminal for the UI.
claunia commented 2026-01-31 01:43:57 +00:00
Author
Owner
Copy Link

@duaneking commented on GitHub (Feb 4, 2025):

As much as the developers working on this code will probably hate me saying this, its important enough that it needs to be said publicly:

Having a history of the commands actually used via the Windows Terminal isn't just an accessibility feature to make things easier to use (Like recalling commands or reusing them via a shortcut). It is also a critical need from a cybersecurity perspective , not just required under legal requirements (like a11y, etc), as tracking and auditing are required for things like GRC, (That's Governance, Risk, and Compliance), FIPS, and other legal requirements that have traditionally meant that windows cant even be considered.

And no... I'm not saying that a history left behind by an attacker can be trusted; what I am saying is that it's another data point that is highly valuable that many are simply unable to collect, due to these architectural issues.

Your are going to tell me to use other tools like "doskey /history" that only gives me a tiny, insecure slice of history that's limited to DOS cmd shell and so by design is insecure; That doesn't address the real needs here:

Accessibility -> People want to to do more with less effort. As an extreme example somebody working with the chromium code base on windows runs into this issue constantly.

Security -> Knowing what was done and not being able to have somebody hide it by spamming echo or rem makes auditors a lot more happy.

Now to be clear: I personally understand that this spans multiple teams. I fully acknowledge that, and that the different parts of the Org chart working together can be a mess. I've been there. I've been there as a lead, and I have been there as an IC, doing that work. In Redmond. Then I stopped because I hated the commute through Bellevue and getting hit by a car running a red light changed my priorities; But as somebody with that experience, I also know its possible to get Developers on different teams working together in a constructive way because I've done it.

@duaneking commented on GitHub (Feb 4, 2025): As much as the developers working on this code will probably hate me saying this, its important enough that it needs to be said publicly: Having a history of the commands actually used via the Windows Terminal isn't just an accessibility feature to make things easier to use (Like recalling commands or reusing them via a shortcut). It is also a critical need from a cybersecurity perspective , not just required under legal requirements (like a11y, etc), as tracking and auditing are *required* for things like GRC, (That's Governance, Risk, and Compliance), FIPS, and other legal requirements that have traditionally meant that windows cant even be considered. And no... I'm not saying that a history left behind by an attacker can be trusted; what I am saying is that it's another data point that is highly valuable that many are simply unable to collect, due to these architectural issues. Your are going to tell me to use other tools like "doskey /history" that only gives me a tiny, insecure slice of history that's limited to DOS cmd shell and so by design is insecure; That doesn't address the real needs here: Accessibility -> People want to to do more with less effort. As an extreme example somebody working with the chromium code base on windows runs into this issue constantly. Security -> Knowing what was done and not being able to have somebody hide it by spamming echo or rem makes auditors a lot more happy. Now to be clear: I personally understand that this spans multiple teams. I fully acknowledge that, and that the different parts of the Org chart working together can be a mess. I've been there. I've been there as a lead, and I have been there as an IC, doing that work. In Redmond. Then I stopped because I hated the commute through Bellevue and getting hit by a car running a red light changed my priorities; But as somebody with that experience, I also know its possible to get Developers on different teams working together in a constructive way because I've done it.
claunia commented 2026-01-31 01:43:57 +00:00
Author
Owner
Copy Link

@duaneking commented on GitHub (Feb 4, 2025):

Something people coming here may want to consider: #2558

@duaneking commented on GitHub (Feb 4, 2025): Something people coming here may want to consider: #2558
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Resolution-Won't-Fix
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9016
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?