Git Exit Code 128: What It Means and How to Fix It

by

Git exit code 128 isn’t one specific error. It’s the code Git uses whenever a command stops with a fatal error, so it tells you only that something went wrong, not what. The real clue is the line that starts with fatal: just before the exit code. Find that line first, then match it to a fix below.

The most common causes are sign-in problems (an expired token or a missing SSH key), a wrong repository URL, the “dubious ownership” safety check, running Git outside a repository, a leftover index.lock file, network or proxy trouble, and very long file paths on Windows. Most take only a minute or two to fix once you know which one you have.

Quick Answer

  1. Run the failing command again in a terminal so you can see the full message.
  2. Read the line that starts with fatal:.
  3. If it mentions authentication, a password, or 403, update your credentials or personal access token.
  4. If it says “Repository not found,” check the URL with git remote -v and confirm you have access.
  5. If it says “dubious ownership,” add the folder as a safe directory.
  6. If it mentions index.lock, close other Git tools and remove the lock file.

In This Guide

What Exit Code 128 Means

Every program returns a number called an exit code when it finishes. Zero means success, and any other number means something failed. Git’s source code uses one shared routine for errors it can’t recover from: it prints a message starting with fatal: and then exits with code 128. That’s why so many unrelated problems show up as “exit code 128.”

You’ll usually see the number in tools that run Git for you, such as GitHub Desktop, Visual Studio, VS Code, Sourcetree, TortoiseGit, CI/CD pipelines, and build servers. These tools often show only “Git failed with exit code 128” and hide or shorten the fatal message. This guide covers Git on Windows, macOS, and Linux, with examples for GitHub, as of September 2026. The same fixes apply to GitLab, Bitbucket, and Azure Repos, though their menu names differ.

How to Find the Real Error Message

Before you change anything, find the exact fatal line. It saves you from guessing.

  1. Open a terminal. On Windows, use Git Bash, PowerShell, or Command Prompt. Our guide to opening a terminal on Windows shows each option. On a Mac, open Terminal.
  2. Go to your project folder. Type cd followed by a space and the folder path, then press Enter. You can also drag the folder onto the terminal window to paste its path.
  3. Run the same command your tool was running, such as git pull, git fetch, git push, or git clone followed by the repository URL. Expected result: Git prints the same failure, this time with the full text.
  4. Find the line that begins with fatal:. Lines starting with remote: or error: just above it often add detail, such as which account was rejected.
  5. Get more detail if needed. On macOS, Linux, or Git Bash, you can put GIT_TRACE=1 and a space in front of the command, as in GIT_TRACE=1 git fetch, to see each step Git takes.
  6. Match the message to one of the sections below, or use the cheat sheet near the end.

If your tool runs Git from a different folder, you can point Git at your project without changing folders by using git -C followed by the project path and the command, for example git -C C:/Projects/website status. Git accepts forward slashes in Windows paths.

Fix Authentication and Permission Errors

Typical messages include fatal: Authentication failed, The requested URL returned error: 403, error: 401, and Permission denied (publickey). The fix depends on whether your remote URL starts with https or uses SSH. Run git remote -v to check.

HTTPS URLs: use a personal access token

GitHub removed password sign-in for Git over HTTPS. According to GitHub’s page About remote repositories, when Git asks for your password, you enter a personal access token instead. A personal access token is a long, generated string that works like an app-specific password.

  1. Create a new token in your GitHub account under Settings > Developer settings > Personal access tokens (GitHub occasionally renames these menus). Give it access to the repositories you need and an expiration date you’ll remember.
  2. Clear the old saved credential. On Windows, open Credential Manager from the Start menu, choose Windows Credentials, and remove the entry for github.com. On a Mac, open Keychain Access and delete the github.com internet password.
  3. Run the Git command again. When prompted, enter your username and paste the token as the password. Expected result: The command succeeds, and your credential helper saves the token.

GitHub recommends using a credential helper, such as Git Credential Manager, so Git remembers your credentials. It’s included with Git for Windows and can sign you in through a browser window instead of a pasted token.

Warning: Treat tokens like passwords. Never paste them into a remote URL, a shared script, or a chat message.

SSH URLs: check your key

