Why Cmder Still Beats Windows Terminal as a Portable Shell Toolkit

This old-school Windows terminal still does a few things better than Microsoft​

Windows Terminal is one of the rare Microsoft apps that I can recommend without a list of caveats. It has tabs, split panes, a clean settings UI, proper profile management, Quake mode, good Unicode handling, GPU-accelerated rendering, command palette support, and enough customization to satisfy most people without forcing everyone into a JSON file.
For most Windows users, that is the correct answer. If you need PowerShell, Command Prompt, WSL, Azure Cloud Shell, Git Bash, or almost any other shell in one modern interface, Windows Terminal is the place to run it.
Still, there is one older Windows terminal bundle that has not entirely lost its place: Cmder.
Cmder is not as modern as Windows Terminal. Its original interface is built around ConEmu, and it looks and feels older. It does not render as smoothly, its UI is heavier, and it is not the best terminal window in 2026. But that is the wrong comparison. Cmder’s real strength is not the glass around the shell. It is the shell environment it brings with it.
Windows Terminal gives you a better terminal host. Cmder gives you a more complete command-line toolkit. That difference matters more than it seems, especially if you work across fresh Windows installs, temporary machines, locked-down systems, or USB-based toolkits.

Windows Terminal is a host, not a toolbox​

Image placeholder: Alt text: Windows Terminal open with several profiles including PowerShell, Command Prompt, Ubuntu, and Git Bash
The first thing to understand is that Windows Terminal does not replace your shell. It hosts your shell.
That distinction sounds small until you set up a clean Windows machine. Open Windows Terminal on a fresh install and you will typically have PowerShell, Command Prompt, and maybe a WSL profile if you have installed a Linux distribution. You get a better window for typing commands, but you do not suddenly get a Linux-style command-line environment.
If you type ls in PowerShell, it works because PowerShell has an alias for Get-ChildItem. That does not mean you have the GNU ls command. If you type grep, awk, sed, or many other everyday Unix tools, Windows will not magically know what you mean unless you have installed something that provides them.
That is where Cmder still feels unusually practical. The full edition of Cmder includes a vendored Git for Windows setup. That means you get Git, Bash, OpenSSH tools, and a useful set of Unix-like commands without separately installing Git for Windows and without manually fixing your PATH.
This is not just about nostalgia for ls. It is about muscle memory and portability. Developers, sysadmins, and power users often move between Windows, Linux, macOS, WSL, containers, remote servers, and CI environments. If your fingers expect grep -R, ssh, cat, touch, which, tar, or bash, a bare Windows shell can feel like a trapdoor. Cmder smooths that gap immediately.
Windows Terminal can absolutely run Git Bash, WSL, PowerShell, or any other shell you point it to. In fact, that is one of its best qualities. But it does not bring the tools itself. You still need to install Git for Windows, configure your shell, manage PATH ordering, decide which executable takes priority, and repeat that setup on each machine.
Cmder bundles a lot of that decision-making into one folder. You unzip it, run it, and get a more familiar toolkit.
This matters most on secondary machines. On my main PC, I have everything configured exactly how I like it. I have PowerShell profiles, package managers, Git, WSL distributions, SSH config, terminal themes, editor integrations, and various utilities installed. On that machine, Windows Terminal is enough because the rest of the environment has already been built around it.
On a spare laptop, a borrowed workstation, a lab machine, or a newly reinstalled PC, the situation is different. There, Windows Terminal gives me a polished surface over an unfinished environment. Cmder gives me a working environment quickly.
That is the part Microsoft still does not fully solve. Windows Terminal makes command-line work nicer. Cmder makes a clean Windows command line immediately more useful.

Cmder’s portability is still its killer feature​

