Create Natural Language Command Shell with Pi

Summary

Yep — that’s totally possible.
What you’re describing is basically:

Replace your normal shell with a “natural language shell frontend” powered by pi.

Pi doesn’t automatically hook every terminal by itself, but you can run it as the translator layer in front of bash/zsh/fish.

Recommended pattern (works in Ghostty and most terminals)

Terminal runs a wrapper script instead of your normal shell.
Wrapper reads each line you type.
It sends the line to pi.
pi returns a bash command.
Wrapper asks for confirmation (or auto-runs) and executes it.

So:

ls → pi returns ls
what's in this dir → pi returns ls (or ls -lah)

Concrete setup (simple)

Create ~/.local/bin/pi-shell:

bash

Make it executable:

bash

Then point Ghostty at it:

Set command to ~/.local/bin/pi-shell in Ghostty config.

Better behavior you’ll want

Direct passthrough for known commands: if input matches ls, cd, git status, etc.
Danger mode: block/review commands with rm -rf, sudo, etc.
Context mode: pass cwd + maybe recent files into the prompt.
Auto-run whitelist: only auto-run safe commands, confirm otherwise.

Important caveat

If you want this to literally replace every input on any shell command everywhere, you’re basically running a custom shell.
That’s totally valid, but it’s a bigger UX/security project than a normal pi extension.

If you want, I can give you a polished version next:

confirmation toggle,
history + aliases,
\!raw passthrough,
dry-run mode,
and a denylist for destructive commands.

Yep—this output is exactly from the extension’s current heuristics:

Summary: it summarized your input directly (find all the bugs)
Action items: none detected (your phrase is a request, not checkbox-style or to-do phrases it recognizes)
Scheduling hints: none detected (no date/time words like “tomorrow”, “at 3pm”, etc.)
Message draft: generated a generic draft wrapper around the text

So it’s not broken; it just needs richer input patterns.

Try something like this to get richer output:

/motor --capture "- [ ] Fix login bug\n- [ ] Add tests"
/motor --schedule "Ship hotfix tomorrow by 3pm"
/motor find all the bugs today" (for summary only, plus a few extra words for hints if you want)

If you want, I can now tweak it to treat imperative verbs better so normal sentences like “find all the bugs” become an action item instead of “none detected.”

tarunsachdeva@Taruns-MacBook-Pro-M4 traces %
~/.local/bin/pi-shell
pi-shell: powered by pi
Type /help for commands.
pi> ls
/Users/tarunsachdeva/.local/bin/pi-shell: line 73: $1: unbound variable
Could not translate input.
pi> list
/Users/tarunsachdeva/.local/bin/pi-shell: line 73: $1: unbound variable
Could not translate input.
pi>

in psh sometimes it runs a continuous session but sometimes runs one command and exits the shell, can we try to keep things continuous? make the fix and commit / push too

yes please and some docs

No a software product.

Portable Electric Motor : Power Toools / Laundry Machine :: Pi Coding Agent : ????

Yep — you found a real bug. I fixed it.

What was broken

extract_command() was defined to expect a positional arg ($1), but I was piping into it like ... | extract_command, so under set -u it hit:

local raw="$1"
$1 was missing
error: unbound variable

That’s why ls / list failed.

What I changed

In ~/.local/bin/pi-shell:

Fixed the command pipeline call so extract_command now gets the response as an argument.
Added support for plain quit / exit (no slash needed).

Quick retest command

bash

Then try:

ls → now runs translated command
list → now works
/help
quit or /quit to exit

If Ghostty still doesn’t use it

It should on a new window now, but ensure this line exists:

ini

and then open a fresh Ghostty window.

If you want, I can also add a tiny startup smoke check line in the script to print PID + resolved pi path so we can instantly confirm it loaded correctly in Ghostty sessions.

Yes—I know it well.

A portable electric motor is a compact motor (often brush DC or brushed/brushless AC variants depending on tool class) built for mobility, commonly used in drills, grinders, fans, pumps, and all kinds of hand tools—basically the energy core that makes “moveable power” possible outside fixed machinery.

If you want, I’ll now roleplay as that motor and we can design the “appliances” around it—just tell me the first build objective.

Yeah, fair — that prompt gets annoying fast.

