Windows Terminal Like a Pro: Profiles, Fonts, and Shortcuts

A practical mental model: Terminal is a host, profiles are contracts

Think of Windows Terminal as a well-behaved multiplexer with opinions. It doesn’t “be” PowerShell or WSL; it hosts them. Your job is to define the contracts: what shell starts, with what working directory, under what environment, with what font and keybindings, and with what safety rails.

If you treat profiles as decorative (“I’ll just click the dropdown”), you’ll end up with the same failure mode as a sloppy SRE runbook: ambiguity under pressure. Profiles should answer these questions without you thinking:

• Which environment am I in: prod, staging, personal, on-call?
• Which identity am I using: local user, admin, SSH key A or B?
• What is the default directory and the default toolchain?
• What safety features are enabled: confirm prompts, read-only mounts, warnings?

This is not aesthetics. This is operational correctness. The terminal is the cockpit. Label your switches.

Interesting facts and context you can use in arguments

1. Windows Terminal is relatively new: Microsoft introduced it publicly in 2019, and it became a mainstream default on many Windows 11 setups later. The point: it’s still evolving; your “it used to work” memory may be version-specific.
2. ConPTY was the turning point: the Windows Console Pseudo-terminal (ConPTY) enabled modern terminal apps to talk to console programs in a more Unix-like way. Before that, terminal emulation on Windows was… character building.
3. The old Console Host (conhost.exe) is still around: Windows Terminal can host classic console apps, but they may still behave like they were built for a different era, because they were.
4. PowerShell has two personalities: Windows PowerShell (5.1) is the legacy inbox version; PowerShell (7+) is cross-platform and actively developed. Mixing them without labeling your profile is an avoidable foot-gun.
5. WT supports multiple renderers: modern GPU-accelerated text rendering can be fast, but also exposes font and glyph issues you never saw in older consoles.
6. Tabs and panes are not just UI candy: they reduce context switching. Used badly, they create “where am I?” errors. Used well, they turn incident response into a repeatable flow.
7. Settings moved from a JSON-only world: early Windows Terminal was configured primarily via settings.json; now there’s a UI, but JSON remains the source of truth for reproducible setups.
8. NERD fonts aren’t “a theme”: they’re patched fonts with extra glyphs. If you don’t need those glyphs, you don’t need the font—and you reduce a whole class of rendering weirdness.

Profiles: make environments boring on purpose

Profile design rules that prevent real mistakes

Here are the rules I enforce on teams:

• Name profiles like you name infrastructure: “WSL Ubuntu” is fine for a laptop. For real work: “WSL: ubuntu (staging tooling)”, “PowerShell 7 (admin)”, “SSH: bastion (prod-readonly)”.
• Default directory is a policy, not a preference. Start in a safe place with known scripts, not the last random directory you happened to cd into.
• Make prod visually distinct. Different color scheme, tab title, and even a different cursor style. You want your brain to notice.
• Prefer explicit commandlines over “whatever the system finds”. Pin to pwsh.exe vs powershell.exe, and pin WSL distributions by name.
• Use one place for automation: keep profile scripts in version-controlled dotfiles when possible. Local-only magic is how you build snowflakes.

Settings structure that stays maintainable

Windows Terminal settings are a merge of defaults and your overrides. You don’t need to rewrite the world. You need to define: default profile, profiles list, appearance defaults, and bindings. Treat it like infrastructure-as-code: minimal, explicit, reviewable.

Key fields you should understand and use deliberately:

• defaultProfile: what launches when you open Terminal. If you don’t set this, you get surprises after installs and updates.
• profiles.list: your curated profile definitions.
• guid: the stable identity of a profile. If you edit profiles by name only, you’ll eventually collide with auto-generated ones.
• commandline: exactly what starts. Prefer explicit paths for non-inbox shells.
• startingDirectory: the first place your shell lands. Boring is good.
• tabTitle and name: one is the display label, one is the profile selector. Use both.
• colorScheme, cursorShape, font: visual safety rails.

Profile patterns that work in production

Pattern 1: “Admin” is a separate profile. Don’t rely on “Run as administrator” as a habit. You want a profile that clearly says “you are holding the chainsaw.” Different icon, different scheme, different title. Then use it intentionally.

Pattern 2: “Prod” is read-only by default. If your workflow can tolerate it, use an SSH profile that lands you on a bastion with restricted permissions, or a shell that exports guardrail environment variables. Make “break glass” a separate profile with an obvious name.

