ShellPilot — Help

What ShellPilot Is

A self-contained, portable PowerShell workbench with AI assistance — built so the productivity gain never costs your environment its security posture.

ShellPilot is a single-file Windows application: no installer, no MSI, no service. Copy the executable to a workstation, a jump server, an admin terminal, or a USB stick, activate once per user-and-machine combination, and work. Settings live in the current user profile; you can move or update the executable any time. The runspace runs inside the application process, so output, formatting, and execution stay under the application's control instead of being scattered across console windows and ad-hoc files.

The point of ShellPilot is to make script-driven administration faster without making it riskier. You get AI assistance for the part you usually do not want to spend your day on — writing PowerShell — while the parts that matter for compliance and audit (script execution, logging, credential handling) stay on the rails your environment already enforces.

Productivity premise

AI-assisted PowerShell workflows for IT professionals who are experts in their domain — independent of how strong their own PowerShell is. ShellPilot shortens the path from intent to a working script for everyone, including seasoned PowerShell engineers who simply want it done faster
The full PowerShell surface area — anything PowerShell can do, including embedded C# via Add-Type, is available
Reports, summaries, and documentation output generated directly from your data and ready to paste into your ITSM, ticket, or change record
Session continuity — variables, modules, and login sessions persist across scripts, so a multi-step workflow stays one workflow
Dedicated Output Window — the current script's output in its own resizable window, optionally on a second monitor

Security premise

No telemetry. ShellPilot does not phone home with usage data, host metrics, or behavioural analytics
No automatic output forwarding. Script output is never sent to the AI or anywhere else unless you explicitly attach it
No server-side chat storage — by IT-grade reasoning. In an admin context, script content and execution output are not casual chat — they are operational data, often confidential. Treating them as a stored conversation would conflict with how IT environments handle that kind of information. So ShellPilot does not retain conversations on the server side. Optional local HTML export is available when you specifically need to document a session
No security-control bypass. AMSI, App Control, AppLocker, EDR, and PowerShell script-block logging all stay in effect — see the Security & Compliance section for the detailed breakdown

How to Order

Pick a plan at shellpilot.app, pay your way, and receive a 6-digit activation code by email. Three payment paths cover individuals, teams, and procurement-bound enterprises.

https://shellpilot.app/order

Choose your plan

Monthly billing · cancel anytime · save 10% annual

Selected

Starter

$34 /mo

Selected

Pro

$49 /mo

Selected

Pro+

$79 /mo

FastSpring

Invoice (B2B)

Pay with FastSpring All major cards (and PayPal as a payment option inside FastSpring). Instant activation. Merchant-of-Record handles VAT, fraud, and chargebacks.
Annual Invoice for business EU customers receive a EUR invoice via SEPA, US customers a USD invoice via ACH. Activation 1–2 business days after payment is received.
Or request a Demo Fill the demo form at shellpilot.app — SYSTANA LLC reviews and issues a trial license. Limited but useful for evaluation.
Magic code arrives by email After purchase you receive an activation email at the registered address with a 6-digit code, valid for 15 minutes.

Heads up: the 6-digit code is one-time and time-limited. If you miss the 15-minute window, request a new one from the activation dialog.

Activate Your Device

First launch shows the Activation window. Five seconds and your install is tied to your subscription — hardware-bound, encrypted at rest.

ShellPilot — Activation

—▢×

Activate Your Device

Bind this Windows install to your subscription.

Email

Code sent. Check your email.

6-Digit Code

Force activation (replace oldest device)

Activated.

Device bound to subscription. 2 of 3 devices in use.

Open ShellPilot. The Activation window appears automatically on first launch.
Enter the email address you used at checkout (or where the demo was sent).
Click Send Code. A 6-digit code arrives within seconds — valid 15 minutes, max 3 attempts.
Enter the code and click Activate.
Your device is now bound to your subscription. ShellPilot is a single-file application — there is no installer, no MSI, no setup. The activation, your settings, and your encrypted credentials live in the current user profile on this machine and stay there until you deactivate. A hardware fingerprint and DPAPI encryption keep them on this machine: they cannot be carried over by copying the executable to another machine, or used from a different user account on the same machine.
Portable by design. Copy ShellPilot.exe wherever you like — a USB stick, a network share, a jump server — and run it. The first launch on a given machine and user activates; from then on, you can move or delete the executable, download a newer version, or run it from a different folder, and ShellPilot still finds your activation and settings in your user profile and continues working as long as your subscription is active. The activation only ends when you deactivate it explicitly (/SPunregister, or replaced via Force Activation when you exceed the device limit), or when the subscription itself ends.
A different user account means a separate activation. Activation is tied to the user account that runs ShellPilot — domain user or local user, it makes no difference. If you start ShellPilot under a different account on the same machine — for example via Run as a different user, or by signing in as a different person — that account has its own profile and therefore its own activation slot. Two accounts on the same machine count as two devices against your subscription limit.
Roaming profiles do not multiply activations. The activation is bound to both the user account and the machine. A roaming profile does not let one activation cover several machines or several nodes of a terminal server farm. Each machine you want to use ShellPilot on counts as its own activation against your device limit.
ShellPilot needs Azure reachability to start and to run. ShellPilot's licensing infrastructure runs on Microsoft Azure in the European region. Every launch of the application opens an outbound HTTPS connection to api.shellpilot.app on port 443 to verify your subscription before the main window opens; the hourly licence heartbeat and any Cloud-AI request use the same path. That is the only outbound connection ShellPilot requires. If your environment enforces application control of any kind, ShellPilot has to be allowed there as well. The Azure infrastructure exists solely for activation, licensing, and request routing — ShellPilot does not collect telemetry, does not store your chat content, and does not analyse your scripts on the server side.
Device limit: up to 3 active devices per subscription. To activate a fourth, tick Force Activation — the oldest device is deactivated automatically.
Need to release this device manually? Type /SPunregister into the chat. The device is removed and the seat returns to the pool.

Security & Compliance

Designed so the security controls already in place on your endpoints stay in charge. ShellPilot integrates with what your environment enforces — it does not replace, route around, or downgrade it. The points below are the ones procurement, audit, and security reviewers usually want to see in one place.

Endpoint security stays in effect — no App Control, EDR, or AMSI bypass AMSI scans every PowerShell script block at the engine level, regardless of whether the engine is hosted in powershell.exe, pwsh.exe, or in ShellPilot's embedded runspace. App Control for Business (formerly WDAC) and AppLocker put the embedded runspace into ConstrainedLanguage mode the same way they put any other PowerShell session into it. Behavior-based EDR sees ShellPilot.exe loading the PowerShell runtime and executing scripts, and is free to act on what it observes. Application Guard, Defender ASR rules, and comparable controls do what they were configured to do. ShellPilot does not ship, document, or enable any evasion path against any of those controls — by design.
PowerShell script-block logging — enable it on the host, see everything ShellPilot runs PowerShell's script-block logging is the right channel to monitor every command that the embedded runspace and the external PowerShell execute. It writes to Microsoft-Windows-PowerShell/Operational. ShellPilot does nothing to disable or hide from this logging — but it does not turn it on for you either. If your security operations team needs full PowerShell visibility, enable script-block logging through Group Policy or the equivalent endpoint configuration tool on the systems that run ShellPilot. From that moment on, every script executed through ShellPilot is logged in the same event channel as any other PowerShell on the host. Standard SIEM and EDR pipelines that already consume PowerShell logs pick it up automatically.
Execution policy — Bypass for the session only ShellPilot sets the PowerShell execution policy to Bypass for its own session, both for the embedded runspace and for the external PowerShell launched by the yellow and red buttons. This is per-session and ends with the process; nothing on the machine or in the user profile is changed. Microsoft documents the execution policy as a guardrail against unintentional script execution, not a security boundary — "it's not a security boundary because it can't stop determined users from deliberately running scripts" (Microsoft Learn, about_Execution_Policies). A Group Policy Turn on Script Execution takes precedence for the external PowerShell path.
Credentials never reach the AI Read-Host, Get-Credential, and Read-Host -AsSecureString are intercepted by ShellPilot's custom PSHost. The input never appears as a chat message, never gets logged, and is never serialised into an AI request. SecureString content stays in protected memory and is handed to the runspace as a SecureString. The visual cues (orange and pink input border) and the two-step flow are documented in the Credentials section.
Script output stays local Output from your scripts never leaves your machine. It is only sent to the AI if you explicitly attach it as context to your next message.
No telemetry, no server-side chat storage The ShellPilot servers on Azure exist for activation, licensing, and request routing. They do not collect telemetry, do not store your chat content, and do not analyse your scripts.
ShellPilot's own events are written to the Windows Event Log ShellPilot's lifecycle events (start, activation, errors) are written to the Application event log under the ShellPilot source. This complements the PowerShell logging above — it lets IT confirm whether the application started cleanly on a given host.

