Oh My Zsh: A Framework for Your zsh Configuration

The problem Oh My Zsh solves, and who ends up using it

zsh ships with a configuration language and almost nothing configured. Completion, prompt rendering, history behaviour and per-tool aliases all have to be written by hand in ~/.zshrc, and a useful setup is hundreds of lines before it does anything interesting. Oh My Zsh is a framework that supplies that layer: the README describes it as "an open source, community-driven framework for managing your zsh configuration", with plugins, themes and an auto-update tool. The repository layout matches the claim. plugins/ holds the bundled plugins, themes/ holds the prompt themes, lib/ holds the shared functions the framework loads, and oh-my-zsh.sh is the script your .zshrc sources to bring all of it in. It is aimed at people who already chose zsh and now want the configuration work done for them, which is why the README's own framing is about saving time rather than about shell features. If you have not chosen a shell yet, this is the wrong entry point: Oh My Zsh configures zsh, it does not replace it.

How the framework loads plugins and themes at shell startup

The mechanism is a load order, not a daemon. Your ~/.zshrc sets two variables, plugins and ZSH_THEME, then sources oh-my-zsh.sh. That script pulls in the framework library from lib/, resolves the theme file from themes/, and iterates the plugins array, sourcing each plugin's script from plugins/ or from custom/. Plugins are ordinary shell files, so a plugin's effect is whatever commands and aliases it defines when sourced. The README points readers at each plugin's own README for "the aliases (if the plugin adds any) and extra goodies". The custom/ directory is the extension point: it is where user plugins and themes live so they are not overwritten by updates. Updates are handled by tools/ inside the repository, which is why the README has a "Getting Updates" section separate from installation. The important consequence is that startup cost is the sum of everything you source, and the framework gives you no lazy loading of its own; anything you add to plugins=() is paid for on every new shell.

Installing Oh My Zsh and enabling your first plugin

The README lists three install one-liners, for curl, wget and fetch. The curl form is the one most people copy. It downloads tools/install.sh from the master branch and pipes it into sh, so the script runs before you have read it.

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

If raw.githubusercontent.com is blocked, the README gives a mirror at install.ohmyz.sh and says the mirror "may be required if you're in a country like China or India (for certain ISPs)". The wget equivalent of the mirror is:

sh -c "$(wget -O- https://install.ohmyz.sh/)"

The README recommends inspecting the script first, and shows how to download it without executing it. Do this before running either command above.

wget https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh
sh install.sh

After installation, the README states that any previous .zshrc is renamed to .zshrc.pre-oh-my-zsh, and that you move the configuration you want to keep into the new .zshrc yourself. Editing that file is the first real use. Open ~/.zshrc, find the plugins=() array, and add plugin names separated by whitespace.

plugins=(
  git
  dotenv
  macos
)

The README is explicit that commas must not be used between plugin names, because "it will break". The names in that array are the directory names under plugins/, so git, dotenv and macos are valid and a typo silently loads nothing. To change the prompt, set ZSH_THEME in the same file to the name of a theme from themes/.

Where Oh My Zsh gets in your way

The installer modifies your shell configuration rather than sitting beside it. Renaming .zshrc to .zshrc.pre-oh-my-zsh is the documented behaviour, and it means any function, alias or PATH edit you had is gone from the active configuration until you move it back by hand. There is no documented merge. The second constraint is platform. The compatibility table marks Android, FreeBSD, Linux, macOS and Windows under WSL2 as supported, and OS/2 Warp as not supported; native Windows is not listed as supported at all, and the only Windows entry is WSL2. If your work happens in PowerShell or cmd, this project does not apply to you. The third constraint is startup cost. Every plugin in the array is sourced on each interactive shell, and the framework does not defer them. A long plugins list on a slow machine shows up as latency before the first prompt, and the README does not document a lazy-loading facility to work around it. The fourth is scope: the README's contribution section carries a heading telling contributors "Do Not Send Us Themes", so theme additions are not part of the normal pull request flow even though themes are a headline feature.

Starship and other prompt tools are a different kind of thing

The natural comparison is a prompt generator such as Starship, and the difference is architectural. Oh My Zsh is a zsh framework: it sources shell files into your interactive session and can define aliases, functions and completions, not just a prompt. A prompt tool renders the prompt, usually from a declarative config file, and leaves the rest of your shell untouched. That means a prompt tool composes with a hand-written .zshrc, while Oh My Zsh expects to own the loading of your configuration through oh-my-zsh.sh. If all you want is a themed prompt with git status, adding a framework for it is more machinery than the problem needs. If you want the alias sets and per-tool helpers that the plugins/ directory provides, a prompt tool alone will not give them to you. The two are not mutually exclusive in principle, but stacking them means two systems deciding what your prompt looks like.

Updating, uninstalling and the MIT licence

The README documents an auto-update tool in the description and a "Getting Updates" section with subsections for update verbosity and manual updates, so updates are a supported path rather than something you script yourself. The manual update route exists for people who disable the automatic behaviour. Uninstalling is also documented as its own section, which matters because the install script renames your original .zshrc: restoring it is part of getting back to a plain zsh setup. On licensing, the repository carries LICENSE.txt and the README has a License section; the project is MIT, which permits use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permission grant, not advice about your situation: if you vendor the framework into a product or a company image, check how the notice is preserved with whoever handles your compliance, since MIT requires the notice to travel with copies.

Editorial conclusion

Adopt Oh My Zsh if you already run zsh and want aliases, prompt themes and plugin loading without writing the scaffolding yourself. Do not adopt it if you want a minimal shell startup, if you cannot accept the installer renaming your .zshrc to .zshrc.pre-oh-my-zsh, or if you are on a platform outside the compatibility table such as native Windows without WSL2. Before installing, open tools/install.sh and read it, confirm zsh --version reports 4.3.9 or newer, and check whether your plugins belong in the plugins=() array in ~/.zshrc or in custom/.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository