Gitエラーコード128の原因と対処法｜fatal症状別の解決手順

Gitで git push や git clone、git pull などを実行した際、ターミナルに fatal: ... というエラーメッセージと共に出力される exit code 128（エラーコード128）。

CI/CDパイプライン（GitHub Actionsなど）やスクリプトでGitを自動実行している現場では、「Process completed with exit code 128.」というログだけが表示され、何が原因で停止したのか一目で分からず困惑するケースが少なくありません。

結論から言うと、Gitのエラーコード128は特定の1つの不具合を指す番号ではなく、「致命的なエラー（fatal error）が発生し、Gitプロセスが処理を途中で中断した」ことを示す汎用的な終了ステータスです。

認証失敗、WSL2やDocker共有ディレクトリの所有権不一致、残留した .git/index.lock ファイル、プロキシの接続遮断など、発生要因は多岐にわたります。

この記事では、Gitでエラーコード128が発生する代表的な原因と、エラーメッセージ別の具体的な解決手順を早見表付きで詳しく解説します。

この記事で行うこと
前提条件・対象読者
1. Gitエラーコード128の症状別早見表
2. 認証失敗・権限エラーによるexit code 128
1. Personal Access Token（PAT）の期限切れと再設定
2. SSH接続のPermission denied（publickey）
3. WSL2・Docker環境の「dubious ownership」エラー
1. 原因：Git 2.35.2以降のセキュリティ保護機能
2. 対処法：safe.directoryの設定
4. index.lockファイルの残留によるexit code 128
1. 原因：多重書き込み防止ロックの残留
2. 対処法：ロックファイルの安全な削除
5. プロキシ・ネットワーク接続遮断によるexit code 128
1. プロキシ設定の確認と更新
6. 詳細ログ（GIT_TRACE）で真因を特定する手法
7. よくある質問（FAQ）
1. Q1. GitHub Actionsで actions/checkout 実行時に exit code 128 が出ます。
2. Q2. fatal: not a git repository (or any of the parent directories): .git と出て128になります。
まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

exit code 128 の直前に出力される fatal: メッセージから原因を即座に特定します
HTTPSトークン（PAT）期限切れやSSH鍵エラーによる認証失敗を解決します
WSL2やDocker環境で多発する detected dubious ownership エラーを safe.directory で解消します
異常終了後に残った .git/index.lock ファイルを安全に削除して復旧します
原因が分からない場合に GIT_TRACE=1 と GIT_CURL_VERBOSE=1 で真因を特定する手順を学びます

前提条件・対象読者

対象環境：Windows 11 / Windows 10（PowerShell / Git Bash）、macOS、Linux、WSL2（Ubuntu）、Dockerコンテナ環境
対象バージョン：Git 2.35.2以降（safe.directory 導入以降の現行バージョン、最終確認：2026年11月）
バージョン確認コマンド：git --version

1. Gitエラーコード128の症状別早見表

エラーコード128が発生した時は、終了コードそのものではなく、直前に出力されている fatal: から始まるメッセージを確認することが最速の解決ルートです。

fatalエラーメッセージ	主な発生原因	即効解決コマンド・対処法
`Authentication failed for ...`	トークン期限切れ・パスワード誤り	PAT再発行または古い資格情報の削除
`Permission denied (publickey)`	SSH鍵の未登録・権限不一致	`ssh-add ~/.ssh/id_ed25519` またはSSH鍵再登録
`detected dubious ownership in repository`	WSL/Docker間の所有者不一致	`git config --global --add safe.directory "<パス>"`
`Unable to create '.../.git/index.lock': File exists`	前回処理の中断によるロック残留	プロセス確認後に `rm -f .git/index.lock` 実行
`Could not resolve host: github.com`	DNS解決失敗・ネットワーク切断	DNS設定見直し・VPN切断確認
`Failed to connect to ... Connection refused`	社内プロキシ設定の不一致	`git config --global http.proxy <URL>` 設定確認
`not a git repository (or any of the parent...)`	作業ディレクトリの誤り・未初期化	正しいリポジトリへ移動または `git init` 実行

2. 認証失敗・権限エラーによるexit code 128

最も発生頻度が高いのが、リモートリポジトリ（GitHub、GitLabなど）へのアクセス認証に失敗するケースです。

Personal Access Token（PAT）の期限切れと再設定

GitHubではパスワード認証が廃止されており、HTTPS通信時はパーソナルアクセストークン（PAT）またはGitHub CLI認証が必須です。トークンの有効期限が切れると認証に失敗して終了コード128で停止します。

キャッシュされた古い認証情報を一度削除し、新しいトークンで再認証します。

WindowsのPowerShell環境で保存済みのGitHub資格情報を削除する手順：

# Windowsの資格情報マネージャーからGitHubのキャッシュを削除する
cmdkey /delete:git:https://github.com

また、OSを問わずGit標準の git credential reject を使ってキャッシュを消去する場合は、以下のように実行します（Linux / macOS / Git Bash / WSL）：

# 標準入力からプロトコルとホストを渡して認証キャッシュを消去
printf "protocol=https\nhost=github.com\n\n" | git credential reject

またはWindowsのスタートメニューから「資格情報マネージャー」を開き、「Windows資格情報」内の git:https://github.com を削除してから再度 git push を実行すると、新しい認証情報の入力画面が表示されます。

SSH接続のPermission denied（publickey）

SSHプロトコルで接続している場合に、公開鍵の登録漏れや秘密鍵のパーミッション不備があると発生します。

まずは現在のSSH接続状況をテストします。

# GitHubへのSSH接続確認
ssh -T git@github.com

Hi username! You've successfully authenticated... と表示されない場合は、SSHエージェントに秘密鍵が登録されていない可能性があります。

# ssh-agentを起動して秘密鍵を登録
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