If you see Permission denied (publickey), GitHub couldn’t match an SSH key on your computer to your account. GitHub’s guide to fixing the Permission denied (publickey) error lists the checks:

  • Don’t use sudo with Git commands. It can make Git look for a different user’s keys.
  • Check that a key is loaded by running ssh-add -l -E sha256. If it prints nothing, add your key to the SSH agent (a background program that holds your keys).
  • Confirm the key is on your account. Compare the fingerprint with the keys under Settings > SSH and GPG keys on GitHub, and add the public key if it’s missing.
  • Test the connection with the verbose SSH test command shown on GitHub’s page. You connect as the user named git, not your own username.

If you’re new to SSH keys, our guide to using SSH from Windows explains how keys and the ssh command work.

Access was removed

If your credentials are fine but you still get 403, you may no longer have access to the repository, or your organization may require single sign-on approval for your token. Ask the repository owner to confirm your permissions.

Fix “Repository Not Found” and Wrong URLs

Messages like remote: Repository not found or fatal: repository … not found mean the server couldn’t find a repository at that address for your account. For private repositories, hosts often say “not found” instead of “access denied,” so this can also be a permission problem. GitHub’s troubleshooting cloning errors page suggests checking spelling, permissions, and that the repository still exists.

  1. Run git remote -v to see the URL your project uses.
  2. Open the repository in your browser and click the Code button to copy the correct HTTPS URL, or the SSH URL if you use SSH keys. Check for typos, renamed repositories, or a changed owner.
  3. Update the remote with git remote set-url origin followed by a space and the URL you copied. For HTTPS, it looks like git remote set-url origin https://github.com/OWNER/REPO.git. For SSH, paste the SSH URL exactly as copied from the repository page.
  4. Run git remote -v again to confirm, then retry the command. Expected result: Fetch, pull, or push works.

A related message, “remote HEAD refers to nonexistent ref,” appears when a repository’s default branch was deleted. GitHub’s fix is to change the default branch on the repository.

Fix “Detected Dubious Ownership in Repository”

This message appears when the repository folder is owned by a different user account than the one running Git. Git added this check as a security fix in 2022 (CVE-2022-24765) so that files planted in a shared folder can’t make Git run someone else’s settings. It’s common with external drives, network shares, folders copied from another PC, containers, and GUI tools running as a different user.

Before you continue: only mark a folder as safe if you trust it and know why its owner differs.

  1. Read the path in the error. Git usually prints the exact command to fix it.
  2. Run git config –global –add safe.directory followed by a space and the full folder path, for example git config –global –add safe.directory C:/Projects/website. Use forward slashes.
  3. Retry your command. Expected result: The ownership error is gone.

Git reads the safe.directory setting only from protected configuration, meaning your global or system settings, not a repository’s own config file. If a tool still fails after you fix it in the terminal, the tool may run Git under another account (such as an administrator or service account), which has its own global settings. Adding the entry for that account, or taking ownership of the folder, usually solves it. Setting the value to an asterisk turns the check off for every repository, which removes the protection, so avoid it on shared machines. See the git config documentation for details.

Fix “Not a Git Repository”

The message fatal: not a git repository (or any of the parent directories): .git means Git can’t find the hidden .git folder that stores your project’s history.

  • Check your folder. Run git status from the project’s top folder, not a parent folder.
  • Check your tool’s path. If an editor or GitHub Desktop points to a folder that was moved, renamed, or deleted, remove it from the tool and add it again from the new location.
  • Look for the .git folder. It’s hidden by default. If it’s gone, the folder is no longer a repository. Clone the project again rather than trying to rebuild it.
  • Starting a new project? Run git init to create a repository in the current folder.

Fix index.lock Errors

If the message says Unable to create … .git/index.lock: File exists, Git found a lock file. Git creates this file while it’s working so two processes don’t change the repository at the same time. Git’s own message explains that another Git process seems to be running, and if not, to remove the file manually to continue.

Warning: deleting the lock while Git is actually running can damage your repository, so check first.

  1. Close editors and Git tools that might be using the repository, and wait for any running pull, commit, or rebase to finish.
  2. Check for running Git processes. On Windows, look for git.exe in Task Manager. On macOS or Linux, check Activity Monitor or run ps aux | grep git.
  3. Delete the lock file. Open the hidden .git folder in your project and delete index.lock. On macOS, Linux, or Git Bash, you can run rm .git/index.lock from the project folder.
  4. Retry your command. Expected result: Git runs normally.

Similar lock files, such as HEAD.lock or a lock inside the refs folder, are handled the same way.

Fix Network and Proxy Errors

