PowerShell remote use usually means one of two setups: Windows PowerShell's WinRM remoting (Enter-PSSession), or PowerShell 7+ (pwsh) over SSH — both of which require configuring the host, opening a network path to it, and working in sessions that end when the connection does. CLIAnywhere offers a third model: pwsh and powershell are supported shells on the host, the daemon hosts the session, and the iOS, Android or web client attaches to it from any network. The object pipeline runs entirely on the host, your $PROFILE and modules apply as usual, and a dropped phone connection ends nothing.
Short Answer
Install the CLIAnywhere daemon on the PC — Windows, macOS or Linux — where your PowerShell environment lives, install the app on your phone, and pair them once with an access key. Tapping the PC in the app opens the persistent shell session on that machine; if the host shell is pwsh, you get pwsh, with its profile, modules and object pipeline intact. There is no WinRM to enable, no PS Remoting to configure and no inbound port, because the daemon connects outward — peer-to-peer over DTLS where possible, through an encrypted relay otherwise.
Why This Is Difficult
Two editions of the shell coexist, and both matter. Windows PowerShell 5.1 (powershell.exe) ships inside Windows on .NET Framework and exists only on Windows. PowerShell 7 and later (pwsh, "PowerShell Core" historically) is a separate cross-platform install that runs on Windows, macOS and Linux and sits side by side with 5.1 — modules, profiles and defaults differ between them, so "run PowerShell remotely" first has to answer which PowerShell, on which machine.
The remoting machinery is the second obstacle. WinRM-based remoting must be enabled on the host (Enable-PSRemoting), listens on ports 5985 (HTTP) or 5986 (HTTPS), and wants a Kerberos domain or explicit TrustedHosts entries in workgroup setups. SSH remoting in pwsh needs an SSH server on the host and a network path to it. Both assume the host is addressable — which is exactly what a home machine behind NAT is not.
And like any connection-bound session, these die with the connection. A long Invoke-Command or an interactive prompt in a remote runspace does not survive a phone losing signal. The persistent-session problem described in the disconnect guide applies to PowerShell exactly as it does to bash.
Common Solutions
Option 1: WinRM / PowerShell Remoting
The native answer: run Enable-PSRemoting on the host, then Enter-PSSession -ComputerName pc01 or Invoke-Command from anywhere that can reach it. In a domain environment with proper firewalls this is the standard tool, and for administering many machines at scale nothing here replaces it.
The friction is at the edges: workgroup machines need TrustedHosts or certificate setup for HTTPS (port 5986); a home or small-office PC behind NAT is not reachable at all without a VPN or a port forward; and enabling WinRM widens the machine's attack surface. Sessions also end with the connection — an interrupted run does not wait for you.
Option 2: pwsh over SSH remoting
PowerShell 7 supports remoting over SSH instead of WinRM: New-PSSession -HostName pc01 after installing an SSH server and PowerShell's subsystem entry on the host. It is cross-platform (a Mac can remote into a Linux box and vice versa) and reuses SSH keys instead of WinRM's trust configuration.
The requirements are the familiar SSH ones: the host needs a reachable SSH endpoint — public IP, port forwarding, or a VPN — plus key management on whatever client you connect from. A phone SSH app plus SSH remoting is workable, but it stacks two layers of keyboard-hostile tooling, and the session is still tied to the connection.
Best for: cross-platform remoting where SSH reachability already existsOption 3: Remote desktop
Connecting to the machine's screen (Microsoft Remote Desktop, VNC, AnyDesk and similar) shows the whole desktop, PowerShell window included. It needs no shell-specific configuration and handles GUI tools too.
For terminal work it is heavy: a full-screen video stream to type Get-Service, awkward on a phone display, typically requiring a reachable RDP/VNC endpoint and an logged-in session left unlocked on the host. It is a reasonable fallback when you truly need the desktop — not a way to run cmdlets.
Option 4: CLIAnywhere
CLIAnywhere hosts the PowerShell session on the PC — pwsh or powershell, whichever the machine's setup provides — and the phone attaches to it. The object pipeline, your $PROFILE, imported modules and PSReadLine behavior all run on the host, untouched. The session persists: lose signal mid-command and the command continues; reconnect and the output is waiting in scrollback.
Nothing has to be enabled or exposed. The daemon makes an outbound connection (DTLS peer-to-peer where possible, encrypted relay otherwise), so WinRM can stay off, no port is forwarded, and no public address is needed.
Best for: using your own PC's PowerShell from a phone, from any networkUsing CLIAnywhere
Install the daemon on the PowerShell host
Install the open-source daemon from GitHub Releases on the Windows, macOS or Linux machine whose PowerShell you want — on Windows, antivirus software occasionally flags freshly built unsigned executables; see the Windows platform guide for the details. The setup guide covers every platform. On the phone: Android on Google Play, iOS on the App Store (see the download page), or the Web App.
Pair the app with the PC
Create an access key in the app and link it to the daemon — paste the key, or scan the daemon's QR code. Pairing uses a local SPAKE2 key exchange; the per-PC Security Code is generated on the PC and never uploaded. One account can hold several PCs, each with its own code.
Open the session and run cmdlets from the phone
Tap the PC in the app and you are in the host's shell — pwsh with your profile and modules if that is what the machine runs. Get-Service, Get-Process, pipelines with Where-Object and Sort-Object all execute on the PC; the phone shows the formatted output. Start a long command, pocket the phone, and reopen the same session later — output produced in between is in the scrollback.
| Supported shells | pwsh / powershell / cmd — plus bash, zsh, fish, sh |
|---|---|
| Shell and modules run on the host | Yes — $PROFILE and imports apply |
| Object pipeline preserved | Yes — pipeline never leaves the host process |
| WinRM / PS Remoting / SSH server required | No |
| Session survives disconnects | Yes, with scrollback |
| Windows / macOS / Linux host | Yes (Linux: desktop UI or headless CLI build) |
| iOS / Android / Web client | Yes — see the download page |
| Port forwarding / public IP required | No |
| Encryption | SPAKE2 key exchange + AES-256-GCM, P2P (DTLS) with encrypted relay (WSS) fallback |
| Open-source daemon | Yes — github.com/CLIAnywhere/clianywhere_daemon |
Example: Restarting a Stuck Service From the Road
A small Windows box at the office runs an internal web app as a Windows service. At 20:30 you get the message that the site is down; the usual fix is logging in and restarting the service — but you are an hour away.
From the phone, you open CLIAnywhere and tap the PC. The persistent pwsh session is where you left it. You type the pipeline you use every week:
Get-Service W3SVC | Select-Object Status, Name — the formatted table appears on the phone, produced on the PC. The service shows Stopped, so you run Start-Service W3SVC, wait a beat, and rerun the check: Running. A quick Get-EventLog -LogName System -Newest 5 -Source Service* shows why it stopped, and the whole exchange took ninety seconds. No VPN, no RDP session, no WinRM listener was involved, and the elevation question resolved the way it would at the keyboard — the session runs with the privileges of the host.
Had the phone lost signal mid-way, nothing would have been lost: the session on the PC would still be sitting there, command history and scrollback intact, waiting for the next connection — from the phone again, the web client, or tomorrow at the desk.
Security
Remote PowerShell is exactly the capability you do not want to expose loosely — which is why CLIAnywhere opens no listener at all. The daemon connects outward, keys are negotiated locally with SPAKE2 (the Security Code never leaves your PC), traffic is AES-256-GCM encrypted, the link is peer-to-peer over DTLS where possible, and the relay only ever sees ciphertext. See how CLIAnywhere handles security for details.