Image placeholder: Alt text: A Cmder folder on a USB drive showing bin, config, vendor, and Cmder.exe
Cmder’s biggest advantage is not that it has tabs. Windows Terminal does tabs better. It is not that it has themes. Windows Terminal themes are cleaner. It is not even that it ships with Git, although that helps.
Cmder’s biggest advantage is that it is a folder.
That sounds almost too simple, but it changes how you think about your command-line setup. Cmder is designed to be self-contained. Your configuration, aliases, custom scripts, binaries, prompt behavior, and bundled tools can all live inside the same directory tree.
You can put that folder in C:\Tools\Cmder. You can put it on a USB drive. You can sync it with cloud storage. You can copy it to another PC. You can keep a known-good copy in your backup drive. You can even drop small standalone tools into its bin folder and have them available inside Cmder sessions.
That is very different from the usual Windows approach, where a terminal setup is spread across the system. Your terminal app is installed in one place. Your PowerShell profile lives somewhere under your user documents folder. Your Git installation is somewhere else. Your SSH config is in your user profile. Your package manager has its own installation paths. Your environment variables are stored at the user or system level. Your scripts may be in another directory entirely.
That setup works, but it is not portable in the same way.
Windows Terminal’s settings can be exported or synced depending on how you use it, and Windows Terminal itself has more installation options than it used to. But exporting terminal settings is not the same as exporting your command-line environment. A Windows Terminal settings file can remember that you have a Git Bash profile, but it does not bring Git Bash with it. It can remember a font, color scheme, starting directory, and command line, but it does not carry your helper binaries, grep, SSH tools, aliases, or custom startup scripts.
Cmder’s model is closer to an old portable app. Copy the folder, and the environment comes with it.
That makes it especially useful in three situations.
First, it is excellent for recovery and troubleshooting. If you keep Cmder on a USB drive with a few trusted utilities, you can plug it into a Windows machine and have a familiar shell without installing half a dozen tools. That can be useful when fixing PATH issues, moving files, checking Git repositories, testing SSH connectivity, or running scripts on a machine you do not want to modify heavily.
Second, it is useful for people who frequently rebuild Windows. Anyone who tests Insider builds, reinstalls Windows often, uses disposable VMs, or works with temporary dev machines knows the friction of rebuilding a command-line environment. A portable Cmder folder cuts that setup time dramatically.
Third, it is useful when you want a consistent setup across machines without committing to a full dotfiles system. Dotfiles work beautifully if you maintain them. They also require discipline. Cmder is less elegant but more immediate. If your aliases and scripts live inside the Cmder folder, they travel with it.
There is a trade-off, of course. Bundling tools means you need to update them. A portable folder can go stale. Vendored Git may not always be the version you want. Security updates matter, especially for Git and SSH. But that is a manageable trade-off if you treat Cmder as a portable toolkit and update it periodically.
Microsoft’s ecosystem is better at app deployment, app updates, and deep Windows integration. Cmder is better at being picked up and carried away.

The alias system is refreshingly simple​

Image placeholder: Alt text: A text editor showing Cmder user aliases such as gs equals git status and .. equals cd ..
Aliases are one of those small things that determine whether a shell feels like home. They are not glamorous, but they are the difference between a terminal you tolerate and a terminal you move through quickly.
This is another area where Cmder still feels pleasantly direct.
In Cmder, Command Prompt aliases can live in a plain text file, commonly user_aliases.cmd inside the Cmder config folder. The syntax is simple enough that you do not need to think about it:

gs=git status $*
ga=git add $*
gc=git commit $*
gp=git push $*
..=cd ..
ll=ls -la $*

The $* part passes along the remaining arguments. That means gs -sb can expand into git status -sb, and ga README.md can expand into git add README.md.
This is basic, but basic is the point. Most aliases do not need to be a script. They do not need a module. They do not need a function definition. They do not need a profile path lookup. They need one line in a file you can copy, edit, and understand six months later.
PowerShell can do aliases too, but PowerShell aliases are intentionally limited. Set-Alias maps one command name to another command name. It is fine for replacing notepad with something else or creating simple shorthand, but it does not handle arguments in the same flexible way. If you want a shortcut such as gs that runs git status and still accepts flags, the PowerShell way is usually to define a function:

function gs {
    git status @args
}

That is not difficult, and PowerShell functions are far more powerful than simple Cmder aliases. But for quick command shortcuts, it adds ceremony. You need to know which profile file you are editing. You need to make sure it is loaded in the host you are using. You need to keep it synced. You may need to think about execution policy if you move scripts between systems. None of this is a huge problem for a PowerShell user, but it is friction.
Cmder’s alias file is low-friction by design. Open the file, add a line, restart the shell, and move on.
The portability angle makes it even better. If your Cmder aliases live inside %CMDER_ROOT%\config, they are part of the Cmder folder. Copy the folder, and your shortcuts follow. You do not have to remember whether this particular alias lived in your Windows PowerShell profile, your PowerShell 7 profile, your VS Code integrated terminal profile, your Git Bash .bashrc, or your Windows Terminal settings.
That does not make Cmder more powerful than PowerShell. It makes it less fussy for a certain kind of everyday shortcut.
PowerShell remains the better shell language. Its object pipeline, modules, remoting features, parameter binding, and scripting model are much richer. If you are automating Windows administration, working with Azure, managing Microsoft 365, or writing robust scripts, PowerShell is the right tool.
But not every shortcut deserves to become a PowerShell function. Sometimes you just want gco to mean git checkout $*. Cmder makes that boring, and boring is good.

Cmder makes Command Prompt feel less primitive​

Image placeholder: Alt text: Cmder running cmd with a Git-aware prompt and command history search
Command Prompt is old, but it is not dead. There are still plenty of reasons to use cmd.exe. Some legacy scripts assume it. Some build tools still document commands for it. Some Windows troubleshooting steps are written with it in mind. Batch files remain common. And sometimes you simply want a shell that starts instantly and behaves predictably.
The problem is that plain Command Prompt feels painfully limited once you are used to modern shell editing.
Cmder improves that by integrating Clink. Clink brings GNU Readline-style behavior to cmd.exe, which means the line editor becomes dramatically more comfortable. You get better history, better completion, more familiar shortcuts, and command-line behavior that feels closer to Bash.
The biggest everyday improvement is history search. In a normal command-line workflow, you constantly reuse commands with small changes. You run a long Git command, then need a similar one later. You SSH into a host, then need that exact command again. You run a build command with flags, then repeat it after changing a file.
In shells with good reverse search, you press Ctrl+R, type a fragment, and pull the command back from history. In a plain cmd.exe session, that experience is not nearly as good. Cmder makes it feel more natural.
The prompt is another improvement. Cmder’s prompt can show useful context, including Git branch information. That sounds cosmetic until you work across multiple repositories. Knowing what branch you are on before you run a command can save real mistakes. It is not unique to Cmder, of course. PowerShell prompts can do this with modules such as posh-git or Oh My Posh, and many developers already have elaborate prompt setups. But Cmder gives Command Prompt a better default experience without turning it into a project.
This is one reason Cmder remains interesting even if you do not launch its own window. It can be treated as an enhanced cmd.exe environment. You can run Cmder’s initialization script from another terminal host and keep the improved shell behavior while using a better terminal window.
That hybrid approach matters because Windows Terminal is now the better graphical terminal. It handles rendering, tabs, splits, profiles, and window management better than Cmder’s older ConEmu-based interface. But Cmder still improves the shell experience underneath.
Think of it this way:
Windows Terminal is the stage. Cmder is one possible backstage crew.
The stage is modern, fast, and flexible. But if you put a bare cmd.exe on that stage, it is still bare cmd.exe. If you put Cmder’s initialized environment there, it becomes much more pleasant.
This is also where Cmder avoids a common trap in Windows terminal debates. The question is not whether you should use Cmder instead of Windows Terminal. For many people, the better question is whether you should use Cmder inside Windows Terminal.

Windows Terminal still wins the modern terminal experience​

Image placeholder: Alt text: Windows Terminal split panes showing PowerShell, WSL, and Cmder running side by side
None of this means Cmder is the better terminal window today. It is not.
Windows Terminal has become the more polished daily terminal host. Its rendering is smoother, its font handling is better, and its interface feels much more at home on Windows 11. It supports tabs and panes well. It has a command palette. It has a settings UI that is approachable for normal users but still exposes advanced configuration for people who want it. It handles profiles cleanly, including automatically detected shells in many cases.
The split pane implementation alone is enough to keep many users in Windows Terminal. Being able to keep PowerShell, WSL, a dev server, and a build command visible in one window is a major productivity improvement. Cmder can do tabs and panes through ConEmu, but the experience feels older and more complex.
Windows Terminal also benefits from being actively aligned with Microsoft’s modern command-line work. It integrates well with WSL. It supports shell integration features. It has a strong settings model. It gets regular releases. It is part of the direction Microsoft wants Windows command-line users to go.
It also does a better job with text rendering. This matters more than people think. Terminal output is not just ASCII logs anymore. Developers deal with Unicode symbols, icons, emoji, box drawing characters, ligatures, complex prompts, progress UI, and color-heavy command-line tools. Windows Terminal is much more comfortable in that world.
Performance is another advantage. Cmder’s older ConEmu interface can feel sluggish compared with Windows Terminal, especially with large amounts of output. If you are tailing logs, running chatty build tools, or dealing with command output that floods the screen, the difference is noticeable.
Then there is configuration discoverability. Cmder is powerful, but much of its power still feels like something you uncover through documentation, config files, or old forum posts. Windows Terminal’s settings UI is easier to navigate. Profiles, color schemes, startup behavior, key bindings, appearance settings, and default terminal behavior are much easier to adjust than they used to be.
For most users, Windows Terminal should remain the default terminal application. That is the right conclusion.
But again, this is not a winner-take-all comparison. Windows Terminal wins the terminal host category. Cmder still has value as a portable shell bundle.
The important mistake is assuming that because Windows Terminal is better, Cmder has no remaining purpose. It does. It is just not the same purpose it had years ago.
Years ago, Cmder made Windows command-line work tolerable because the default console experience was poor. Today, Microsoft has fixed much of the terminal window problem. What it has not done is ship a portable, Unix-friendly, batteries-included command-line environment with simple aliases and bundled tools.
That is the gap Cmder still fills.

The best setup is to run Cmder inside Windows Terminal​

Image placeholder: Alt text: Windows Terminal settings showing a custom Cmder profile command line
The smartest way to use Cmder today is not necessarily to open Cmder.exe.
Instead, keep Windows Terminal as the host and add Cmder as a profile.
That gives you the best parts of both tools. You get Windows Terminal’s rendering, tabs, split panes, keyboard shortcuts, command palette, and modern UI. Underneath, you get Cmder’s initialized environment, aliases, Git tooling, Unix-like commands, and portable config.
A typical Windows Terminal profile can point to cmd.exe and launch Cmder’s init.bat. The exact path depends on where you keep Cmder, but the idea looks like this:

{
    "name": "Cmder",
    "commandline": "cmd.exe /k \"C:\\Tools\\Cmder\\vendor\\init.bat\"",
    "startingDirectory": "%USERPROFILE%",
    "icon": "C:\\Tools\\Cmder\\icons\\cmder.ico"
}

Some setups use slightly different command lines depending on the Cmder version and whether you want to initialize from a specific root. The important part is that Windows Terminal launches cmd.exe, and Cmder’s initialization script prepares the environment.
Once configured, opening the Cmder profile in Windows Terminal feels like a normal Windows Terminal tab. You can split it, duplicate it, move it, rename it, and theme it like any other profile. You are no longer staring at the older Cmder window, but the shell environment is still there.
This approach also lets you use Cmder selectively.
You can keep PowerShell as your default profile. You can keep WSL for Linux work. You can keep a dedicated Git Bash profile if you prefer. Then you can open Cmder when you want its specific portable toolkit.
That is better than forcing Cmder to be your entire terminal experience. It becomes one tool in a broader terminal setup.
There are a few details worth considering.
First, be mindful of PATH ordering. Cmder can inject its own directories and Unix-like tools into PATH. That is useful, but it can also lead to confusing behavior if two tools share a name. For example, Windows has its own find, Git for Windows has Unix-like tools, and PowerShell has aliases. If a command behaves differently than expected, check which executable is actually being used.
Second, keep Git updated. If you rely on Cmder’s vendored Git, remember that it is still software that needs security updates. Do not keep a years-old Cmder folder on a USB drive and assume it is safe forever.
Third, decide whether Cmder is your portable toolkit or your main development shell. If it is your main shell, invest time in maintaining it. If it is your portable fallback, keep it lean and predictable.
Fourth, do not duplicate complexity unnecessarily. If you already have a great PowerShell profile with Oh My Posh, posh-git, PSReadLine customization, modules, and a dotfiles repo, you may not need Cmder for daily work. Its value is highest when you want something self-contained and low-maintenance.
The hybrid setup is not for everyone, but it is the most sensible way to keep Cmder relevant on a modern Windows system.

