Luish: A vibe-coded shell that is better than bash or zsh A developer known as Luispedro built luish, a shell written in roughly 50,000 lines of Rust, by directing Claude through millions of tokens and 301 commits to reimplement zsh. Luish v0.6.0 runs existing bash scripts, matches zsh and dash output across hundreds of test scripts, and is measurably faster for interactive use, with features like autosuggestions, TOML configuration, GitHub-integrated plugins, and an SSH client/server mode. The author says Claude also surfaced a crash bug in bash involving self-referential expansion. A few weeks ago, I was trying to speed up zsh’s startup. After a bit of frustration, I had a thought that would have been ridiculous until recently any time before February : I should just ask Claude to reimplement zsh in Rust. A few million tokens, 301 commits, and about 50,000 lines of Rust later, luish v0.6.0 https://luish.readthedocs.io/ is here. I want to make a few points about it. Luish is good and you should try it It’s already a good shell. It runs all the bash scripts that I have encountered so far. Every time I hit a failure, I ask Claude to add the missing functionality. By the time we reach 1.0, we’ll have parity. 1 footnote-1 And it’s much faster https://luish.readthedocs.io/en/latest/performance.html . I am actually surprised at how much difference it makes to have it be just a few tens of milliseconds more responsive for interactive use. I don’t feel that zsh is slow, but I feel that luish is faster . It borrows a lot of what makes zsh good for interactive use: autosuggestions, better completions, advanced globbing, vared , ${file:t} and the other modifiers, … It can automatically detect whether your terminal’s background is dark or light and pick a matching colour scheme: style colorscheme = { dark = "ocean", light = "ocean-light" } It uses modern approaches to plugins and configuration: you can specify options in TOML and plugins are a builtin feature that integrates with GitHub. The recommended way to configure luish across machines is to write a personal plugin . Mine is luispedro/luish-personal-plugin https://github.com/luispedro/luish-personal-plugin : a plugin.toml with my options, aliases, and the other plugins I want. Here’s an extract: dependencies std.completion = " " tab completion for ~230 commands, git included options autosuggest = true as zsh-autosuggestions options.history file = "~/.histfile" the same file as zsh, in zsh's format share = true alias.global "..." = "../.." On a new machine, I can just paste the URL into a fresh luish installation: plugin add https://github.com/luispedro/luish-personal-plugin That adds it to config.toml , fetches it including all plugins it depends on, recursively , and loads it. Luish has an SSH mode that uses a client/server model, so that you have a local shell that is very responsive even if your server is in Australia light is only so fast: a round trip to the other side of the world takes long enough that you notice it when typing . You can use setopt vars.trace to add history to all the variables, making debugging easier. More debugging features will come soon. Claude is very good at porting This is an ideal Claude-shaped task: there are existing implementations that Claude can always compare itself against. Luish has 100s of test scripts https://github.com/luispedro/luish/tree/main/tests/cases , each run under both luish and dash or zsh , and the output and exit status must match exactly. Telling Claude to implement vared just like in zsh is a very clear instruction, and it just does it one shot prompt & commit https://github.com/luispedro/luish/commit/a127e38 . Claude also found at least one bug in bash a bit of a corner case, but you can set up a self-referential expansion and crash the shell . 2 footnote-2 Claude is very good at polishing I think that the difference between usable software and great software is polish, getting a million little things right: good error messages, handling the corner cases, special-casing for speed and comfort, … As I wrote recently https://luispedro.substack.com/p/links-tweets-photos-september-2026 , the value of noticing bugs has gone up in the Age of Claude. Right now, a good bug report is the same as a pull request. You can type a single prompt asking Claude to make the help text colourful by enabling markdown use . This is obviously a positive contribution, but might not have been worth the time of a human developer: it was necessary to add a markdown parser and then output it with colours. Not hard, but a bit of effort for a human developer. Add hundreds of these small improvements, and you have a polished product. 3 footnote-3 Claude makes it easier both to ship a chabuduo product https://www.tracingwoodgrains.com/p/chabuduo-world and to turn one into a polished product. Whether the equilibrium is more or less chabuduo in the world, it’s not clear to me yet. I think it might be less. Claude is terrible at writing documentation Claude seemingly cannot distinguish between what should be shown to users and what is internal implementation. It dumps internal details into the Getting Started section, so that the important question of “how do I install it?” is buried under three paragraphs of introduction and five paragraphs of implementation details. This was the part of the project where I intervened the most, as I rewrote most of the docs by hand https://github.com/luispedro/luish/commit/03e9350 . 4 footnote-4 Maybe you should write your own shell? We might be back in the early days of open source. If you don’t like a tool, just rewrite it or take someone’s code and adapt it. No plugins or configuration, just edit the code and recompile. Do you like luish but want it to be more like zsh in its arrays? That’s probably one or two prompts away and you can call it Luizsh . Maybe you should let your imagination grow? More generally, ideas like “ maybe I should write my own shell ” used to be crazy, and we’ve trained ourselves to self-censor them. Maybe it’s time to undo that self-censoring and let them bubble up. Agents don’t freeze the 2025 stack One worry that I hear is that, with agents, we’ve locked ourselves into the tech stack of 2025. The training data is Python and Rust, so newer languages have no chance. I think this is 100% wrong Exactly the opposite is true. Luish uses Rhai https://rhai.rs/ as its extension language. I had never heard of it. Claude recommended it, and it makes sense given its tight integration with Rust. In the pre-agent era, I would have played it safe with Python. If it turns out that Rhai is a bad fit in the future, a port of the existing codebase about 11,500 lines of Rhai, adding TAB completion to ~230 commands is one prompt away. Vendor lock-in is much less of a worry. As I wrote above, Claude is very good at porting. 1 footnote-anchor-1 If you run into anything, let me know and I will add it to the next release. 2 footnote-anchor-2 In an interactive bash shell, expands to the command line typed so far, so each doubles the line. echo x ... , with 30 copies of , asks for gigabytes, and bash 5.3 dies with bash: xmalloc: cannot allocate 1073741824 bytes . 3 footnote-anchor-3 When it comes to scientific software, this is the difference between tools we write just for ourselves and tools we write for others see Coelho, PLOS Comput Biol 2024 https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1011920 . 4 footnote-anchor-4 When I ran the draft of this blog post by Claude, it defended itself by claiming that “it is, however, very good at writing documentation for developers and for itself : DEVELOPING.md https://github.com/luispedro/luish/blob/main/DEVELOPING.md is over 1,800 lines of design decisions, notes on dash’s quirks and performance measurements, and it is genuinely useful.” — I think this is right, actually.