Xonsh: a Python-powered shell where shell commands and Python share one prompt

What xonsh is and who switches to it

Xonsh, pronounced like consh, is a shell whose language is a superset of Python 3 with shell commands built in. The README says it runs on Linux, macOS, Windows, BSD, Jupyter, Android, Raspberry Pi and Nix. In practice that means one prompt accepts cd $HOME and cat /etc/passwd | grep root, and on the next line accepts a list comprehension or a JSON parse, without switching programs.

The people who get the most from it are those who already reach for Python the moment a shell pipeline gets awkward: data engineers, people automating infrastructure, researchers who live in notebooks. The repository topics list data engineering, DevOps and security automation, which fits. If your shell use is mostly running a handful of commands and your scripts are written for sh, xonsh changes a lot for little gain.

How shell mode and Python mode share one language

The README's examples show the two directions the language works in. Shell values are Python objects: $PATH is a list you can append to, and $() captures a command's output as a string you can pass to len. Python values go into commands through @(), so a variable becomes an argument or part of a file name:

$PATH.append('/tmp')
len($(curl -L https://xon.sh))
name = 'snail'
echo @(name) > /tmp/@(name)

There is a path literal as well. The README shows p'/etc/passwd' used as a path object with read_text, and p'/tmp/dir' being created and entered inside a with block. This is where xonsh differs from calling Python from a normal shell: there is no string quoting round trip between the two worlds, and a command's output can go straight into a data structure. The same mechanism powers the README's example of turning podman output into JSON and indexing it by key in one expression.

Getting xonsh onto a machine

The README keeps installation on the project site. Its first steps link an installation guide covering an isolated environment, a package, a container or a portable AppImage, and a step by step tutorial. The badges add Docker Hub images and an AppImage page, and the repository has a flake.nix for Nix users.

The packaging files fill in the constraints. pyproject.toml publishes a project named xonsh, requires Python 3.11 or newer, and declares an empty dependency list, so the shell itself pulls nothing else in. The setup.py builds the lexer and parser tables during installation, which is why a source install does a little more work than an ordinary pure Python package. An isolated environment is the sensible default the installation guide points to: the shell you log into should not break because a project upgraded a library in your system Python.

Aliases, events and xontribs

Customization is ordinary Python. Aliases are entries in a dictionary, and an alias can be a string or a function:

aliases['e'] = 'echo @(2+2)'
aliases['a'] = lambda args: print(args)
aliases['ai'] = 'ollama run llama3'

Events hook into the shell's life cycle. The README's example registers a handler that runs after each command and, when the command failed, puts it back in the prompt so it can be fixed and rerun:

@events.on_postcommand
def _prompt_err_cmd(cmd, rtn, out, ts):
    if rtn != 0:
        $XONSH_PROMPT_NEXT_CMD = cmd.rstrip()

Plugins are called xontribs. The README loads several at once, including terminal integration, a Starship prompt and a powerline theme:

xontrib load term_integration \
             prompt_starship  \
             powerline

The README links an awesome-xontribs list, the core xontribs documentation and a template for writing your own. Because a xontrib is Python running inside your shell, a slow or broken one shows up as a slow or broken prompt, which is the reason to add them one at a time.

Where xonsh is the wrong choice

The README describes a superset of Python 3, not a POSIX shell, and it does not claim compatibility with sh or bash scripts. That is the main limit. Existing shell scripts, installers that expect sh semantics and instructions written for bash are not what xonsh was built to run, so most people keep their old shell installed alongside it.

The README's answer to that gap is the meta-shell idea. Its examples load an sh xontrib and a fish completer, call osqueryi and nu from inside xonsh, and feed nushell's JSON output into a pandas DataFrame. That works, but each bridge is another dependency, and a colleague reading your aliases has to know Python and the shell you are bridging to.

The licensing is slightly muddled on the GitHub page: GitHub reports NOASSERTION, while pyproject.toml declares the BSD 2-Clause License. Anyone redistributing xonsh should read the LICENSE file itself.

Releases, maintenance and the ecosystem around it

The recent release history is regular: 0.24.0 on 2026-07-02, 0.24.1 on 2026-07-31 and 0.24.2 on 2026-08-23, and the last push to the repository was on 2026-09-14. The repository also carries an AI_POLICY.md and a CLAUDE.md, and its topics include Claude and Claude Code, which matches the description's claim of being AI-friendly.

The README lists projects that use xonsh or support it: conda and mamba, the Starship prompt, zoxide, xxh for taking xonsh over SSH, Snakemake, rever and several Nix tools, plus a Jupyter kernel through xontrib-jupyter. For a shell that is a meaningful signal of reach, because each of those projects had to write and keep xonsh support. Upgrading is still worth doing deliberately: a shell sits under everything else you run, and a change to the parser or to a xontrib's behaviour affects every terminal you open.

Editorial conclusion

Try xonsh if you already think in Python and move between scripts and a terminal all day. Install it into an isolated environment as the installation page suggests, keep your old shell for existing sh scripts, and load xontribs one at a time so a plugin that breaks your prompt is easy to find.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. xonsh/xonsh on GitHub