ShellPilot Basic Configuration

Once you have activated, open Configuration → Settings and walk through the basic setup. None of these settings is mandatory — the defaults are usable — but spending one minute here tailors ShellPilot to your environment and your screen.

ShellPilot — Settings

PowerShell Environment

Preferred PowerShell Version:

Script Save Folder:

C:\Users\admin\Documents\ShellPilot\Scripts

Appearance

Font Size:

13

Performance Mode (for Terminal Server / RDP)

Use on systems without GPU. Requires app restart.

Preferred PowerShell VersionShellPilot detects every PowerShell installation that is reachable on your system and lists them here. The default Automatic (Detect at runtime) resolves to the most current PowerShell available on the machine at the moment a script is launched. If you need to pin a specific version — for example because your environment expects a particular PowerShell on every server — pick it explicitly from the list.

This dropdown controls which PowerShell the yellow and red triangle buttons launch as an external console. The persistent runspace inside the application uses its own engine independently — and that is a deliberate choice. ShellPilot embeds the official Microsoft PowerShell SDK; the runspace runs a current PowerShell engine regardless of what is installed on the host. Windows ships with Windows PowerShell 5.1 as a built-in component on every supported version, and that is enough for ShellPilot to operate — the modern PowerShell features you would otherwise need to install separately are already inside the application. Modules you add through the runspace (or through the external console) install into the user profile in the usual way and remain available across both execution paths. You can install, update, and import modules straight from the ShellPilot command line, without downloading a separate PowerShell first.
Script Save FolderWhen you save a script from chat to disk, this is where it lands. Set it to wherever you keep your operational scripts — a OneDrive folder, a network share, your local profile. ShellPilot does not write to it without your action.
Font SizeAdjusts chat, code, and output rendering between 10 and 18 points. Useful on high-DPI displays or when presenting on a beamer. Takes effect immediately, no restart required.
Performance ModeDesigned for Terminal Server, RDP, virtualised desktops, and any host without dedicated graphics. With Performance Mode enabled, ShellPilot switches its rendering to a software pipeline and slows down streaming refresh, which removes the load that animated typing and live output would otherwise place on a remote graphics channel. The result is a smoother session at the cost of some visual polish. Requires a restart to take effect.

Your First Chat

Tell ShellPilot what you want in your own language — German, English, French, Spanish, Japanese, whatever you prefer. ShellPilot replies in the same language. It writes the PowerShell, you run it — directly in the persistent runspace, or in a new PowerShell window.

Administrator: ShellPilot −□×

ConfigurationViewHelp

Ready

Natural language in, PowerShell outDescribe what you want in any language you prefer — ShellPilot replies in the same language and is purpose-built for PowerShell on Windows, returning scripts ready to run.
Every code block has one action row at the bottom — icons only, no text Green triangle — Execute in the embedded persistent runspace (in-process, your environment stays alive).
Yellow triangle — Open in an interactive PowerShell window (separate process).
Red triangle — Open as Admin (elevated PowerShell, UAC prompt).
On the right of the same row: ⬇ save to file, ⎘ copy to clipboard. Both available on Starter, Pro, Pro+. Disabled only in the Demo/Trial plan.
Execute (green) turns into a stop button while runningThe green triangle becomes a red square with a white square inside while the script runs. Click it again to cancel. Orange pulsing border = cancelling in progress.
Running ShellPilot with elevated privilegesIf you start ShellPilot as Administrator, the persistent runspace is already elevated — the red triangle (Open as Admin) becomes redundant in most cases since the green Execute button runs with the same privileges. Starting elevated is not required: for analysis, reports, and documentation workflows that do not need elevated access on the target systems, normal user mode is fine. For continuous interactive administrative work on local or remote systems, starting elevated gives the fluent experience because the runspace stays elevated across every Execute.
In-process runspace ShellPilot embeds a PowerShell engine directly into the application process. Scripts triggered by the green Execute button run inside ShellPilot.exe — no child process is spawned. The yellow and red triangle buttons take a different path: they launch a dedicated external PowerShell as a subprocess of the application. Two execution surfaces, deliberately separated, each chosen for what it does best.
Why we picked the embedded path for chat-driven execution Because the runspace lives inside the process, ShellPilot owns the I/O end to end. We control the formatting width and table layout independently of any console — tables render with every column visible up to our configured limit, never silently truncated to a console width. The captured output is the real, complete object output: select it directly out of the Output Window, paste it straight into your ITSM, project tool, or ticket — no Out-File detour, no Excel intermediary required (which on a hardened server you may not even have available). One of our design goals was that the output is immediately productive — no "run, write to file, open elsewhere, continue" cycle. We have tested the Output Window with over one million lines in a single run and have not yet hit our own ceiling; in practice the limit is the host's available memory and CPU, not anything ShellPilot imposes. Session state persists across executions: variables, imported modules, and authenticated sessions (Az, MgGraph, ExchangeOnline) remain live and addressable between scripts, which a fresh interactive console cannot offer without re-establishing them every time.
Where the external console wins — and what happens if a script lands in the wrong lane An in-process runspace deliberately has no console of its own, so a small set of cmdlets that require a real terminal or open their own GUI belong in an external PowerShell. In most cases a runspace-friendly equivalent exists (New-PSSession + Invoke-Command in place of Enter-PSSession, for example) and the AI selects it automatically. When the script genuinely needs a terminal, the yellow triangle opens it in PowerShell; the red triangle opens it elevated. Should a runspace-incompatible script reach the green button anyway, ShellPilot refuses to start it and reports "⚠ Script blocked for runspace execution" in the status bar — re-run with the yellow button.
PowerShell execution policy — what ShellPilot does and what it does not change ShellPilot sets the PowerShell execution policy to Bypass for its own session — both the embedded runspace and the external PowerShell launched by the yellow and red buttons. This is a per-session preference: it applies to the ShellPilot process and ends with it; the policy stored on the machine and on the user is not modified. Microsoft documents the execution policy plainly: "it's not a security boundary because it can't stop determined users from deliberately running scripts" (Microsoft Learn, about_Execution_Policies). It is a guardrail against unintentional script execution, not an enterprise control surface. A Group Policy that enforces Turn on Script Execution takes precedence over the external PowerShell path; the embedded runspace operates inside the ShellPilot process and is not subject to that GPO.
Endpoint security stays in effect — we do not bypass App Control, EDR, or AMSI We want to be explicit on this point because it matters for enterprise procurement: ShellPilot does not contain, ship, or enable any mechanism that circumvents endpoint security tooling. Whatever your environment already enforces against PowerShell continues to apply when you run it through ShellPilot — that is by design, not an oversight. AMSI is integrated at the PowerShell engine level and scans every script block regardless of which application hosts the engine. Microsoft documents this explicitly: "PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI" (Microsoft Learn, PowerShell security features). Script-block logging behaves the same way — events land in Microsoft-Windows-PowerShell/Operational for the embedded runspace just as they do for an external console. App Control for Business (formerly WDAC) and AppLocker are also enforced at the engine level: "PowerShell automatically runs in ConstrainedLanguage mode when it's running under a system application control policy" (Microsoft Learn, about_Language_Modes). That includes ShellPilot's embedded runspace. Behavior-based EDR products see ShellPilot.exe loading the PowerShell runtime and executing scripts, and are free to act on what they observe. Application Guard, Defender ASR rules, and comparable controls do what they were configured to do. The embedded runspace is a clean integration model, not an evasion path.
If the runspace ever does lock up — Reset Runspace, no app restart Edge cases happen. If the runspace ever stops responding, open Configuration → Settings. At the very top is a red Reset Runspace button. It uses the same deliberate click-pause-click pattern so you cannot trigger it by accident. The reset terminates any child processes the runspace spawned, releases the engine, and rebuilds it from scratch in a few seconds. Your chat, your subscription session, and the application itself stay alive — no app restart, no re-authentication. Treat it as the emergency stop you should rarely need, not as a routine action.
Persistent runspace = your environment livesTo reset only the AI context without losing your runspace: clear chat. Don't restart the app for that — restarting loses every login and variable you set up.
Output stays localScript output never leaves your machine unless you explicitly paste it back to the AI as context.
Output Window (Pro / Pro+)Open via View → Open Output Window for a wider results view with full scrollback. The Output Window always shows only the latest script run, kept clean by design, and can be moved to a second monitor. Output capacity has been tested well past 1.5 million lines in a single run; the practical limit is the available memory and CPU on the host, not anything ShellPilot imposes. Because the output is held in memory, keeping the Output Window open while the same output is still in the chat roughly doubles the working set for that data — a one-million-line run can occupy several hundred megabytes. Trial plan cannot open the Output Window.
Per-output Clear button — for managing memory on large outputsEach script output you no longer need can be cleared from its chat bubble with one click, and ShellPilot releases the memory immediately. Relevant scale: thousands of lines and up, where a single output can occupy hundreds of megabytes. For routine outputs of a few dozen to a few hundred lines, clearing makes no meaningful difference and you can ignore the button. Best practice for large outputs: once you have copied them somewhere — ticket, change record, file — clear them. A long chat session can otherwise accumulate gigabytes of script output that you are no longer using. The Clear button also matters for the HTML chat export: output bubbles you clear before exporting do not appear in the exported document, which is the clean way to keep personal data or other sensitive content out of a session record you intend to share. One thing the button does not do: it is workspace hygiene, not an AI-context reset. If an output was previously sent to the AI with Send to AI, it is part of the conversation history and stays in the AI context until you clear the chat or restart the application.