Where Cmder shows its age​

Image placeholder: Alt text: Cmder’s classic ConEmu interface next to the modern Windows Terminal interface
Cmder deserves credit, but it also deserves a realistic assessment.
The first weakness is the interface. ConEmu was a major improvement in its time, but Windows Terminal now feels cleaner and more native. Cmder’s default window has more visual clutter, older dialogs, and a configuration experience that can feel intimidating if you are not already used to it.
The second weakness is maintenance. A bundled environment is convenient, but bundled tools age. If you install Git for Windows separately, you may get more straightforward update paths. If you use winget, Scoop, Chocolatey, or another package manager, you can update tools in a more consistent way. Cmder’s self-contained nature is both a strength and a responsibility.
The third weakness is overlap. Windows itself has improved. Windows includes an OpenSSH client. PowerShell has matured. PSReadLine gives PowerShell excellent editing behavior. WSL provides a real Linux environment. Winget can install most of what you need quickly. Windows Terminal provides the modern host. The number of reasons to rely on a third-party terminal bundle has shrunk.
The fourth weakness is that Cmder can blur boundaries. When Unix-like tools are injected into a Windows shell, you need to know which world you are in. Paths, quoting, environment variables, command names, and line endings can behave differently depending on whether you are in cmd.exe, PowerShell, Git Bash, WSL, or a Cmder-initialized shell. Experienced users can manage that. Beginners may find it confusing.
The fifth weakness is that PowerShell is simply better for many Windows-native tasks. If you are working with services, registry keys, event logs, Windows APIs, Microsoft cloud services, structured objects, or automation scripts, PowerShell is far more capable than a Unix-flavored cmd.exe setup. Cmder makes cmd.exe nicer. It does not turn it into a modern automation platform.
This is why I would not tell a new Windows user to replace Windows Terminal with Cmder. I would tell them to learn Windows Terminal, PowerShell, and WSL first. Cmder is a specialized convenience, not the default future of Windows command-line work.
Still, specialized conveniences can be valuable.
Cmder remains useful because it solves a different problem than Windows Terminal. It is a portable, preconfigured command-line bundle. It gives you a familiar set of tools quickly. It makes cmd.exe nicer. It keeps aliases and binaries together. It lets you carry a usable shell environment from one Windows machine to another.
That is not everything. But it is not nothing.

Cmder still earns a small, specific place​

The Windows command-line world is much better than it used to be. Windows Terminal fixed the terminal host problem for most users. PowerShell is powerful and mature. WSL gives developers a real Linux environment when they need one. OpenSSH, winget, and modern developer tooling have made Windows far less hostile to command-line work.
Because of that, Cmder no longer needs to be the main terminal on a Windows machine.
But it can still be the folder you keep around.
Its value is in being self-contained. Its value is in giving you Git, Bash, SSH, and Unix-like tools quickly. Its value is in a simple alias file that travels with the rest of the setup. Its value is in making cmd.exe feel less ancient without requiring you to build an entire profile system from scratch.
The best modern use of Cmder is not as a replacement for Windows Terminal. It is as a portable shell bundle that Windows Terminal can host.
Use Windows Terminal for the window. Use Cmder when you want the toolkit. That combination keeps Microsoft’s modern terminal experience while preserving the old-school bundle’s best trick: a useful Windows command line you can copy like a folder.

---

Source: MakeUseOf This old-school Windows terminal still does a few things better than Microsoft