Pattern 3: “Tooling” profiles are per context. If you have Kubernetes contexts, AWS profiles, or different SSH configs, don’t load all of them in every shell startup. Create profiles that load what they need. Startup time matters; so does correctness.

Fonts: readability, ligatures, and the tyranny of missing glyphs

Pick a font like you pick a monitoring dashboard

Your terminal font isn’t a fashion statement. It’s an interface. Your font choice affects:

• How quickly you spot a typo in a command that can delete things.
• Whether box-drawing characters render correctly (think: tables, tmux-like UI, CLIs).
• Whether Powerline or Nerd Font symbols show up as squares.
• Whether the GPU renderer struggles (rare, but real on older systems).

My opinionated advice:

• Default to Cascadia Mono or another clean monospaced font that renders well on Windows. Keep it boring until you have a reason not to.
• Only use a Nerd Font if you need glyphs. If your prompt theme depends on icons, fine. If you just want to feel modern, don’t. Missing glyphs are operational noise.
• Disable ligatures unless you have a strong preference. Ligatures can make operators misread !=, =>, or == in certain fonts. When you’re tired, you want literal.

First short joke: Ligatures are like caffeine—amazing until you realize they’re hiding the truth and now you can’t sleep.

Font problems that look like “the system is cursed”

If you see squares, question marks, or misaligned prompt symbols, it’s almost always one of these:

• You picked a font without the needed Unicode glyphs.
• Your shell is emitting Powerline symbols but your font isn’t patched.
• Fallback fonts are being used inconsistently because the primary font lacks characters.
• Your font metrics cause line height issues; the cursor doesn’t align, or text overlaps.

The fix is rarely “reinstall Windows Terminal.” It’s “choose a font that matches your prompt.”

Shortcuts: muscle memory beats creativity

Bind for incident response, not for fun

Keybindings are where good terminal users become fast terminal users. But random shortcuts are worse than none; they create false confidence. Pick a small set and standardize them across your machines.

My recommended binding philosophy:

• Keep defaults when they’re sane. Windows Terminal defaults are mostly sensible for tabs/panes.
• Standardize pane splits to the same keys you use in other multiplexers if you live in them. Consistency beats novelty.
• Make “copy” and “paste” predictable. Decide whether selection automatically copies, whether right-click pastes, and what Ctrl+V does. Then enforce it.
• Have a “panic close” behavior that prompts you. Accidentally closing the wrong tab mid-incident is a special kind of pain.

Tabs, panes, and the “wrong pane” failure mode

Panes are wonderful until they aren’t. The core operational failure mode is executing a command in the wrong pane. The cure is not “be more careful.” The cure is:

• Distinct tab titles that include environment markers.
• Color schemes by environment.
• Keyboard shortcuts for “focus pane” that are easy and consistent.
• Starting commands that set a visible prompt or title per environment.

Hands-on tasks: 12+ checks, commands, outputs, decisions

These are real tasks you can run on a Windows box with WSL installed. I’m using WSL because it gives us a consistent shell for commands and outputs, and because modern Windows Terminal users usually have it anyway. Each task includes: the command, what the output means, and the decision you make.

Task 1: Verify Windows Terminal is installed and identify the package

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-AppxPackage Microsoft.WindowsTerminal | Select-Object Name, Version, PackageFullName"
Name                          Version      PackageFullName
----                          -------      ---------------
Microsoft.WindowsTerminal     1.21.3471.0  Microsoft.WindowsTerminal_1.21.3471.0_x64__8wekyb3d8bbwe

What it means: You’re seeing the installed Windows Terminal package and version.

Decision: If this is missing or ancient, stop debugging settings. Upgrade first; behavior changes across versions.

Task 2: Locate the settings file path you’re actually editing

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Test-Path $p; $p"
True
C:\Users\cr0x\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

What it means: The settings file exists at the canonical packaged-app location.

Decision: If Test-Path is False, you may be on a different install channel or the file hasn’t been created. Open Terminal once, or find the correct package folder.

Task 3: Validate settings.json is valid JSON (catch trailing commas fast)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Get-Content $p -Raw | ConvertFrom-Json | Out-Null; 'JSON OK'"
JSON OK

What it means: Your settings file parses. If it doesn’t, Terminal may silently ignore parts or fall back to defaults depending on the failure.

Decision: Fix JSON before touching anything else. Invalid JSON makes every other symptom look random.

Task 4: List profiles and their GUIDs to avoid editing the wrong one

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; $j.profiles.list | Select-Object name, guid, source"
name                    guid                                   source
----                    ----                                   ------
PowerShell              {61c54bbd-c2c6-5271-96e7-009a87ff44bf} Windows.Terminal.PowershellCore
Windows PowerShell      {0caa0dad-35be-5f56-a8ff-afceeeaa6101} Windows.Terminal.Powershell
Ubuntu                  {2c4de342-38b7-51cf-b940-2309a097f518} Windows.Terminal.Wsl

What it means: You have multiple PowerShell flavors plus WSL. GUIDs are the stable handles.

Decision: Pick the one you want to change and target by GUID, not by guesswork.

Task 5: Check which profile is currently the default

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; (Get-Content $p -Raw | ConvertFrom-Json).defaultProfile"
{61c54bbd-c2c6-5271-96e7-009a87ff44bf}

What it means: Terminal will open PowerShell 7 by default (in this example GUID).

Decision: Set the default profile explicitly to match your most common safe workflow. Don’t leave this to chance.

Task 6: Inspect where the profile starts (startingDirectory)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; ($j.profiles.list | Where-Object name -eq 'PowerShell').startingDirectory"
C:\Users\cr0x

What it means: Your PowerShell profile opens in your user home.

Decision: If you do ops work, consider starting in a dedicated C:\ops or repo folder with scripts and notes. Fewer “where is that file?” moments.

Task 7: Identify which shell you’re actually running (pwsh vs powershell)

cr0x@server:~$ powershell.exe -NoProfile -Command "$PSVersionTable.PSVersion.ToString()"
5.1.22621.2506

What it means: This command ran in Windows PowerShell 5.1 (because we invoked powershell.exe).

Decision: If you think you’re on PowerShell 7 but you’re not, modules and TLS defaults can differ. Use pwsh.exe explicitly in profiles that require it.

Task 8: Confirm PowerShell 7 availability (and its path)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Command pwsh | Select-Object Source, Version"
Source                         Version
------                         -------
C:\Program Files\PowerShell\7\pwsh.exe 7.4.1

What it means: PowerShell 7 is installed and discoverable.

Decision: Point your PowerShell 7 profile commandline directly at this path to avoid PATH weirdness.

Task 9: List installed WSL distributions (and choose a stable target)

cr0x@server:~$ powershell.exe -NoProfile -Command "wsl.exe -l -v"
  NAME            STATE           VERSION
* Ubuntu          Running         2
  Debian          Stopped         2

What it means: WSL has Ubuntu and Debian. Ubuntu is default (asterisk) and currently running.

Decision: If you have multiple distros, make separate profiles pinned with wsl.exe -d Ubuntu etc. Don’t rely on the default distro.

Task 10: Measure startup time of a shell to detect “slow profile” scripts

cr0x@server:~$ powershell.exe -NoProfile -Command "Measure-Command { pwsh.exe -NoProfile -Command \"exit\" } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
142.8817

What it means: Starting PowerShell 7 without loading a profile is fast.

Decision: If -NoProfile is fast but normal startup is slow, your profile script is the culprit. Fix your dotfiles, not Terminal.

Task 11: Identify if your PowerShell profile is doing expensive work

cr0x@server:~$ pwsh.exe -NoProfile -Command '$PROFILE; Test-Path $PROFILE; Get-Content $PROFILE -TotalCount 20'
C:\Users\cr0x\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
True
Import-Module posh-git
Import-Module oh-my-posh
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression

What it means: The profile imports modules and initializes a prompt theme. That can be slow, especially if modules are on a network profile or antivirus is aggressive.

Decision: Cache prompt init, lazy-load modules, or create a “minimal” profile for on-call.

Task 12: Check whether you’re accidentally loading network home paths (latency land)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Item env:USERPROFILE, env:HOMEDRIVE, env:HOMEPATH, env:HOMESHARE | Format-Table -AutoSize"
Name        Value
----        -----
USERPROFILE C:\Users\cr0x
HOMEDRIVE   C:
HOMEPATH    \Users\cr0x
HOMESHARE

What it means: No network home share is configured (in this example).

Decision: If HOMESHARE points to a UNC path, expect slow prompts if your profile touches the home directory at startup.

Task 13: Verify font availability (catch “I set a font that isn’t installed”)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' | Select-String -Pattern 'Cascadia|Nerd|Caskaydia' -SimpleMatch"
Cascadia Mono (TrueType)    REG_SZ    CascadiaMono.ttf
Cascadia Code (TrueType)    REG_SZ    CascadiaCode.ttf