Activate Local LLM PRO / PRO+

Connect ShellPilot to a local OpenAI-compatible inference server so chat content never leaves your network.

ShellPilot - Settings 

Custom LLM (OpenAI-compatible)

Connect to any OpenAI-compatible endpoint. HTTPS is strongly recommended.

Use Custom LLM Endpoint

Base URL

Connected

Model

Local Context Limit

System Prompt (optional)

(default)

Settings saved.

ReadyCustom LLM

Available on Pro and Pro+. Starter does not include Local LLM. Trial includes it for evaluation.

Why local LLM

Air-gapped environments, regulated industries, internal data that must not leave the network.
Compliance: chat content stays inside your perimeter.
Business continuity: the client keeps working during cloud outages.

Intended deployment

Anything that exposes an OpenAI-compatible API works — from a single workstation up to dedicated GPU servers. ShellPilot does not care about the hardware. What matters is that the endpoint is reachable from the client and behaves like the OpenAI API.

Our testing focuses on serious local inference setups — the kind of model and hardware combinations shown above. Smaller or underpowered deployments can technically connect, but that is not what this feature is designed for. If your local setup is so slow that fluent interactive use is no longer realistic, we consider the local deployment unsuitable for ShellPilot rather than something to be worked around on the client.

Remote consulting on running ShellPilot against your local inference is available as a paid service — [email protected].

Endpoint requirements

OpenAI-compatible HTTP API. The exact route layout depends on your server — some require /v1/..., some accept the bare host. Configure the Base URL to match what your server actually exposes.
HTTPS is strongly recommended. Whether you run the endpoint over TLS is your decision; ShellPilot does not enforce it. If you do use HTTPS, omit the port for the standard 443.
Example URL format: https://llm.internal.example.com or https://llm.internal.example.com/v1, depending on your server.
Optional bearer-token authentication is supported for serving stacks that require it.

Model recommendation

We recommend models from 20B parameters upward, dense or MoE. Smaller models will not work reliably — ShellPilot ships a non-trivial system prompt (PowerShell conventions, response format, code-block structure, safety rules) and smaller models tend to ignore parts of it or break the expected output format.

System prompt

ShellPilot ships an internal system prompt that teaches the model PowerShell conventions, ShellPilot's expected response format, code-block structure, and safety rules. This is sent automatically on every Local-LLM request — you do not need to write one.

The System Prompt field in Settings is for additional, customer-specific instructions appended to the internal prompt — internal naming conventions, allowed cmdlets, environment-specific guardrails. Leave it empty for the default behaviour.

This field applies only to Local LLM. ShellPilot does not forward client-side system prompts to the managed Cloud API — that prompt is owned and maintained server-side.

Context limit

The context limit is how much chat history plus script context is sent to the local model on each request.
Set it to match what your serving stack actually supports under load — your inference team will know the practical limit for the deployed model (dense vs. MoE, KV-cache sizing, batching strategy).
128K enables long workflows: extended debugging sessions, large script context, multi-step troubleshooting with full history retained.
Lower values (32K / 64K) reduce per-request latency and free GPU memory for higher concurrency if multiple admins share the same cluster.

How ShellPilot manages context (important for Local LLM)

ShellPilot manages the context window on the client side: when the conversation reaches the configured limit, it trims the oldest messages and continues. For Local LLM the trim target is half of the configured limit, so the next few turns have room to grow before the next trim — fewer but larger trim events instead of constant micro-trimming.
Always configure the local server's context window at least as large as the limit set in ShellPilot. The client cuts only when its own limit is reached; if the server's window is smaller, the server will error out first and ShellPilot has no way to recover from that.
ShellPilot uses the actual token counts returned by the model in the response usage metadata — it does not estimate. This makes trimming precise as long as the model returns honest usage numbers.
When you toggle between Cloud and Local LLM, the same chat history is suddenly counted by a different tokenizer (Google's vs. your local model's). The two counts can disagree by a few percent. To absorb that, leave some headroom between ShellPilot's configured limit and the server's hard limit — a 10–15 % buffer is usually enough.

Stability

If the local model returns context-window errors, lower the configured limit first. Most local-LLM failures at runtime are context-related rather than model-related.

Licence check on Local LLM

ShellPilot validates your subscription even when inference runs locally. The hourly token refresh is the licence heartbeat. If the proxy is briefly unreachable, Local LLM continues to work for up to 24 hours since the last successful refresh — see the next section on mode switch for the detailed offline-grace behaviour.

Local LLM removes the dependency on Azure for the AI calls themselves, but not for application start: every fresh launch of ShellPilot still contacts the Azure proxy to verify activation before the main window opens. The 24-hour offline grace applies only to a session that is already running and temporarily loses connectivity.

Switch Between Cloud and Local

The toolbar holds three controls: Clear Chat, Theme toggle, and the AI-mode toggle. Both Clear Chat and the AI-mode toggle use the deliberate click → pause → click pattern (not a standard double-click) — this prevents accidental mode changes that could leak sensitive chat history to the cloud, and accidental loss of your chat.

Cloud AI active

Click, pause, click to switch

— chat / script editor —

Ready

The three toolbar buttons

Clear Chat — orange triangle pointing left. Click once, the triangle turns red and the status bar prompts you. Pause briefly, then click again within 3 seconds to wipe the chat. A standard double-click is ignored on purpose.
Theme toggle — single click switches between Light and Dark mode. No confirmation needed; no data risk attached.
AI Mode toggle — yellow triangle pointing up = Cloud active; blue triangle pointing down = Local active. Click, pause, click to switch — same 3-second window as Clear Chat.

How the click-pause-click pattern works

This is NOT a standard double-click. Click once — the button enters confirm state and the status bar shows a warning. Pause briefly. Click the same button a second time within 3 seconds to confirm.
If you don't click the second time within 3 seconds, the toggle silently resets — you can start over.
A real double-click (two clicks back-to-back, no pause) is treated as a single click and will not switch.

Read the footer warning when switching

When you switch from Local to Cloud, the entire current chat history is sent to the cloud on your next message — including any output you previously fed back from local inference.
If sensitive data is in your chat history, clear chat first before switching to Cloud.

Why "clear chat" and not "restart"

Clearing the chat empties the AI context — your conversation starts fresh.
Your PowerShell runspace stays alive: variables, imported modules, Azure / AD / Graph connections all persist.
If you restart the client you lose the runspace and have to reconnect everything.
Rule: clear chat to reset the AI's memory; never restart to reset the AI's memory.

24-hour offline grace (Local LLM)

Local LLM works without internet, but ShellPilot still validates your subscription hourly when online.
Each successful hourly token refresh resets the 24-hour offline grace window.
If internet is temporarily out, you can keep working locally for up to 24 hours since the last successful proxy contact.
During those 24 hours, ShellPilot keeps retrying in the background — when internet comes back even briefly, your grace window resets.
After 24 hours offline with no successful refresh, ShellPilot blocks AI requests until you reconnect briefly.
Net effect: short internet outages have zero impact on Local LLM usage.

Credentials & Sensitive Inputs

ShellPilot detects when the runspace asks for a credential and switches the input bar into a protected mode — credentials never enter the chat or reach the AI.

Administrator: ShellPilot −□×

ConfigurationViewHelp

12:00:00 ( AI )

The script below will prompt for credentials when it runs.

Script 1 (powershell)

$cred = Get-Credential

⬇ ⎘

Ask anything...

Ready

The input bar changes color — that is the signal Orange border — Script input mode. Text is hidden from logs and the AI but is not stored as a SecureString. Used for Read-Host and the username step of Get-Credential.
Pink border — Secure input mode. Whatever you type is stored as a SecureString in protected memory, never logged, never sent to the AI. Used for Read-Host -AsSecureString and the password step of Get-Credential.
Get-Credential runs in two steps inside the chat inputFirst the input bar turns orange and asks for the username. After you confirm, it turns pink and asks for the password. Both stages live in the input bar — no separate Windows dialog is opened, the custom PSHost handles the prompt itself.
Credentials follow the secure input pathCredentials entered in response to Get-Credential or Read-Host -AsSecureString never enter the chat, are not logged, and are handed to PowerShell through the secure input path as a SecureString. There is no path in the code that would attach them to a chat message or transmit them to the AI.
Browser-based logins (Connect-AzAccount, Connect-MgGraph)Those modules open a browser window for OAuth. The browser flow happens between you, Microsoft, and the local PowerShell module — ShellPilot does not see or store the access token.
Never type a password as a normal chat messageAlways wait for the pink border before entering a credential. When the runspace prompts for a credential, ShellPilot triggers the secure input automatically. If a local LLM ever asks you to paste a password directly into the chat (System Prompt not followed correctly — we cannot guarantee what a customer-deployed model does): do not do it. Cancel and re-prompt.

UI Essentials & Tips

Small details that make a big difference. Most issues users report turn out to be things the UI already tells them — usually in the status bar.

Administrator: ShellPilot −□×

ConfigurationViewHelp

12:00:00 ( User )

list running services that start with M

12:00:01 ( AI )

Service Filter

Here is a one-liner that filters running services by name prefix.

Script 1 (powershell)

Get-Service | Where-Object { $_.Status -eq 'Running' -and $_.Name -like 'M*' }

⬇ ⎘

Ask anything...

Ready

Save / Copy — disabled on Trial

Four ways to run the script

Ask in any language — reply matches

Read warnings here — mode-switch & budget

Light / Dark toggle

Watch the status bar at the bottomMode-switch warnings appear there with a yellow background. Budget warnings ("90% of monthly budget used"), token-refresh status, and subscription expiry warnings surface there too. Read it.
Clear chat = click, pause, clickNot a double-click. Click once, the button turns red and the status bar prompts you. Pause briefly, then click again within 3 seconds. A standard double-click is ignored on purpose so you cannot wipe the chat by accident.
Clear chat resets the AI context, not your runspaceYour variables, imported modules, and login sessions stay alive. Use Clear Chat to reset the AI's memory without losing the work you have set up.
Export chat as HTMLConfiguration → Export Chat as HTML saves the conversation with syntax-highlighted code blocks for documentation. There is no chat re-import by design — runspace state cannot be replayed, so importing would mislead. Export is for documentation only.
The submit triangle changes color with the modeGreen triangle: normal chat — message goes to the AI. Yellow triangle: script-input mode — your text is treated as PowerShell and injected into the runspace. Pink border: secure input mode — content is never logged and never sent to the AI (used for credentials).
Trial plan UI restrictionsCannot copy script content (button disabled). Cannot save script as a .ps1 file. Cannot open the Output Window. These are upgrade triggers — see the plans page.
Local AI footer warning persists until clearedAfter switching from Local to Cloud, the footer reminds you that any further chat will send the history to the cloud. The warning stays until you clear chat or send a new Cloud message.
Light / Dark modeToggle via the half-yellow / half-dark circle in the top-right of the menubar. The choice persists between sessions.
Custom system prompt (Local LLM)Optional. Most users skip this. Set it only if your local model needs specific instructions you have validated. The default (empty) works for most OpenAI-compatible servers.