Messages like Could not resolve host, Failed to connect, Connection timed out, or SSL certificate problem point to your connection rather than your credentials.

  • Check the basics. Open the repository in your browser to confirm the site is up and you’re online.
  • Check proxy settings. On a work network that uses a proxy, Git needs the proxy address. Ask your IT team for it and set it with git config –global http.proxy followed by the address, such as http://proxy.example.com:8080. If you left that network, remove the old setting with git config –global –unset http.proxy.
  • Try the other protocol. Some networks block SSH on port 22. Switching the remote to HTTPS often works.
  • Certificate errors: don’t turn off SSL verification to make the error go away. Ask IT whether your network inspects traffic and needs its certificate installed.

Fix Long Path Errors on Windows

If you see Filename too long during clone or checkout on Windows, some file paths are longer than the classic Windows limit of 260 characters. You have two options:

  1. Clone to a shorter path, such as C:/src, so the full paths stay shorter.
  2. Turn on long path support in Git for Windows by running git config –global core.longpaths true, then retry. This setting is specific to Git for Windows, and some other programs on your PC may still struggle with very long paths.

Error Message Cheat Sheet

If the fatal message mentions Likely cause First fix to try
Authentication failed, 401, 403 Expired or wrong credentials New personal access token; clear saved credential
Permission denied (publickey) SSH key missing or not on account Load key with ssh-add; add public key to GitHub
Repository not found Wrong URL or no access Copy URL from Code button; git remote set-url
dubious ownership Folder owned by another user Add safe.directory for that path
not a git repository Wrong folder or missing .git cd into the project; re-add in your tool
index.lock: File exists Leftover lock file Close Git tools; delete the lock
Could not resolve host, timed out Network or proxy Check connection and http.proxy
Filename too long Windows path limit Shorter folder or core.longpaths

Troubleshooting

It works in the terminal but fails in my editor or GUI

The tool may use its own bundled copy of Git, a different user account, or a different credential store. Check the tool’s settings for the Git path, sign in again inside the tool, and repeat the safe.directory fix for the account the tool runs as.

It fails only in a CI/CD pipeline

Build servers run under a service account without your personal credentials. Make sure the pipeline has a valid token or deploy key with access to the repository, and that the checkout folder is owned by the account running the job.

Git says the repository is corrupt

Messages such as “bad object” or “loose object is corrupt” point to damaged files in the .git folder. Run git fsck –full to list problems. The safest fix is usually to clone a fresh copy and move over any uncommitted work.

I fixed one error and got a different one

That’s normal. Git stops at the first fatal problem, so fixing it can reveal the next one. Read the new fatal line and repeat the process.

The error mentions a submodule

Submodules are repositories inside your repository, and each has its own URL and permissions. Run git submodule update –init in a terminal to see which one fails, then apply the same fixes to its URL or access.

Frequently Asked Questions

Is exit code 128 a bug in Git?

Usually not. It’s Git’s standard code for a fatal error, and the cause is almost always your setup: credentials, paths, permissions, or the network.

Why does GitHub reject my password?

GitHub removed password authentication for Git over HTTPS. Use a personal access token, a credential helper such as Git Credential Manager, or SSH keys.

Is it safe to delete index.lock?

Yes, once you’ve confirmed no Git process is running. If Git is still working, wait for it to finish first.

Should I set safe.directory to an asterisk?

Only on a machine where you trust every repository and user. It turns off the ownership check completely. Adding specific folders is safer.

Does exit code 128 mean I lost my work?

No. A fatal error stops the command before it finishes. Your commits and files are normally untouched.

Why do I get exit code 128 when cloning?

During a clone, it’s most often a wrong URL, missing access, or failed sign-in. On Windows, long file paths are another common cause.

Where do I find the correct clone URL?

Open the repository page on GitHub while signed in and click the Code button. Copy the HTTPS or SSH URL from there.

Summary

  1. Exit code 128 means Git hit a fatal error; the fatal: line tells you which one.
  2. Re-run the command in a terminal to see the full message.
  3. For sign-in errors, use a personal access token over HTTPS or fix your SSH key.
  4. For “not found,” verify the URL with git remote -v and your access.
  5. For “dubious ownership,” add the folder with safe.directory.
  6. For lock, network, and long path errors, remove the stale lock, fix proxy settings, or shorten paths.

Next step: open a terminal in your project, run the failing command again, and copy the exact fatal line so you can match it to the cheat sheet above.

Related posts: