Go Command Not Found After Installing Go on Linux Fully

You downloaded Go, extracted it and typed go version, and got bash: go: command not found. The binary is on disk but the shell does not search its folder. The cause is always a PATH problem, and the fix has three steps. The same lookup logic is described in debugging PATH command lookup. The steps assume Go 1.23 on a 64-bit Linux system.

Check what exists

ls -l /usr/local/go/bin/go
echo "$PATH" | tr ':' '\n'
command -v go || echo "go is not on PATH"

-rwxr-xr-x 1 root root 15M Oct  1 08:00 /usr/local/go/bin/go
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
go is not on PATH

If the first line shows the file, the install is fine and PATH is the problem. If it says no such file, the extraction went to the wrong place; see the next section. If go works with its full path (/usr/local/go/bin/go version), nothing else is broken.

Install per the official steps

curl -LO https://go.dev/dl/go1.23.2.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.23.2.linux-amd64.tar.gz

Removing the old tree first matters: extracting a new version over an old one leaves stale files and can produce odd build errors. Check the downloaded file's SHA-256 against the value on the download page before extracting, as in verifying downloads. The archive creates the go directory itself, so the target is /usr/local, not /usr/local/go.

Add it to PATH

echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.profile
source ~/.profile
go version

go version go1.23.2 linux/amd64

Which file you edit matters. A login shell reads ~/.profile (or ~/.bash_profile); a terminal emulator that starts a non-login shell reads ~/.bashrc. If the command works after source but vanishes in a new terminal, the line is in the wrong file; see bashrc versus bash_profile. For all users, put a script in /etc/profile.d/go.sh. The official installation guide at go.dev/doc/install documents this step.

Tools you install later

go install golang.org/x/tools/cmd/goimports@latest
goimports -h
go env GOPATH

If goimports: command not found appears after a successful install, the tool went to $(go env GOPATH)/bin, which is ~/go/bin by default, and that directory is not on PATH. The line added above covers it. Check go env GOBIN too: if set, installs go there instead.

Other causes

A distribution package (apt install golang-go) puts a link at /usr/bin/go, usually an older version; remove it or put the newer one first on PATH, because a stale hash table can make the shell remember the old location, fixed with hash -r. In scripts and CI, the environment may not read profile files at all, so set PATH in the job. Under sudo, the secure_path setting overrides your PATH, so use the full path or sudo env "PATH=$PATH" go .... In cron, set the PATH at the top of the crontab, as in scripts that fail in cron.

How the shell finds a command

When you type go, the shell does not search the disk. It reads the PATH variable, a colon-separated list of directories, and looks in each in order for an executable file with that name. The first match wins. If none is found, you get "command not found". Installing a program only puts files on disk; making the shell find them is a separate step, which is why a successful extraction and a failed command can both be true. This is also why the same program is found in one terminal and not another: each shell has its own PATH, built from the files it read at start.

Bash adds one more layer, a hash table of commands it has already found. After the first successful lookup, it remembers the full path and skips the search. If you install a newer version elsewhere and put it first on the path, the shell may still run the old one until you run hash -r or open a new terminal. When a version change does not take effect, suspect the hash before suspecting the install.

Installing for one user or for everyone

The official instructions install into /usr/local/go, which needs root and serves all users. A user-level install into ~/sdk or ~/.local/go needs no root, keeps the system clean and makes it simple to keep several versions side by side. The trade is that each user manages their own copy and every account that needs Go must set its own path. Choose by who uses the machine: a shared build server benefits from one managed copy, and a laptop is simpler with a personal one.

For multiple versions, Go has a built-in mechanism. Installing a specific toolchain with go install golang.org/dl/go1.22.8@latest and then running go1.22.8 download places a wrapper in ~/go/bin, which lets a project test against an older release without disturbing the main installation. Recent releases of Go can also fetch the toolchain that a module's go.mod requests, which removes most reasons to juggle versions by hand.

Making the path change reliable

The line you add to a profile file must be read by the shell you use. Graphical sessions on some systems read ~/.profile once at login, while terminal windows read ~/.bashrc for each new shell, and a change in the wrong file appears to work after you log out and in, but not in a new tab. Test by opening a new terminal and running echo "$PATH". For services and scheduled jobs, the profile is never read, so set the path in the unit file or the crontab, or call the binary by its absolute path. Editors and IDEs launched from a desktop icon may not see the terminal's path at all, a frequent cause of "Go not found" errors in an editor plugin when the terminal works.

Checking the installation end to end

A quick test confirms that everything is wired correctly. Run go version, then go env GOROOT GOPATH, and compare them with where you expect the files to be. Create a small module with go mod init example.test/hello, write a main function that prints a line and run go run .. If that works, the compiler, the standard library and the module cache are all functioning. A failure at this step points to permissions on the cache directory or a proxy setting, which are different problems from the missing path.

Where this does not apply

If go version prints but go build fails, the problem is not PATH; see cannot find package. On macOS use the installer package, which adds /usr/local/go/bin to /etc/paths.d, or Homebrew. On Windows the installer adjusts the system PATH and needs a new terminal to take effect.

For a reference on how the shell resolves names, read the command search section of the Bash manual; it explains the hash table that makes the shell remember a stale location.