From
TruFoundation
Subject
TruShell, a shell written in Rust
Status
alpha
Source
github.com/TruFoundation/TruShell
Updated
September 2026

TruShell

A shell, written in Rust. It is alpha. It is not finished, it is not a bash replacement, and you should not trust it with anything you can't afford to lose.

We're building it because we think a shell can be safer by default than the ones we all use, and the only way to find out whether that's true is to write one and see. This page says what exists, what doesn't, and what we're still arguing about. Feedback is welcome, especially the unflattering kind.

Get the source Read the known issues 
trushell> let name = "Alice"
trushell> let age = 30
trushell> let next_year = $age + 1
trushell> echo "Hello, $name! Next year you'll be $next_year."
trushell> cat server.log | grep "ERROR" > errors.txt
trushell>

Status, plainly

  • Alpha. Things break, and behaviour changes between commits without notice.
  • Don't set it as your login shell.
  • Don't run scripts you don't trust under it and assume it protects you. WASM plugins run inside a capability sandbox. The commands you type do not. They run with your full privileges, as in any other shell.
  • Nobody outside the project has done a security review.
  • We haven't measured performance. Rust rules out a class of memory bugs. It doesn't make a design safe or fast, and we won't claim either until we have numbers or a review.
  • Linux is what we build and test on. macOS may work, may not. Windows: no.

What works today

As far as we know. This list is only as good as our testing, and we haven't re-checked every line.

  • An interactive prompt that runs ordinary Unix commands (ls, cat, grep) through your PATH.
  • Pipes and redirects, including &>.
  • Job control and signal handling. Merged recently, so young.
  • Variables, integer arithmetic, comparisons, and { ... } blocks that return their last value.
  • Numbers with units: 1mb, 500ms.
  • A PTY layer with a Linux backend, and a terminal emulator core. Both are new.
  • A WASM plugin host with a capability model. A plugin declares what it needs in a JSON manifest, and one that imports an undeclared host function fails to load.
  • A dotfile importer and a compatibility linter.
  • A POSIX compatibility spec with acceptance tests. It covers a small set of behaviours, not POSIX as a whole.
  • Linux packages (.deb and .rpm) and release binaries built by CI.

What doesn't work yet

  • The docs don't describe if, for, while or functions, or how variable scope works. If they exist, the docs are wrong. If they don't, that's the biggest gap between us and a shell you can write scripts in.
  • Our goal is that scripts written for /bin/sh run, with a fallback when they don't. We are nowhere near "run any sh script", and bash-only features are a separate, larger problem.
  • The commands you run are not sandboxed. Only plugins are.
  • We're not sure how complete tab completion and history are.

Something we know is wrong. If a line doesn't parse as a TruShell expression, we hand it to the system as an external command. A typo can turn into a PATH lookup, what a line means depends on what happens to be installed, and this is exactly where injection bugs live. We plan to remove it or make it explicit. It will break some things. That's fine, this is alpha.

The full list of known problems is in trushell-issues.md. If you find something that isn't on it, that's a bug in the list.

Try it

You need Rust 1.70 or newer.

git clone https://github.com/TruFoundation/TruShell.git
cd TruShell
cargo build --release
./target/release/trushell

While hacking, cargo run is quicker, and cargo test runs the tests. Release binaries and Linux packages are on the Releases page. Treat them as lightly tested.

Where it came from

TruShell began as a Python program, a "productivity shell" with todos, jokes, world clocks and a CSV viewer. Version 2 replaced the engine with Rust. In July and August 2026 we ran a sprint to turn it into what it is trying to be now: a Linux- and POSIX-compatible shell with a terminal core and sandboxed WASM extensions.

That history is why odd leftovers are still lying around. We know. They're on the cleanup list.

Where it's heading

The goals we set for the last sprint:

  • Scripts that work with /bin/sh should work here too, with a fallback when they don't.
  • Processes handled correctly: job control, signals, pipelines.
  • A small, fast core. Optional features load only when needed.
  • Safe by default: extensions run in a sandbox that limits what they can do.

Ideas we'd like to try after that. None are built, and some may turn out worse than they sound:

  • Extending the permission model from plugins to the commands you run, with a way to preview destructive actions and a record of who ran what.
  • Data with types: lists and records through a pipeline, not guesses at columns in text.
  • A plain JSON interface for automated agents, which today scrape terminals built for humans.
  • Running old bash scripts inside a sandbox so nobody has to rewrite them to try this.

What we're not doing: bug-for-bug bash compatibility, and Windows support for now.

Help wanted

There's plenty to do, and most of it isn't glamorous.

  • Read the known issues, pick one, and say so in the issue so two people don't do the same work.
  • Try it, break it, and tell us how. A minimal reproducer with the commit you built from and your OS is worth more than a long essay.
  • Tell us what you think of the design. What would stop you from ever using a shell like this?
  • Review code. Very few people outside the project have looked at it.

Bigger design questions get discussed before they get written. Please don't send a 2000-line patch for something we haven't talked about. It isn't a rule to annoy you. It's so we don't waste your weekend.

Start with CONTRIBUTING.md. Found a security problem? Don't file a public issue. Read SECURITY.md.