What it means: Cascadia fonts exist. Your settings referencing them should work.

Decision: If your chosen font name doesn’t appear, install it or stop referencing it. Terminal won’t magically find a font you made up.

Task 14: Detect binding conflicts by grepping for duplicated keys

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $raw = Get-Content $p -Raw; ($raw | Select-String -Pattern '\"keys\"' | Measure-Object).Count"
24

What it means: There are 24 keybinding entries in the file (counting occurrences of the word "keys").

Decision: If you’ve been experimenting, you probably have collisions. Consolidate. The best binding set is the one you can explain to a teammate.

Task 15: Validate your SSH config is being used (profile correctness)

cr0x@server:~$ wsl.exe -d Ubuntu -- bash -lc "grep -nE '^(Host|  HostName|  User|  IdentityFile)' ~/.ssh/config | head -n 20"
1:Host bastion-prod
2:  HostName bastion.prod.example
3:  User ops
4:  IdentityFile ~/.ssh/id_ed25519_ops

What it means: Your SSH config defines a bastion host with a specific key.

Decision: Build a Terminal profile that runs ssh bastion-prod so operators don’t type hostnames at 3 a.m.

Fast diagnosis playbook: what to check first/second/third

This is the quick triage when Windows Terminal “feels slow,” text input lags, tabs take forever, or copy/paste behaves inconsistently. You’re hunting for the bottleneck, not vibes.

First: isolate whether Terminal is the problem or the shell is

1. Start a shell with no profile (PowerShell: pwsh -NoProfile). If it’s fast, your profile scripts are the problem.
2. Start a plain cmd-like session (or a minimal PowerShell profile). If the terminal UI is still laggy, look at rendering/font and GPU/remote desktop factors.
3. Try WSL with a minimal command (like wsl -d Ubuntu -- echo ok). If that’s slow, WSL startup or filesystem integration is involved.

Second: check the top three common time sinks

1. Profile scripts hitting the network: module imports from UNC paths, git status in huge repos, prompt themes reading theme files across synced folders.
2. Antivirus scanning: especially on module directories or home directories in OneDrive/synced paths.
3. Font/glyph fallback behavior: patched fonts or missing glyphs can cause rendering jank and cursor misalignment.

Third: identify environment-specific multipliers

1. Remote Desktop sessions: graphics acceleration and clipboard integration behave differently; you may see input lag that doesn’t exist locally.
2. Huge scrollback and heavy output: some CLIs dump thousands of lines; rendering becomes the bottleneck. Reduce output, or adjust scrollback.
3. ConPTY edge cases: older console apps may behave poorly; try running them in classic console as a sanity check.

If you do this in order, you stop guessing. You also stop “optimizing” the wrong thing.

Common mistakes: symptoms → root cause → fix

1) “My prompt is slow; Terminal must be slow.”

Symptoms: New tabs take seconds. The cursor appears, but you can’t type for a bit. CPU spikes during startup.

Root cause: Your shell profile does expensive work: git status in large dirs, module imports, theme init, network checks, calls to cloud CLIs.

Fix: Create two profiles: “minimal” (on-call) with -NoProfile or a lean profile, and “full” for daily dev. Lazy-load modules and avoid network calls in the prompt path.

2) “My icons are squares; Windows Terminal is broken.”

Symptoms: Powerline separators show as tofu (□). Box-drawing looks wrong. Prompt alignment is off.

Root cause: Font missing glyphs or inconsistent fallback fonts. Sometimes you set a font name that isn’t installed.

Fix: Install the right font and reference its exact name, or stop using icon-heavy prompts. Also set lineHeight if needed to avoid overlap.

3) “Copy/paste is inconsistent and I keep pasting into prod.”

Symptoms: Selection sometimes copies, sometimes doesn’t. Right-click sometimes pastes. Ctrl+V behaves differently between panes/apps.

Root cause: Mixed settings across Terminal, shell, and remote sessions; plus muscle memory from other terminals.

Fix: Decide a policy and enforce it in settings: consistent copy/paste bindings and selection behavior. Make prod profile visually distinct so your eyes catch “wrong pane” mistakes.

4) “Tabs got duplicated or profiles changed after an update.”

Symptoms: New default profiles appear; your carefully named ones are buried; default profile flips.

Root cause: Auto-generated profiles from installed shells; your defaultProfile wasn’t explicitly pinned; you relied on a name rather than GUID.

Fix: Set defaultProfile to the intended GUID. Curate profiles.list. Delete or hide auto-generated profiles you don’t want exposed.

5) “WSL starts, but file operations are painfully slow.”

Symptoms: Git status crawls. Node installs take forever. Anything in /mnt/c feels sluggish.

Root cause: You’re doing Linux-y workloads on the Windows filesystem mount (/mnt/c), which is slower than the WSL ext4 filesystem for metadata-heavy tasks.

Fix: Keep repos inside the WSL distro filesystem (e.g., ~/src). Use a profile that starts there.

6) “Keyboard shortcuts don’t work in remote sessions.”

Symptoms: Pane split shortcuts don’t trigger; key combos are swallowed.

Root cause: RDP/client key mapping, OS-level hotkeys, or application-level intercepts.

Fix: Rebind conflicting combos in Terminal, and choose shortcuts that survive your remote tooling. Test on the actual path operators use.

Three corporate mini-stories (because reality has plot twists)

Mini-story 1: The incident caused by a wrong assumption

They were migrating a build-and-release pipeline from legacy Windows PowerShell to PowerShell 7. Locally, everything looked fine. In Windows Terminal, the engineer had a “PowerShell” profile and assumed it meant the new one. The name was the same as their mental model: PowerShell equals modern.

During a production hotfix, they opened a new tab and ran a script that pulled dependencies using TLS defaults. It worked on their laptop when they tested in pwsh. In the incident call, it failed in their tab because it was actually Windows PowerShell 5.1 with different defaults and module behavior. The error message wasn’t dramatic; it was worse: it was ambiguous. People started blaming the artifact repo.

They “fixed” it by retrying and temporarily bypassing validation in a way that made security uncomfortable. The hotfix shipped, but the post-incident review was not fun. The root cause wasn’t the repo. It was the wrong terminal profile. The tab looked like every other tab.

The remediation was boring and effective: explicit profile names (“PowerShell 7” vs “Windows PowerShell”), pinned commandlines, and a default profile set by GUID. They also changed the tab title to include PS7 or PS5. After that, the failure mode stopped existing. Not reduced. Eliminated.

Mini-story 2: The optimization that backfired

A team wanted their prompts to show everything: git branch, dirty state, Kubernetes context, cloud account, and the current incident ticket ID. It looked impressive in screenshots and demos. It also did a small amount of work on every prompt render—meaning every command, every Enter press, every tab completion.

To speed it up, they added caching. Great idea in theory. The cache lived in the user profile directory, which on corporate machines was synced and sometimes redirected. Under normal conditions it was fine. Under VPN jitter, the cache reads became slow, and suddenly typing felt like lag. People blamed Windows Terminal’s rendering.

The real problem surfaced when an engineer tried to reduce output during a live incident by splitting panes and tailing logs. The prompt theme constantly re-evaluated networked context; the cache thrashed. The terminal was responsive, the shell was not, and the operator was effectively fighting their own prompt.

They rolled back to a minimal prompt for ops profiles: git branch only, no network lookups, no cloud context. They kept the fancy prompt for dev profiles. Optimization wasn’t the villain; optimizing the wrong place was. Second short joke: The fastest prompt is the one that doesn’t try to earn a performance bonus.

Mini-story 3: The boring but correct practice that saved the day

Another org had a habit that looked excessive: they maintained a version-controlled Windows Terminal settings.json snippet for on-call engineers. It wasn’t mandatory, but it was strongly encouraged. The snippet defined a small set of profiles: “On-call PowerShell (minimal)”, “WSL tooling”, “SSH bastion (prod)”, and “SSH bastion (staging)”.

The prod SSH profile did something unglamorous: it set a loud tab title, a red-ish color scheme, and a custom starting command that printed a short warning banner. It also enforced a different cursor shape. People joked about it until the first time it prevented a mistake.

During an outage, an engineer had four panes open: metrics query, log tail, SSH into staging, SSH into prod. They almost pasted a staging-only cleanup command into prod. They noticed the cursor shape and the tab title at the last second. No heroics, no drama—just a safety rail doing its job.

The postmortem call was almost anticlimactic: “We nearly did something bad, but the terminal profile made us stop.” That’s what you want. Reliability is mostly the absence of exciting stories.

Checklists / step-by-step plan

Plan A: Build a sane profile set in under an hour