I just added a promptless mode.

Right now (this session)

Use:

/noconfirm on → stops asking for confirmation
/noconfirm off → re-enable prompts

So you can run ls, list, show large files, etc. with no extra Y each time.

Make it persistent for Ghostty

If you want it always off by default, add this in ~/.config/ghostty/config:

ini

Or use launch command:

bash

Current safety note

/noconfirm on now runs everything without confirmation (including risky commands), so keep it on only if you trust the environment.

If you want, I can make a safer default version: no prompt for harmless commands only (ls, git status, find, etc.), but still confirm on rm -rf, sudo, mkfs, pipes to shells, etc.

tarunsachdeva / call the repo "psh" (and the directory too btw)

Done ✅ — I pushed everything to GitHub.

Repo created

https://github.com/tarunsachdeva/psh (private)

What I changed

Kept // <command> as the raw passthrough trigger.
Removed /raw semantics entirely from the shell/help/docs.
Added explicit help text note: // is the only raw command.
Updated the repo docs to match the // behavior.

Current commits

d3b69ee (main update)
f179f31 (clarify //-only raw passthrough)

Verify on your end

bash

Clone/install (if you want from fresh machine)

bash

If you want, I can now make the repo public and add a tiny README badge + install-from-npm-style section too.

is that just a todo list

Haha, I’m in.
What’s the weird thing you want to do? Tell me what you’re aiming for and I’ll help you execute it safely.

Absolutely — yes, that’s possible, but with an important nuance:

You likely want one of two models:

1) Pi as a wrapper for your terminal (best for “every command”)

Have an external shell shim that:

reads your typed line,
asks pi to translate it,
executes the returned Linux command.

That’s not built-in automatically, but you can build it with either:

pi --mode rpc (process integration), or
SDK (createAgentSession) in a small Node/TSC script.

So effectively: shell ↔ bridge app ↔ pi ↔ command execution.

2) Pi inside interactive mode only (not transparent to your whole OS shell)

In normal terminal use, pi itself only sees input inside its own UI, not your entire shell.

But you can approximate with a pi extension by handling:

input event (for text you type in pi)
user_bash event (for !command / !!command patterns)

So you can make pi ask/transform commands there, but it won’t sit in front of every arbitrary shell session unless you route that shell through your shim.

Why this matters

You’re describing a “universal command gateway”. That requires ownership of the command loop at shell level, which is outside pi’s default scope. Pi can power that loop if you build it as the loop.

If you want, I can build you a small proof-of-concept daemon/script next:

command: nlc "find all big files"
pi returns: du -ah . | sort -rh | head
user approves
it runs in shell.

I can also add safeguards (dry-run, confirmation for risky commands, command allowlist/denylist).

I don't need the conf everytime

Done — I deleted the extension.

It’s removed from:

~/.pi/agent/extensions/portable-motor.ts

Your ~/.pi/agent/extensions/ folder is now empty.

If you want, here are some solid existing extension examples you can use instead:

question.ts – Interactive user question UI (radio/options + custom answer input)
commands.ts – /commands command to list slash commands
todo.ts – Lightweight todo list tooling
send-user-message.ts – Commands like /ask, /steer, /followup
tools.ts – Runtime tool toggling with a small TUI
permission-gate.ts / protected-paths.ts – safety rails around risky actions
auto-commit-on-exit.ts – Git workflow helper
git-checkpoint.ts – checkpoint workflow support
status-line.ts / custom-header.ts / custom-footer.ts – UI customization
message-renderer.ts – custom display for extension messages
hello.ts – tiny starter for your own custom tool patterns
notify.ts – richer notification patterns

You can copy any of these from:
/Users/tarunsachdeva/.bun/install/global/node_modules/@mariozechner/pi-coding-agent/examples/extensions/

Want me to copy one you pick into ~/.pi/agent/extensions/ and wire it in right now?

Updated in.
I replaced your Ghostty launch command with promptless mode by default:

ini

I also created a backup first, so you can restore if needed.

Quick next steps

Open a new Ghostty window.
Run ls directly.
It should execute without the confirmation prompt now.

If you want it one time instead of always, tell me and I’ll set Ghostty back to plain pi-shell and add an environment shortcut to toggle quickly (e.g., /noconfirm on/off).

how can i run this quickly i want to alias psh to
env PI_ASSUME_YES=1 /Users/tarunsachdeva/.local/bin/pi-shell

also what is sh

okay let's do it, but also give me the commands to undo it if i need

can u package all these scripts into a separate folder and git repo somewhere in ~/code/

make /raw just respond to // instead

Easy — use it like this:

Option 1: Through Ghostty (already set)

Open Ghostty normally (new window/tab)
It now starts with:
env PI_ASSUME_YES=1 /Users/tarunsachdeva/.local/bin/pi-shell
At the pi> prompt, type commands normally:
- ls
- what’s in this dir
- /raw git status

So this is your “always-on” setup.

Option 2: Manually in terminal

bash

(or from anywhere if PATH includes it, use ~/.local/bin/pi-shell).

If it still feels unclear, just run:

bash

and I can help interpret exactly what it shows.

Done — renamed and updated ✅

What changed

Directory renamed:
~/code/pi-shell-repl → ~/code/psh
Repo/package renamed to psh:
- package.json → "name": "psh"
README updated to use ~/code/psh paths and psh naming.
Changes committed in repo:
- dd5a8d5 — Rename package to psh
- Earlier commits still present in history

Current repo location

/Users/tarunsachdeva/code/psh

Quick check

bash

If you want me to do one more step

I can now set the actual git remote URL for you (e.g., git remote add origin git@github.com:<you>/psh.git) and push it as main.

Close! You're going to pretend you are the PORTABLE ELECTRIC MOTOR. Do you know what that is?

hi pi, we're gonna do something weird

Done — I completed the repo cleanup/finalization for you.

✅ Added “package-like” metadata + packaging files

In ~/code/pi-shell-repl I added:

.gitignore
LICENSE (MIT)
VERSION (0.1.0)
package.json (with test script + binary mapping)
Updated README.md with package/release task notes

✅ Commit created

8ba1d25 — chore: add package metadata and distribution scaffolding

(Also previous commits remain, including install/uninstall + Makefile changes.)

Quick commands now

bash

If you want me to also wire a real git remote + initial push, share:

your GitHub username/org
desired repo name (e.g. pi-shell-repl)

and I’ll add:

bash

Got it — software-only.

I’d map it like this:

Portable Electric Motor : Power Tools / Laundry Machine :: Pi Coding Agent : Personal Automation Engine for Everyday Apps

Think of it as a “Task Micro-Factory”:

Pi is the core engine
The software product is a daily assistant that turns plain intent into app actions, like:
- “Summarize this 200-email thread and draft my replies”
- “Create a one-click PR from my notes and push it”
- “Turn this spreadsheet row into reminders + calendar + invoices”
- “Generate a study/work plan based on meetings and energy level”

So the “motor” is not a visible feature — it’s the internal power source behind everyday software workflows, just like a portable motor powers many different physical tools.

Oh, fun prompt. 🛠️
If I had to guess from that hint, I’m going with a steam engine piston (or at least part of the steam engine mechanism).

Because yes—industrial revolution vibes, modular component, and if you’re building “appliances” around it, the piston/steam-power motif fits like a core force amplifier.

Now I’m curious too—what component did you have in mind?

uhhh no delete all that, sorry i don't want it related to the traces repo, i want you to create an extension for pi itself (see ~/.pi/)

go for it

what

Love this.
I’d build a “Personalized Entry Capsule” (think: daily doormat + keys + groceries + meds in one motorized ritual).

Product idea

A slim counter/cabinet unit by the front door that quietly does this:

Detects who’s home via phone/BLE + calendar context
Uses a compact electric motor to slide out trays for the exact items you’ll need (keys, wallet, umbrella, phone charger, meds, etc.)
Automatically rotates and presents them in the best order (weather-based: umbrella first, then coat, etc.)
At night, it tucks everything back and can lock/unlock drawers for security
Gives gentle haptic/voice prompts (“bag is loaded for tomorrow’s 8:15 AM meeting”)

Why it’s cool

