Zsh Missing on Kali After Upgrade: Get It Back

If zsh seems to have gone missing after a Kali upgrade, run which zsh — it is almost certainly still installed. The real answer is that an upgrade never changes your login shell, and never overwrites the configuration files in your home folder. That is deliberate, because doing either could leave you unable to use your own machine. So new Kali installations have started in zsh since 2020.4, while every upgraded account quietly kept bash and its old settings. Nothing broke. To switch: copy Kali's config with cp /etc/skel/.zshrc ~/, then run chsh -s /usr/bin/zsh, then log out and back in.

"The upgrade didn't work"

Jake had spent an evening upgrading the Kali laptop he uses for his course, which went fine, took a while, and finished without complaint.

Then he opened a terminal and it looked exactly as it had before. The same plain prompt. None of the colors from the videos, none of the suggestions appearing as he typed. Every guide he found said Kali uses zsh now.

"So the upgrade didn't work," he said. "Two hours, and it's the same as it was."

"The upgrade worked. Type which zsh."

It printed a path. It was there, and had been the whole time.

"It's installed. It's just not your shell, because an upgrade isn't allowed to change that. Changing which shell a person logs into, or rewriting the config files in their home directory, is how you lock somebody out of their own computer. So packaging rules forbid it, and the rules are right."

That is the entire explanation, and it is worth having properly, because once you know it a whole family of "why didn't the upgrade apply" questions answers itself.

Why an upgrade cannot do this for you

Two rules are at work, and both exist for good reasons.

Your home directory belongs to you. The dot-files in it — the hidden configuration files with names beginning with a period — are yours. Package upgrades will not overwrite them. If they did, every upgrade would risk deleting aliases, functions, environment variables and paths that somebody spent years building.

Your login shell is a per-account setting. It is recorded once per user and changed only when somebody deliberately changes it. An upgrade that silently switched everyone to a different shell could break scripts, break automated logins, and in the worst case leave an account unable to start a working shell at all — on a remote server, that is a machine you cannot get into any more.

So when Kali made zsh the default, that default applied to accounts created afterwards. Existing accounts were left exactly as they were, and the distribution's own advice was for upgraders to make the change themselves.

The same logic explains why a new default wallpaper, prompt or editor configuration never arrives with an upgrade either. Defaults apply at account creation. After that, your home directory is yours.

What happened, and when

Kali 2020.3 made zsh available and invited people to try it, while bash stayed the default. That is the release the original version of this post was written against, and it is why guides from that period say zsh is "missing" — on a 2020.3 machine you genuinely did have to go and get it.

Kali 2020.4, in November 2020, completed the change and made zsh the default for new installations.

Every guide written between those two releases describes a different situation, which is a large part of why searching this is confusing. If you are unsure which release you actually ended up on, our guide to checking your Kali version properly answers it in one command — and explains why the kernel version is not the answer to that question.

Step 1: find out what you actually have

Three answers, and between them they tell you which situation you are in:

That last row catches people out for an entire afternoon. Terminal emulators can be told to run a particular command instead of your login shell, and when that is set, changing the login shell does nothing visible. If everything else looks correct and it still opens bash, the setting is in the terminal, not in the system.

Step 2: install it, if it really is absent

The two plugins are worth installing at the same time, because they are most of what people actually notice about Kali's shell:

• Syntax highlighting colors your command as you type it. A command that does not exist turns red before you press Enter, which catches typos and half-remembered tool names constantly.
• Autosuggestions shows a greyed-out completion from your history as you type, accepted with the right arrow key. On a machine where you run the same long commands repeatedly, this is the feature you would miss most.

If apt complains about a half-configured package rather than installing, stop and repair that first — our post on the dpkg was interrupted error covers the recovery. Installing on top of a broken package state is how a small problem grows.

Step 3: take Kali's configuration, before you switch

This is the step people skip, and skipping it is why so many end up with a zsh that looks worse than the bash they left.

Kali's famous two-tone prompt, the highlighting, the suggestions — none of that is zsh. It is all in a configuration file Kali supplies. Bare zsh with no configuration is a plain, slightly austere shell, and if that is what you get, you have switched shells without bringing the settings along.

The file lives in the skeleton directory, which holds the defaults copied into a home folder when an account is created:

That skeleton directory is the answer to a question people ask in a dozen different forms: why didn't my existing account get the new defaults? Because that copy happens once, when the account is created, and never again. It is not a bug and there is no setting to make it happen automatically — when a distribution improves what it ships, existing users go and take it.

Take the same opportunity to move anything you care about out of your bash configuration. Aliases, functions and additions to your path live in the file for one shell, and the other shell does not read it. Open ~/.bashrc, find the lines you actually added over the years, and append them to the end of your new ~/.zshrc.

Step 4: make it your login shell

Before changing anything permanent, try it. Type zsh and press Enter, and you are in a zsh session using the config you just copied. Type exit and you are back where you started. Nothing has been changed, and if the prompt does not look right this is the moment to find out.

Happy with it? Make it permanent:

It asks for your password — you are changing a property of your own account, so that is expected. Then log out and log back in.

Two things routinely trip people here:

It does not take effect in the terminal you are sitting in. The login shell is chosen at login. The session you are in was started by the old one and keeps running it until you close it. People run chsh, see no change, run it again, and conclude it is broken.

The path has to be right, and listed in /etc/shells. If chsh refuses, check the path which zsh gave you and use exactly that. The list of permitted login shells is a safety measure, not an obstacle.

Root has its own shell, and its own config

Every account has a separate login shell and separate configuration, so changing yours does nothing for root. That is why a root shell can still look like bash long after your own is zsh.

Kali has not signed you in as root by default since 2020, so for most people this simply does not come up. If you do spend time in a full root shell, root's configuration comes from root's own home directory rather than yours, and the same copy-then-switch steps apply there.

When zsh will not start at all

A different problem with a different fix: zsh is your shell, and it either throws errors on startup or does not give you a usable prompt.

The diagnostic is one flag:

If it starts cleanly like that, zsh is fine and your configuration is the problem. That narrows an intimidating failure down to one file.

By far the most common cause is a configuration copied from somewhere else — a friend's machine, a video, a repository of somebody's personal setup — that expects a framework or plugins this machine does not have. Every missing piece produces an error at startup.

Open a fresh terminal and you are back to Kali's supplied setup. Your old file is still there under its new name if you want to pick lines out of it — and reading it side by side with the working one is a genuinely good way to learn what each line was doing.

If you cannot get a working terminal at all

Press Ctrl + Alt + F3 for a plain text console and sign in there. It does not depend on your desktop, and it is the escape hatch worth remembering before you experiment with shells rather than after.

From there, chsh -s /bin/bash puts you back to a shell you know works, and Ctrl + Alt + F7 or F2 returns you to the desktop. A rescue that takes thirty seconds when you know it exists, and an evening when you do not.

Going back to bash, which is a legitimate choice

Log out, log back in, done. Your .bashrc never went anywhere, so everything is exactly as you left it.

And to be plain, since the tone of most write-ups on this implies otherwise: preferring bash is not a failure to keep up. If you write scripts that run on servers, bash is what is there, and staying fluent in the shell you actually deploy to has real value. A common and sensible arrangement is zsh at the prompt, bash in files — and because any script starting with a line naming its interpreter runs under that interpreter regardless of what launched it, the two do not conflict.

What zsh genuinely gives you for interactive work is worth the switch for most people: suggestions from your own history, highlighting that catches typos before you run them, better completion, and directory movement that saves keystrokes all day. Kali did not switch on a whim.

Five things to try in the first five minutes

Having switched, it is worth knowing what you actually gained, because otherwise it is just a different-looking prompt. These are the ones that change how you work rather than how the terminal looks.

• Type part of a command and press the up arrow. Instead of walking back through everything you have ever run, it walks back through only the commands that started that way. Type sudo apt, press up, and you are stepping through your apt history. This is the single biggest time-saver on the list.
• Press the right arrow to accept a suggestion. The greyed-out text after your cursor is a completion from your history. One key and it is yours.
• Press Tab twice. Instead of a static list, you get a menu you can move around with the arrow keys and select from. On a long directory of tool names this is much faster than typing.
• Type a directory name with no command in front of it. With Kali's configuration, changing directory does not need the command at all — the name on its own is enough.
• Watch the colors while you type. A command that exists goes one color, one that does not stays another. You will catch mistyped tool names before pressing Enter, which on a long command with sudo in front of it is worth having.

One habit worth forming now rather than later: keep a copy of your ~/.zshrc somewhere outside the machine. Everything you add to it — aliases, shortcuts, paths — is the accumulated result of noticing small annoyances and fixing them, and it is the one file people genuinely regret losing when they reinstall. It is a few kilobytes of text. Put it wherever you keep things you would be annoyed to lose.

Questions people actually ask about this

Why is zsh missing after upgrading Kali?

It usually is not missing, it simply was never switched on for your account. An upgrade deliberately never changes your login shell and never overwrites configuration files in your home directory, because both could leave you unable to use your own machine. New installations from Kali 2020.4 onward got zsh as the default, while upgraded machines kept bash and their existing settings. Check whether the package is installed before assuming anything is broken.

How do I switch to zsh on Kali?

Make sure the package is installed, copy Kali's supplied zsh configuration from the skeleton directory into your home folder, then run chsh with the path to zsh to change your login shell. Log out and back in for it to take effect. Doing it in that order matters, because switching first and copying afterwards gives you a plain zsh with none of the prompt or highlighting Kali ships.

When did Kali switch to zsh?

Kali 2020.3 began the transition by making zsh available and inviting people to try it, and Kali 2020.4, released in November 2020, made it the default shell for new installations. That two-release approach is why guides from that period disagree with each other. Anything installed since then starts in zsh, and anything upgraded from before it keeps whatever shell that account was already using.

Why does chsh not change my shell straight away?

