The install itself takes about a minute. What takes an hour is the part nobody writes down: the environment problems that surface immediately after, all of which look like the tool is broken when it is not.
The install
Claude Code ships as a command-line tool. You install it globally with your package manager of choice, then authenticate once through the browser. On a clean machine with a current Node runtime, that is the whole process.
Run the version command afterward. If it prints a version, you are done and the rest of this article is insurance. If it prints nothing, or the shell says the command is not found, you have hit the first of the three.
One: the binary is not on your PATH
This is by far the most common failure, and it has nothing to do with Claude. Your package manager installed the binary into a directory your shell does not search. The install succeeded; your shell simply cannot see the result.
Ask your package manager where it puts global binaries, confirm that directory appears in your PATH, and add it to your shell profile if it does not. Then open a new terminal, because the current one is still running with the old environment.
If a fix involves changing your shell profile, it did not take effect in the window you are typing in. Open a new one before concluding it failed.
Two: the Node version is too old
If you have a version manager installed, you may have several runtimes and a default that is years behind whatever you last used in a project. The error this produces is rarely a clean message about versions; it is usually a syntax error from deep inside a dependency, which sends people debugging the wrong thing entirely.
Check the active version before anything else. If it is old, switch, set the new version as your default, and reinstall. Skipping the reinstall is a common miss, because the previous install is still linked against the old runtime.
Three: permissions on the config directory
The tool writes configuration and credentials into a directory in your home folder. If an earlier command was run with elevated privileges, that directory can end up owned by root, and every subsequent normal-user run fails to write to it.
The symptom is inconsistent: it authenticates, then forgets. Or settings do not persist between sessions. Check the ownership of the config directory and correct it to your own user.
Installing developer tools with elevated privileges is what causes this in the first place. If a package manager needs root to install a global package, fix the package manager's directory permissions instead.
After it runs
A working install is the starting line, not the finish. The first real decision is what goes in your project's instruction file, because that single file does more to change output quality than any prompt technique.
Start it short. Most instruction files people write are three times longer than they should be, and the extra length actively dilutes what matters. Say what the project is, what conventions to follow, and what to never touch. Add more only when you catch a mistake worth preventing twice.