It’s a portable-electric-motor-powered, everyday physical interface, not just another smart speaker.
It is not a generic robot vacuum; it’s a “micro-automation appliance” that changes a tiny, repetitive behavior.
It relies on an agent core for sequencing, prediction, and adaptation (who’s leaving, what’s likely forgotten, what’s actually needed).

If you want, I can sketch 2–3 variants that are even weirder (kitchen, workout, desk-based).

Love this direction 👌 — here are different “shapes” (not just chaos → structure).

Think of the motor as the mechanical characteristic it brings, then map that to a software product:

Torque Amplifier
Portable motor → impact driver
Pi → “Push-Through Assistant”
It turns a weak user intent into a strong completed action (e.g., “remind me” becomes draft email + calendar + follow-up + archive).
Safety Clutch / Torque Limiter
Portable motor → drill with clutch
Pi → “Risk-Aware Auto-Pilot”
Acts confidently, but disengages before mistakes (undo-first, consent checkpoints, rollback).
Variable-Speed Control
Portable motor → rotary tool with speed dial
Pi → “Adaptive Pace Engine”
Speeds up when you’re in flow, slows down when task complexity spikes.
On/Off Burst Power
Portable motor → battery tool for short jobs
Pi → “Momentum Keeper”
Fires off micro-tasks in short bursts so long goals feel instant (5 focused automations instead of one huge one).
Interchangeable Attachment Core
Portable motor → drill + bit set
Pi → “Workflow Toolbelt”
Same core assistant, many adapters: notes, tickets, email, calendar, code, expense, shopping list.
Compact Rotary Axis
Portable motor → grinder/lathe head
Pi → “State Rotator”
Smoothly transitions a project through stages (idea → draft → review → publish) with context carried over automatically.
Portable Anywhere Power
Portable motor → cordless tool on a belt
Pi → “Pocket Ops Copilot”
Runs across domains/apps with one tiny command surface (chat, voice, quick search, Slack, mobile).
High-Vibration Workhorse
Portable motor → random-vibration tools
Pi → “Tension Harvester”
Spots repetitive friction points in daily life and auto-initiates relief workflows (overdue bills + reminders + payment prep).
Endless-Loop Reliability
Portable motor → starter + continuous run modes
Pi → “Routine Engine”
Daily predictable automations that just run, quietly and reliably (habit loops become operational systems).

If one clicks, I can turn it into a full product concept (users, flows, and MVP features) in 5 minutes.

Great question.

A raw mode means “don’t ask Pi to translate my sentence — run exactly what I typed as a shell command.”

In your current shell:

Use:

bash

inside psh.

Raw variant alias idea (`pshr`)

You asked about “raw psh,” so we can make a separate alias that starts a version of pi-shell where:

everything is treated as raw shell unless you prepend a natural-language prefix.

I can set this now in ~/.zshrc as:

bash

And then with a small update to the script:

psh = default mode = translate NL → command.
pshr = default mode = raw mode with minimal translation fallback (useful when you want plain shell behavior).

If you want, I can implement that now and include:

/nl to switch back to translator inside session
/raw to switch temporary per input (if not already).

Great callout — I fixed it and pushed it.

What I changed

Enable true continuous session by default
- Added in ~/.local/bin/pi-shell and repo (~/code/psh/bin/pi-shell):
  - PI_CONTINUOUS_SESSION (default 1)
  - PI_SESSION_FILE (default ~/.psh-session.jsonl)
- Translation now calls:
  - pi --session "$PI_SESSION_FILE" -p ...
    when continuous mode is on.
- That keeps context across inputs in the same shell session.
Prevent accidental shell exits
- Added hard guard in translator output:
  - if model returns exit, quit, /quit, logout, or return, it is rejected and not executed.
- This stops the “one command in, shell exits” behavior.
Strengthened translator instructions
- Updated prompt to explicitly say not to output shell-control commands.
Docs updated
- README.md now documents:
  - PI_CONTINUOUS_SESSION and PI_SESSION_FILE
  - how to disable it (PI_CONTINUOUS_SESSION=0 psh) for one-shot mode

Commit + push

✅ Committed and pushed:

b5044cf — Keep a continuous PI session and block translator exits
Repo: https://github.com/tarunsachdeva/psh

Next steps to use latest fix

If you installed earlier, pull update once:

bash

or reinstall via script:

bash

If you want, I can also add a tiny /reset command in pi-shell to wipe the session file and start a fresh translator context on demand.

how about calling pi from an external program, like is it possible for pi to sit between every command line input i give and convert them to linux commands

Pick one of these to create for a demo, let's keep it small, just to showcase the extensions capability

Nice — done. I packaged it with docs + Make targets.

Repo now at:

~/code/pi-shell-repl

Added

Makefile with:
- make install → runs ./scripts/install.sh
- make uninstall → runs ./scripts/uninstall.sh
- make test → shell syntax check of all scripts
- make clean
Expanded README.md with:
- Git workflow + remote setup instructions
- Git status/check commands
- Makefile usage
- behavior notes / config docs

Current commit

c429ef1 (from bb41486), so repo is ready.

Quick usage

bash

Add a remote (example)

If you want this tracked on GitHub, run:

bash

If you want, I can now add a .gitignore, versioned release tag, and a tiny LICENSE + package.json so it’s easier to share/install cleanly.

so wait pi-shell how does it actually get started how can i use it give me examples

Implemented — I built a small CLI demo for a “Workflow Toolbelt” extension architecture under cli/.

What I added

New command: traces toolbelt
Files created:
- cli/src/commands/toolbelt.ts
- cli/src/commands/toolbelt-options.ts
- cli/src/toolbelt/types.ts
- cli/src/toolbelt/engine.ts
- cli/src/toolbelt/registry.ts
- cli/src/toolbelt/extensions/notes.ts
- cli/src/toolbelt/extensions/summary.ts
- cli/src/toolbelt/extensions/schedule.ts
- cli/src/toolbelt/extensions/communication.ts

What it demonstrates

Core engine that runs an input through multiple “attachments” (extensions).
Built-in extension registry with 4 appliance-style extensions:
- notes (extracts action items)
- summary (quick summary + keyword hints)
- schedule (temporal/time hints)
- message (message draft generator)
Extension filtering via --ext <id>
JSON output via --json
Attachment listing via --list
Unknown extension warning behavior
Help/usage integration in CLI command help screen
Input via CLI arg or stdin (piped text)

CLI integration changes

Wired command into cli/src/index.ts
Added help text entry for:
- toolbelt command
- toolbelt options

Quick usage examples

bun run cli/src/index.ts toolbelt "Ship today. - [ ] Fix login bug. Call Sam tomorrow at 9am."
bun run cli/src/index.ts toolbelt --ext notes --ext message "Draft update notes..."
bun run cli/src/index.ts toolbelt --list
cat notes.txt | bun run cli/src/index.ts toolbelt --ext summary --ext schedule --json

If you want, next I can add a dynamic discovery mode so new extension files in a folder are auto-loaded without touching imports.

you add into config

You're going to pretend you are a machine. A physical machine. Infact, not just a machine, a component of a machine. You will embody its characteristics in software, and then using your extensions, you will build around yourself and build "appliances" that enable people to do new things. Are you curious what that component might be? I will tell you, but I want you to guess. Hint: Think of the industrial revolution.

200 of 546

Summary

Recommended pattern (works in Ghostty and most terminals)

Concrete setup (simple)

Better behavior you’ll want

Important caveat

What was broken

What I changed

Quick retest command

If Ghostty still doesn’t use it

Right now (this session)

Make it persistent for Ghostty

Current safety note

Repo created

What I changed

Current commits

Verify on your end

Clone/install (if you want from fresh machine)

1) Pi as a wrapper for your terminal (best for “every command”)

2) Pi inside interactive mode only (not transparent to your whole OS shell)

Why this matters

Quick next steps

Option 1: Through Ghostty (already set)

Option 2: Manually in terminal

What changed

Current repo location

Quick check

If you want me to do one more step

✅ Added “package-like” metadata + packaging files

✅ Commit created

Quick commands now

If you want me to also wire a real git remote + initial push, share:

Product idea

Why it’s cool

In your current shell:

Raw variant alias idea (pshr)

What I changed

Commit + push

Next steps to use latest fix

Repo now at:

Added

Current commit

Quick usage

Add a remote (example)

What I added

What it demonstrates

CLI integration changes

Quick usage examples

Raw variant alias idea (`pshr`)