Because your login shell is chosen at login, not while you are working. The terminal you are sitting in was started by your old shell and keeps running it until you close the session. Log out and back in, or reboot, and the new shell is used. If you want to try the new shell immediately without changing anything permanently, just type its name and press Enter.

How do I go back to bash on Kali?

Run chsh with the path to bash and log out and back in. Nothing is lost by doing this, your bash configuration file is still in your home directory where it always was, and you can switch back later. Preferring bash is a legitimate choice rather than a failure to adapt, particularly if you write scripts that other people run on servers where bash is what exists.

My zsh prompt looks plain compared to screenshots. Why?

Because you switched shells without taking Kali's configuration with you. The colored two-tone prompt, the syntax highlighting and the command suggestions all come from the configuration file Kali supplies, not from zsh itself. Copy that file from the skeleton directory into your home folder and start a new terminal, and the familiar prompt appears.

What is the skeleton directory and why does it matter here?

It is the folder holding the default configuration files that get copied into a new user's home directory when the account is created. That copying happens once, at account creation, and never again, which is exactly why an upgrade cannot give your existing account new defaults. When a distribution improves its shipped configuration, existing users get it by copying from there themselves.

Zsh will not start or throws errors at startup. What do I do?

Start zsh with the option that skips all configuration files. If it starts cleanly that way, your configuration file is the problem rather than zsh, and the usual cause is a config copied from somewhere else that refers to plugins or a framework this machine does not have. Rename the file, start a fresh shell, and put back Kali's supplied version.

How do I check which shell I am actually using?

Print the shell environment variable to see what is running right now, and look at your line in the password file to see the login shell that will be used next time. Those two can legitimately disagree, which confuses people mid-change. If the running shell is zsh but the login shell is still bash, you started zsh manually and the change was never made permanent.

Do I need to change root's shell separately?

Yes, because each account has its own login shell and its own configuration. Changing yours does nothing for root, which is why a root shell can still look and behave like bash long after your own is zsh. Kali does not sign you in as root by default in any case, so this only matters if you regularly work in a full root shell.

Is zsh better than bash, honestly?

For interactive use, yes, and that is why Kali switched. Command suggestions from your history, syntax highlighting that shows a typo before you run it, better completion and easier directory movement all add up over a working day. For writing scripts that other people will run, bash is still the safer target because it is what exists everywhere. Many people use zsh at the prompt and write bash in files.

Will switching shells break my scripts?

Not if they begin with a line naming the interpreter, which is what that line is for. A script starting with the bash path runs under bash no matter which shell you launched it from. What can break is anything you had defined in your bash startup file, since aliases, functions and path additions live in the configuration for one shell and are not read by the other. Move what you need across.

Does any of this work differently on WSL or in a container?

The same rules apply with a couple of extra wrinkles. Container images often lack the tool that changes your login shell and are usually configured to start a particular shell explicitly, so the setting is on the outside rather than inside. Under WSL, the login shell is honored but the way you open the session can override it, so check your terminal profile before concluding that the change did not work.

What are zsh-syntax-highlighting and zsh-autosuggestions?

They are the two plugins that account for most of what people notice about Kali's shell. Highlighting colors your command as you type it, turning a mistyped command red before you press Enter. Suggestions show a greyed-out completion from your history that you accept with the right arrow key. Both ship with Kali and are enabled by the supplied configuration file.

How do I know which Kali release I upgraded to?

Read the release file in the system configuration directory, which every installation has and which reports the version the system considers itself to be. Do not use the kernel version for this, because it answers a different question entirely. Knowing the release matters here because the guidance for this problem is different before and after the 2020.4 transition.

What Jake ended up with

Three commands, one log-out, and a terminal that finally matched the ones in his course videos. About four minutes, after an evening of believing a two-hour upgrade had failed.

"So nothing was wrong. At any point."

"Nothing was wrong. Your home directory is yours, and the upgrade respected that. It looked like a failure because the thing that protects your settings also protects them from improvements."

"That's going to keep happening, isn't it."

"Every time a distribution changes a default, yes. Now you know where to look."

Which is the real value of this one. The shell takes four minutes. Knowing that /etc/skel exists, and why your account never receives new defaults, will save you the same evening a dozen more times on a machine you keep for years.

Revision note. Originally published in August 2020, days after Kali 2020.3 landed, and rewritten on 9 August 2026. At the time it was written the transition was genuinely half-finished — zsh had just been offered, bash was still the default, and "zsh is missing" was a fair description of what people were seeing. What settled afterwards is the useful part: 2020.4 completed the change in November 2020, and everything since then behaves the same way, so the question today is almost never about a missing package. It is about a packaging rule that protects your home directory and your login shell from being changed underneath you, which is a good rule and the reason your account never receives new defaults. So this version explains the cause first, then gives the fix, then gives the recovery routes before asking you to change anything — because a shell change is one of the few things a beginner can do that makes it hard to open a working terminal afterwards. If your machine does something this page does not cover, particularly under WSL or in a container where the rules bend, do write in through the contact page and tell us what you saw.