1. Inventory your shells: PowerShell 5.1, PowerShell 7, WSL distros, SSH usage patterns.
2. Create four baseline profiles:
   • PowerShell 7 (daily)
   • PowerShell 7 (minimal / on-call)
   • WSL (tooling) starting in ~/src
   • SSH: bastion (prod) with loud visuals
3. Pin defaultProfile to the safest common option (often PS7 minimal).
4. Pick one font and stick to it. If you must use Nerd Fonts, do it intentionally and verify glyphs.
5. Define 6–10 shortcuts you actually use: new tab, close tab (with confirm), split pane, focus pane, search, copy, paste.
6. Test the wrong-pane scenario: open prod/staging profiles side by side and make sure you can tell instantly which is which.
7. Validate JSON after edits. Don’t trust your eyes.

Plan B: Fix slowness without breaking your workflow

1. Measure: time pwsh -NoProfile startup versus normal. If there’s a gap, profile scripts are guilty.
2. Minimize: create a minimal profile and use it when latency matters.
3. Remove network calls from prompts and startup. No cloud context checks. No auto-update checks. No fetching git status in huge repos.
4. Check font and rendering only after shell startup is proven fast.
5. Standardize: keep one known-good settings baseline. Drift is how “it’s slow on my machine” becomes a team sport.

Plan C: Make it reproducible across a team

1. Define a baseline settings.json fragment (profiles, schemes, bindings).
2. Decide what’s personal: background image, opacity, experimental themes—keep those out of the baseline.
3. Document the contract: what “On-call” profile means, what it loads, and what it intentionally doesn’t.
4. Review changes like code. Keybindings and prod visuals should not be “whatever.”

One reliability idea worth keeping in your head

Paraphrased idea (attributed to John Allspaw): “Blameless learning works best when you focus on how people’s local context made actions reasonable at the time.”

Terminal mistakes are often context mistakes: wrong pane, wrong identity, wrong shell. Your job is to make the right action easy and the wrong action obvious.

FAQ

1) Should I edit settings in the UI or in settings.json?

Use the UI for quick tweaks; use JSON for anything you’d want to reproduce, review, or roll back. If you care about consistency, JSON is the source of truth.

2) Why do I have multiple PowerShell profiles?

Because you likely have both Windows PowerShell (5.1) and PowerShell 7 installed, and Terminal can auto-detect them. Rename them clearly and pin commandlines so you always know what you’re running.

3) What’s the best font?

The best font is the one you can read at 3 a.m. and that renders your symbols correctly. Start with Cascadia Mono. Switch to a Nerd Font only if your prompt truly needs icons.

4) My prompt theme looks cool but it’s slow. What should I do?

Split into two profiles: a minimal ops profile and a full dev profile. Remove network lookups from prompt rendering and avoid expensive git operations by default.

5) How do I stop pasting into the wrong pane?

Make environments visually distinct (scheme, title, cursor). Bind focus-pane shortcuts you can hit without thinking. And keep prod profiles “loud” on purpose.

6) Why is WSL fast in Linux paths but slow in /mnt/c?

Because metadata-heavy workloads (git, npm, small-file builds) are slower on the Windows filesystem mount. Put repos in the WSL filesystem and start your WSL profile there.

7) Why did my default profile change?

Updates and new shell installs can add profiles. If you didn’t set defaultProfile explicitly by GUID, you left the decision to chance. Pin it.

8) How do I keep shortcuts consistent across machines?

Keep a baseline settings.json (or a snippet) under version control and apply it across machines. Avoid per-device randomization for anything that affects navigation and safety.

9) Does GPU acceleration cause issues?

Usually it helps. When it hurts, it tends to show up as rendering glitches with certain fonts or in remote sessions. Prove the shell is fast first; then test with a simpler font and reduced visual effects.

Next steps you’ll actually do

1. Create a minimal on-call profile (PowerShell 7 with -NoProfile or a lean profile script). Make it the default for incident work.
2. Rename and pin your profiles so you never confuse PS5 vs PS7 or staging vs prod again.
3. Pick one font, verify it’s installed, and stop chasing glyph dragons unless you truly need them.
4. Standardize 6–10 shortcuts and practice them until they’re automatic. Under stress, your hands should know the route.
5. Run the fast diagnosis playbook the next time Terminal “feels slow.” Measure first. Then fix the actual bottleneck.

If you do only one thing: make prod visually loud and your on-call profile boring. That’s professionalism disguised as aesthetics.