~iany/ PowerShell

Use tmux for PowerShell in Windows Terminal

me@iany.me (Ian Yang) — Thu, 29 Jan 2026 23:30:42 +0800

You can get tmux session persistence and multiplexing in Windows Terminal by running tmux inside WSL and setting the default shell to PowerShell. New panes and windows will then start pwsh.exe instead of a Linux shell. Here’s a minimal setup using small wrappers and the tmux -C attach trick to configure new sessions.

Why tmux under WSL with PowerShell?

Since tmux does not run natively on Windows, the standard approach is to use it through WSL. However, if you launch wsl tmux from Windows Terminal, all panes will default to your WSL shell. When working in a Windows directory, I prefer to use native PowerShell within the Windows environment.

To ensure every tmux pane runs PowerShell, configure tmux to use pwsh.exe as its default command. When you launch pwsh.exe from WSL within a Windows directory, it brings us back to the Windows environment.

Wrappers so you can call tmux from PowerShell

Put these in a directory on your PATH (e.g. ~/Documents/PowerShell/bin).

PowerShell — tmux.ps1:

wsl tmux $args

Cmd — tmux.cmd:

@echo off
wsl tmux %*

From PowerShell or Cmd you can then run tmux new, tmux attach, etc., and they all go to WSL’s tmux.

Creating PowerShell Sessions

The next piece is a script that creates a new session whose default command is pwsh.exe, or attaches if that session already exists. Example usage: tmux-pwsh dev or tmux-pwsh work.

The script sets the default command only for sessions it creates; it does not affect sessions started with a standard tmux new-session.

tmux-pwsh.ps1:

param(
[Parameter(Mandatory=$true)]
[string]$SessionName
)
$pwshCommand = "exec pwsh.exe -nologo"
# Check if session exists using exact name match
wsl tmux has-session -t "\=$SessionName" 2>$null
if ($LASTEXITCODE -ne 0) {
wsl tmux new-session -d -s $SessionName $pwshCommand
echo "set-option default-command `"$pwshCommand`"" | `
wsl tmux -C attach -t "\=$SessionName" >$null
}
wsl tmux attach -t "\=$SessionName"

Note:

The = prefix does an exact session name match and must be escaped when sending the command from PowerShell to WSL.
The new session specifies command pwsh.exe via the command argument.
Running wsl tmux set-option immediately after creating the session does not work because there’s a brief window where the session is not available for setting options. Instead, sending set-option via tmux -C attach reliably applies the setting.

After this, splitting panes and creating new windows in that session will all start pwsh.exe -nologo in Windows Terminal.

Summary

Use WSL for tmux and PowerShell as the default command by setting tmux’s default command to exec pwsh.exe -nologo.
tmux.ps1 / tmux.cmd — thin wrappers so tmux from Windows means wsl tmux.
tmux-pwsh.ps1 <name> — create (or attach to) a named session that uses PowerShell as the default command.

Once these are on your PATH, run e.g. tmux-pwsh dev from Windows Terminal to get a tmux session where every pane is PowerShell.

Temporary Vi Mode in PowerShell

me@iany.me (Ian Yang) — Sat, 22 Nov 2025 23:17:05 +0800

I miss the feature in readline (Bash/Zsh) where Ctrl+x, Ctrl+v switches to Vi command mode temporarily. In that workflow, entering Insert mode switches back to Emacs mode. PSReadLine has a command ViCommandMode, but binding it directly in Emacs mode will report errors on every key input.

The solution requires handling the mode change event to toggle the global EditMode between Emacs and Vi.

When entering “Insert” mode (the default for Emacs users), we force the mode to Emacs and set up the trigger for the temporary Vi mode. When that trigger (Ctrl+x, Ctrl+v) is fired, we switch the edit mode to Vi and jump to command mode.

Here is the configuration for your $PROFILE:

function OnViModeChange {
if ($args[0] -eq 'Insert') {
Set-PSReadLineOption -EditMode Emacs
Set-PSReadlineKeyHandler -Chord "Ctrl+x,Ctrl+v" -ScriptBlock {
Set-PSReadLineOption -EditMode Vi
[Microsoft.PowerShell.PSConsoleReadLine]::ViCommandMode()
}
# Add other Emacs key bindings here.
# Switching `EditMode` resets key bindings to their defaults.
# Remember to reconfigure them.
# Set-PSReadlineKeyHandler -Chord "Ctrl+w" -Function BackwardKillWord
}
}
Set-PSReadLineOption -ViModeIndicator Script
Set-PSReadLineOption -ViModeChangeHandler $Function:OnViModeChange
Set-PSReadLineOption -EditMode Emacs
# Reuse the function to start Emacs mode
OnViModeChange Insert

Switching EditMode resets key bindings to their defaults. Remember to reconfigure them.

Envrc Alternative for PowerShell in Windows

me@iany.me (Ian Yang) — Sat, 06 Apr 2024 08:55:34 +0800

This post introduces a solution for automatically setting up and tearing down shell environments for PowerShell in Windows. It is proposed as a potential alternative to the bash-based tool direnv, which, while effective at loading .envrc files in the current or nearest ancestor directory, has limited compatibility with PowerShell in Windows.

.envrc.ps1

The basic idea is creating a file .envrc.ps1 with two entries: setup and teardown. The setup entry is responsible for setting up the environment up entering the directory, and the teardown entry is used when leaving it.

PowerShell allows code to be executed from a file using the dot command. This means that the entire file can be used as the setup entry. For the teardown entry, a function can be defined within the same file, and I use the function name down.

The layout of the file .envrc.ps1 looks like:

# setup
$env:GH_TOKEN = "secret"
# teardown
function global:down {
$env:GH_TOKEN = ""
}

The global: scope before the function name is necessary when this file is loaded in the hook, as I will do later.

The corresponding commands for setup and teardown entries:

Setup: . .envrc.ps1
Teardown: down

Hook

To hook the setup and teardown entries, I reference this example.

using namespace System;
using namespace System.Management.Automation;
$hook = [EventHandler[LocationChangedEventArgs]] {
param([object] $source, [LocationChangedEventArgs] $eventArgs)
end {
# 1. `down` for $eventArgs.OldPath
# 2. `. .envrc.ps1` for $eventArgs.NewPath
}
};
$currentAction = $ExecutionContext.SessionState.InvokeCommand.LocationChangedAction;
if ($currentAction) {
$ExecutionContext.SessionState.InvokeCommand.LocationChangedAction = [Delegate]::Combine($currentAction, $hook);
} else {
$ExecutionContext.SessionState.InvokeCommand.LocationChangedAction = $hook;
};

To run the code snippet, PowerShell 7 or later is required. You can install it from the repository.

Here is the algorithm for identifying setup and teardown entries:

Find the nearest .envrc.ps1 for the old path.
Find the nearest .envrc.ps1 for the new path.
If the two paths are the same, skip the next step.
If they differ, invoke the down function and remove it if it exists. Then, if found, load the .envrc.ps1 file for the new path.

The full code example to be added into PowerShell $PROFILE file.

using namespace System;
using namespace System.Management.Automation;
# existing PowerShell profile contents
# skip when version is less than 7
if ($PSVersionTable.PSVersion.Major -lt 7) {
return
}
# find the .envrc.ps1 in the currenct directory or the nearest ancestor directory.
function Find-NearestEnvrc {
param (
[Parameter(Mandatory=$true)]
[string]$StartDir
)
$currentDir = Resolve-Path $StartDir
while ($currentDir -ne "") {
$envrcPath = Join-Path $currentDir ".envrc.ps1"
if (Test-Path $envrcPath) {
return $envrcPath
}
$currentDir = Split-Path $currentDir -Parent
}
return ""
}
# hook the setup and teardown entries
$hook = [EventHandler[LocationChangedEventArgs]] {
param([object] $source, [LocationChangedEventArgs] $eventArgs)
end {
$oldEnvrc = Find-NearestEnvrc $eventArgs.OldPath
$newEnvrc = Find-NearestEnvrc $eventArgs.NewPath
if ($oldEnvrc -ne $newEnvrc) {
Get-Command down -ErrorAction SilentlyContinu
if (Get-Command down -ErrorAction SilentlyContinu) {
down
Remove-Item Function:down
}
if ($newEnvrc -ne "") {
. $newEnvrc
}
}
}
};
$currentAction = $ExecutionContext.SessionState.InvokeCommand.LocationChangedAction;
if ($currentAction) {
$ExecutionContext.SessionState.InvokeCommand.LocationChangedAction = [Delegate]::Combine($currentAction, $hook);
} else {
$ExecutionContext.SessionState.InvokeCommand.LocationChangedAction = $hook;
};

Example Usage

# setup
# set environment variable
$env:GH_TOKEN = "secret"
# load python virtual env
. .venv\Scripts\Activate.ps1
# add a helper function
function global:build {
cargo build
}
# teardown
function global:down {
# unset environment variable
$env:GH_TOKEN = ""
# unload python virtual env
deactivate
# remove the helper function
Remove-Item Function:build
}