SSH鍵の新規作成やGitHubへの公開鍵登録手順の詳細は、GitHubにSSH接続する公開鍵の作成・登録手順と接続テスト方法で詳しく解説しています。

3. WSL2・Docker環境の「dubious ownership」エラー

Windows上のWSL2環境やVS Code Dev Containers、Dockerコンテナ内でGit操作を行った際、以下のようなエラーメッセージと共に exit code 128 が発生することがあります。

fatal: detected dubious ownership in repository at '/mnt/c/Users/user/project'
To add an exception for this directory, call:
    git config --global --add safe.directory /mnt/c/Users/user/project

原因：Git 2.35.2以降のセキュリティ保護機能

このエラーはGitのセキュリティ脆弱性（CVE-2022-24765）対策として導入された安全装置です。

リポジトリディレクトリの所有者（UID）と、現在コマンドを実行しているユーザーのUIDが一致しない場合、悪意ある .git/config ファイルの読み込みを防ぐためにGitが処理を拒否します。

Windows側のドライブ（/mnt/c/...）をWSLからマウントして参照している場合や、DockerのバインドマウントでホストとコンテナのUIDが異なる場合に頻発します。

対処法：safe.directoryの設定

エラーメッセージで案内されている通り、該当リポジトリを安全なディレクトリとして例外登録します。

特定のリポジトリのみ許可する場合：

git config --global --add safe.directory /mnt/c/Users/user/project

WSLやローカル開発コンテナ内の全ディレクトリを対象に一括許可する場合（信頼できる個人開発環境のみ推奨）：

git config --global --add safe.directory "*"

この設定により、~/.gitconfig に例外ルールが追記され、所有者の差異によるエラーが解消されます。

4. index.lockファイルの残留によるexit code 128

Gitでコミットやブランチ切り替えを行っている最中にターミナルを強制終了したり、エディタがクラッシュしたりすると、以下のエラーが発生して以降のGit操作が受け付けられなくなります。

fatal: Unable to create '/path/to/project/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed before: remove the file manually to continue.

原因：多重書き込み防止ロックの残留

Gitはインデックス（ステージング情報）を更新する際、複数のGitプロセスが同時に書き込んでデータが破損するのを防ぐために .git/index.lock という一時ロックファイルを作成します。通常は処理完了時に自動削除されますが、処理が異常中断されるとロックファイルだけがディスクに残ってしまいます。

対処法：ロックファイルの安全な削除

まずは裏で別のGitプロセス（VS Codeのバックグラウンド同期や別ウィンドウの git commit 等）が実行中でないか確認します。

他のGitプロセスが動いていないことを確認したら、残ってしまった .git/index.lock を手動で削除します。

Linux / macOS / WSL環境：

# プロジェクトルートでロックファイルを削除
rm -f .git/index.lock

Windows PowerShell環境：

# プロジェクトルートでロックファイルを削除
Remove-Item -Force .git\index.lock

ロックファイルを削除すれば、すぐに通常のGitコマンドが実行できるようになります。

5. プロキシ・ネットワーク接続遮断によるexit code 128

企業のイントラネット環境やVPN接続時に多いのが、ネットワーク到達不能によるエラーです。

fatal: unable to access 'https://github.com/...': Failed to connect to github.com port 443: Connection refused

または

fatal: unable to access 'https://github.com/...': Could not resolve host: github.com

プロキシ設定の確認と更新

社内ネットワークで指定のプロキシサーバーを経由する必要がある場合、Gitのプロキシ設定が未構成だと通信が拒否されます。

# HTTPおよびHTTPSプロキシを設定する
git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080

逆に、テレワークや自宅Wi-Fiに切り替えたにもかかわらず社内プロキシ設定が残っている場合も接続エラーになります。プロキシ不要のネットワークへ移動した際は設定を解除してください。

# プロキシ設定を解除する
git config --global --unset http.proxy
git config --global --unset https.proxy

DNSの名前解決エラーへの対処法は、GitHubでclone時にCould not resolve hostエラーが出た場合の対処法でも詳しく解説しています。

6. 詳細ログ（GIT_TRACE）で真因を特定する手法

エラーメッセージが短すぎて原因が特定できない場合や、CI/CD環境で exit code 128 だけが表示される場合は、Gitの詳細トレースログを有効化して実行するのが確実です。

Gitには環境変数を指定することで内部処理やHTTP通信ログを出力する機能が備わっています。

Linux / macOS / WSL環境での詳細ログ出力：

# 詳細トレースとcURL通信ログを同時に出力しながら実行
GIT_TRACE=1 GIT_CURL_VERBOSE=1 git push origin main

Windows PowerShell環境での詳細ログ出力：

# PowerShellで環境変数を一時設定して実行
$env:GIT_TRACE = "1"
$env:GIT_CURL_VERBOSE = "1"
git push origin main

# 確認後に環境変数をクリア
Remove-Item Env:\GIT_TRACE
Remove-Item Env:\GIT_CURL_VERBOSE

このコマンドを実行すると、Gitがどの設定ファイルを読み込み、どのURLへリクエストを送り、どのHTTPステータスコード（401 Unauthorized、403 Forbidden、407 Proxy Authentication Required など）で拒否されたかがターミナル上に表示されます。

7. よくある質問（FAQ）

Q1. GitHub Actionsで actions/checkout 実行時に exit code 128 が出ます。

プライベートリポジトリやサブモジュール（Submodules）をチェックアウトする際、デフォルトの GITHUB_TOKEN では別リポジトリへのアクセス権限が不足しているケースが大半です。リポジトリへの読み取り権限を持つPersonal Access Token（PAT）またはGitHub Appトークンを secrets に登録し、with: token: ${{ secrets.MY_PAT }} を指定してください。