How to resolve git did not exit cleanly exit code 128 error on TortoiseGit?

git error

TortoiseGit

troubleshooting

exit code 128

git did not exit cleanly

How to resolve git did not exit cleanly exit code 128 error on TortoiseGit?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Start Practicing Learn More

The TortoiseGit error "git did not exit cleanly (exit code 128)" means Git itself encountered a fatal error and the GUI is only reporting the exit code. Exit code 128 is Git's generic "fatal" signal, so the real diagnosis comes from reproducing the failing command in a terminal, reading the actual error message, and then fixing the specific repository, credential, or configuration issue that caused it.

What Exit Code 128 Means

When Git hits a fatal error, it prints a message starting with fatal: and exits with code 128. TortoiseGit captures the exit code but often truncates or hides the fatal: message in its dialog box. That is why the same error can mean dozens of different things: bad remote URL, expired credentials, corrupted repository, missing branch, permission denied, or lock file contention.

The TortoiseGit dialog is a symptom reporter, not a diagnostic tool. The fix always starts by running the command outside the GUI.

Step 1: Reproduce the Error in a Terminal

Open a terminal (Command Prompt, PowerShell, or Git Bash) in the same repository directory and run the operation that failed:

bash

1# Check basic repository health
2git status
3
4# If the error was during fetch/pull
5git fetch origin
6
7# If the error was during push
8git push origin main
9
10# If the error was during clone
11git clone https://github.com/user/repo.git

The terminal output will show the full fatal: message, which tells you what is actually wrong. Common examples:

1fatal: unable to access 'https://github.com/user/repo.git/': Could not resolve host: github.com
2fatal: Authentication failed for 'https://github.com/user/repo.git/'
3fatal: repository 'https://github.com/user/old-repo.git/' not found
4fatal: Unable to create '.../.git/index.lock': File exists
5fatal: bad object HEAD

Each of these has a different fix.

Step 2: Check for Lock Files

A stale lock file is one of the most common causes. If a previous Git operation crashed or was killed mid-operation, it may have left a .lock file that blocks subsequent operations.

bash

1# Check for lock files
2dir .git\*.lock          # Windows Command Prompt
3ls .git/*.lock           # Git Bash / PowerShell
4
5# Common lock files
6# .git/index.lock       - blocks most operations
7# .git/HEAD.lock        - blocks checkout/commit
8# .git/packed-refs.lock - blocks ref updates

If you find lock files and no Git process is currently running, delete them:

bash

1# Windows
2del .git\index.lock
3del .git\HEAD.lock
4
5# Git Bash
6rm -f .git/index.lock
7rm -f .git/HEAD.lock

Only delete lock files when you are certain no other Git operation is active. Check Task Manager for running git.exe processes first.

Step 3: Verify Remote URL and Authentication

A large percentage of exit code 128 errors come from remote access failures. The remote URL may have changed, your token may have expired, or SSH key authentication may be misconfigured.

bash

1# Check configured remotes
2git remote -v
3
4# Test SSH connectivity (if using SSH)
5ssh -T [email protected]
6
7# Test HTTPS connectivity (if using HTTPS)
8git ls-remote https://github.com/user/repo.git

If you recently switched from password authentication to token-based authentication (GitHub deprecated passwords in 2021), TortoiseGit may still have the old password cached.

bash

1# Clear cached credentials on Windows
2git credential reject <<EOF
3protocol=https
4host=github.com
5EOF
6
7# Or use Windows Credential Manager
8# Control Panel -> Credential Manager -> Windows Credentials
9# Delete entries for github.com

Step 4: Check Repository Integrity

If git status itself fails, the repository may be corrupted:

bash

1# Verify repository is valid
2git rev-parse --is-inside-work-tree
3
4# Run filesystem check
5git fsck --full
6
7# Check for a corrupted HEAD
8git log -1

If git fsck reports errors, you have a corrupted repository. The recovery path depends on the type of corruption:

bash

1# If HEAD is bad, reset to a known good commit
2git reflog
3git reset --hard HEAD@{1}
4
5# If objects are missing, fetch them from the remote
6git fetch origin
7git reset --hard origin/main

Step 5: Align TortoiseGit's Tool Configuration

TortoiseGit uses external Git and SSH executables. If it points to a different Git installation or SSH client than your terminal, the same repository can behave differently between the two.

Check these settings in TortoiseGit (Settings > General):

Setting	What to Check
Git.exe Path	Must point to the same `git.exe` your terminal uses. Run `where git` to find it.
SSH Client	TortoiseGit defaults to TortoisePlink. If your keys are in OpenSSH format, switch to the Git-bundled `ssh.exe`.
Credential Helper	Should match what your terminal uses. Run `git config credential.helper` to check.

A common scenario: your terminal uses Git for Windows' built-in OpenSSH, but TortoiseGit uses TortoisePlink, which reads Putty-format keys (.ppk) instead of OpenSSH keys. The terminal works fine, but TortoiseGit fails with exit code 128 because TortoisePlink cannot read your id_rsa file.

bash

1# Find which git.exe your terminal uses
2where git
3
4# Find which ssh TortoiseGit should point to
5# Usually: C:\Program Files\Git\usr\bin\ssh.exe

Systematic Troubleshooting Order

Work through these in sequence rather than guessing:

Run the failing operation in a terminal and read the fatal: message
Check for and remove stale .lock files
Verify remote URLs with git remote -v
Test authentication with ssh -T or git ls-remote
Run git fsck to check repository integrity
Compare TortoiseGit's Git/SSH paths against your terminal's
Re-clone as a last resort (only after backing up local work)

Common Pitfalls

Debugging through the TortoiseGit dialog instead of reproducing the error in a terminal. The GUI hides the actual fatal: message that contains the diagnosis.
Deleting .lock files while another Git process is still running. This can corrupt the repository index. Check Task Manager first.
Assuming exit code 128 is a TortoiseGit-specific bug. It is a standard Git fatal error code. TortoiseGit is only the messenger.
Re-cloning as the first troubleshooting step. This hides the root cause (expired token, bad SSH config, wrong remote URL) and the problem will recur.
Using TortoisePlink with OpenSSH-format keys. Either convert your keys with PuTTYgen or switch TortoiseGit's SSH client to ssh.exe from Git for Windows.
Forgetting that Windows paths are case-insensitive but Git internals are not. A repository cloned on Linux with files differing only in case can cause fatal errors on Windows.

Summary

Exit code 128 is Git's generic fatal error code. The actual cause is in the fatal: message, which TortoiseGit often truncates.
Always reproduce the error in a terminal first to see the full message.
The most common causes are stale lock files, expired credentials, wrong remote URLs, and mismatched Git/SSH tool paths between TortoiseGit and the terminal.
Work through causes systematically: terminal reproduction, lock files, remote URL, authentication, repository integrity, tool configuration.
Re-cloning should be the last resort, not the first step, because it hides the underlying problem.