Pretty PowerShell, a Windows Terminal profile that refuses to slow down your shell

One line of PowerShell, run as Administrator

The install is a single command, run as Administrator inside Windows Terminal:

irm "https://github.com/ChrisTitusTech/powershell-profile/raw/main/setup.ps1" | iex

That is the whole entry point, and it is worth naming what it does before running it. The script is fetched over the network and piped straight into the PowerShell session, which means the code that runs on your machine is whatever is on the remote branch at the moment you run it, with no local copy to read first. The repository is small, with setup.ps1, setprofile.ps1, the profile file and a README at the root, so reading it before you run it is entirely practical.

The installer does four things, and they are worth knowing one by one. It backs up an existing profile into a timestamped oldprofile-*.ps1 file. It installs the repository's Microsoft.PowerShell_profile.ps1. It installs Oh My Posh, zoxide, Terminal-Icons and the CaskaydiaCove Nerd Font. And it downloads the cobalt2.omp.json theme into your PowerShell profile directory.

Afterwards the instructions are to restart Windows Terminal and set the PowerShell font to CaskaydiaCove NF, which is not optional decoration: the icons in the prompt and in Terminal-Icons are glyphs from that font, and without it they render as placeholder boxes.

The profile does no work at shell startup, on purpose

The most quotable line in the README is a negative one. The profile itself does not install packages, download themes, or upgrade PowerShell during shell startup, and missing optional tools are skipped with a warning.

That decision shapes everything else in the design. A profile that installs a tool on first launch feels good once and then costs you a second on every shell thereafter, and on Windows, where a new console tab is cheap and frequent, the tax is paid constantly. Splitting the work into an installer that does the one-time setup and a profile that only reads configuration means the shell starts at the speed of PowerShell plus PSReadLine, and the optional tools are detected at startup rather than fetched.

The consequence for the user is a specific kind of warning. If zoxide is not on the path, the profile does not fail and does not silently pretend; it warns and moves on. That is the right trade for a profile, because a shell that refuses to start because a font or a tool is missing is a shell you will end up debugging on a machine that is not your own.

The pieces that remain at startup are cheap by design. PSReadLine handles colours, list-view suggestions and shell-friendly keybinds, and the optional startup of Terminal-Icons, oh-my-posh and zoxide is what the warning applies to.

The command surface: git, files, processes, navigation

What the profile actually adds is a set of short commands, grouped into four families in the README.

The git shortcuts are gs, ga, gcom, gp, gpull, gcl and lazyg. The file helpers are touch, mkcd, trash, ff, head, sed and which. The process and system helpers are pgrep, pkill, k9, uptime, windev, winutil and winutildev. The navigation and listing helpers are g, docs, la and ll. Running Show-Help in PowerShell lists the full command set, which is the discovery path the README points to for the full command list.

Two of those names are worth a second look. The pgrep, pkill and head and sed names are the Unix ones, brought to a shell where the native equivalents are Get-Process and Get-Content, and the profile is explicit in its own description that it aims to make Windows Terminal look and behave like a Linux terminal. k9 is a longer-standing joke name for a force-kill command than any of the others, which tells you the tone of the project.

The trade is shadowing. A profile that defines touch and head in the global scope overrides or competes with whatever else on the machine defines them, and in a shared environment that is a genuine hazard. The commands are cheap to remove if they collide, and the override mechanism described later is how you would do it.

Customisation belongs in CTTcustom.ps1, not in the profile file

The profile file is managed, and the README is direct about it: do not edit Microsoft.PowerShell_profile.ps1 directly, because it is updated from this repository. Anything you write there will be overwritten on the next update.

There are two sanctioned places to put your own code. The first is the all-hosts profile, which you open with the Edit-Profile command. The second is a file named CTTcustom.ps1 placed beside Microsoft.PowerShell_profile.ps1, and the ordering matters: it is loaded before the profile reads its override variables and functions, which is what makes it the right place to define them.

The override surface is a fixed set of names, listed in the README. Six variables: $EDITOR_Override, $debug_Override, $repo_root_Override, $show_help_Override, $timeFilePath_Override and $updateInterval_Override. Seven functions: Debug-Message_Override, Update-Profile_Override, Update-PowerShell_Override, Clear-Cache_Override, Get-Theme_Override, WinUtilDev_Override and Set-PredictionSource_Override.

The naming convention with the _Override suffix is what makes the mechanism safe, and the README closes it with one warning: avoid calling the original function from your override, otherwise the override will recurse. If Update-Profile_Override calls Update-Profile, you have built an infinite loop, and the advice is to reimplement the behaviour rather than delegate to the version you are replacing.

One theme file, one environment variable

The visual side is small and replaceable. By default the profile points oh-my-posh at a single theme file in your home directory:

$Home\cobalt2.omp.json

The installer downloads that file into the PowerShell profile directory, so the default works straight after installation. To use a different oh-my-posh theme, set the POSH_THEME environment variable to another path.

The design point is separation again. The theme is a file, not a script, and the pointer to it is an environment variable, so changing the appearance of the prompt does not mean editing the profile or replacing a theme definition in place. A user who wants a different look can point POSH_THEME at their own .omp.json and leave the repository alone.

The other half of the appearance is the font, CaskaydiaCove NF, which the installer places and which you must select manually in Windows Terminal settings after restarting. Since the profile and the font are installed by different mechanisms, a user who skips the font step ends up with correct code and wrong glyphs, which is the single most common way this setup looks broken.

Where a ready-made dotfiles profile is the wrong answer

There is a category of user this does not serve, and it is not a small one. A profile that replaces your PowerShell profile wholesale, adds a dozen global command names, and depends on a Nerd Font, a set of optional binaries and a Windows Terminal configuration is a decision about your whole shell. On a locked-down corporate machine, where running a downloaded script with iex as Administrator is not something you can do, none of it applies.

A second mismatch is the update model. Because the profile file is replaced from the repository, a user who has edited it will lose those edits, and the workflow for avoiding that depends on understanding the override mechanism rather than just copying the file. The design is correct, but it is a design you have to learn before you touch it, and the README is short.

A third is scope of platform. The README describes a PowerShell 7 profile for Windows Terminal, and the sample commands assume Windows concepts such as Recycle Bin access through the trash helper and device tooling through windev. The Linux-like feel is a coating over a Windows shell, which is exactly what the project wants and exactly what makes some users prefer their existing profile.

For a reviewer weighing the dependency, the last push was on 2026-08-09, the repository has no tagged releases, and the licence is MIT with a LICENSE file at the root. There is no versioned artefact to pin, so a user following the install command is running the current main branch, which is a sensible trade for a dotfiles repository and a reason to read setup.ps1 first.

Editorial conclusion

The profile suits a Windows developer who wants a modern terminal with git and file shortcuts working on a new machine in one command, and who accepts a PowerShell 7 and Windows Terminal workflow. It does not suit a shared or locked-down workstation where running a piped script as Administrator is not on the table, and it does not suit someone who wants to keep their own profile file, because the shipped file is replaced from the repository and changes belong in CTTcustom.ps1. Before installing it, read setup.ps1, since the install path is a remote script executed with iex, and decide which of the optional tools you actually want, because everything outside PSReadLine is skipped with a warning when it is absent. The licence is MIT and the last push was on 2026-08-09.

Frequently asked questions

Official sources

1. ChrisTitusTech/powershell-profile on GitHub
2. Issues
3. License: MIT
4. README