Antigravity の Agent から git push したら permission denied になるときの切り分けと恒久対策

エージェントに丸ごと任せたコード修正がきれいに通り、テストも緑、コミットメッセージまで気の利いた一文を書いてくれて、いざ最後の git push ……というところで真っ赤な remote: Permission to masakihirokawa/xxx.git denied to other-account を見た瞬間の脱力感は、Antigravity を日常的に使っている方なら一度は味わったことがあると思います。2014年から個人で iOS/Android アプリを運営してきて累計5,000万DL に育ったメインの AdMob 収益アプリ群と、現在は別軸で 4 つのブログサイトを並行運用していて、それぞれにアカウント別の Personal Access Token を割り当てています。そのため廣川（masakihirokawa）はこの種の認証エラーには何度も足を取られてきました。

このエラーはネットワーク的にはサーバーまで届いていて、単にエージェントが渡している資格情報が間違っているだけ、ということがほとんどです。とはいえ Antigravity でエージェントを使った作業フローには、通常の手作業よりも認証情報が「ねじれる」きっかけが多く、原因が複層的に絡まりやすいのも事実です。本稿は、廣川が現場で使っている切り分けの順番と、そのまま再発させないための恒久対策の備忘録です。

まず、エラーメッセージから「どこで詰まっているか」を3秒で特定する

git push が失敗したときに最初にやるべきは、エラーメッセージの一行を読み分けることです。Antigravity のターミナルで赤く出た文字列を、まずは大きく3つに分類します。

• remote: Permission to {owner}/{repo}.git denied to {user}: サーバーまで通信が届いて、相手のアカウントは判別できているが、書き込み権限を持っていないアカウントとして認識されている
• fatal: Authentication failed for 'https://github.com/...': 資格情報が空、または無効。PAT の期限切れ・スコープ不足・タイポなどでサーバー側に拒否されている
• fatal: unable to access ... Could not resolve host / Connection timed out: そもそもネットワーク層で届いていありません。プロキシや VPN を疑う

最初の Permission to ... denied to ... が一番厄介で、Antigravity 環境で特に起きやすいパターンです。ここから先は、このメッセージが出たケースを中心に解説します。

エージェントが「誰として」push しようとしているかを把握する

エージェントは指示された作業に集中していて、自分が今どのアカウント・どの資格情報で push しようとしているかには無頓着です。まずは、現在のリポジトリでどの認証情報が選ばれているかを淡々と確認します。

# 1. リモート URL を確認（HTTPS か SSH か、所有者は誰か）
git remote -v
 
# 2. credential.helper の設定を確認（macOS なら osxkeychain か manager-core か）
git config --get credential.helper
git config --list --show-origin | grep -i credential
 
# 3. macOS Keychain に保存されている GitHub の資格情報を確認
security find-internet-password -s github.com -g 2>&1 | grep "acct\|svce"

この3つで「今このリポジトリは HTTPS で masakihirokawa/xxx.git に対して、Keychain の acct=other-account に保存された PAT を使って push しようとしている」というような状態が見えてきます。acct= の値と、リポジトリの所有者が一致していなければ、その瞬間に原因が確定します。

ちなみに、4サイト並行運用のように同じ GitHub のホストに対して別のアカウントが入り混じる環境では、osxkeychain が「github.com に対しては一つの資格情報」と勘違いしがちです。私の経験上、認証エラーの 7〜8 割はこの「Keychain に古いアカウントの PAT が居座っている」ケースでした。

アカウントごとに資格情報を分けるための3つの選択肢

原因が特定できたら、次は恒久対策です。複数アカウントが混ざる環境で、エージェントに毎回正しい資格情報を渡すには、私の知る限り次の3つのアプローチが現実的です。それぞれの向き不向きを整理します。

1. リモート URL に PAT を埋め込む（プロジェクト単位で完全に分離したい場合）

Antigravity でリポジトリごとに別 PAT を確実に使いたいなら、リモート URL 自体に資格情報を埋め込んでしまうのが最もシンプルです。

# 例: masakihirokawa アカウントの PAT を URL に埋め込む
git remote set-url origin https://masakihirokawa:ghp_xxxxxxxxxxxx@github.com/masakihirokawa/example.git
 
# 確認
git remote -v

利点は、credential.helper の設定や Keychain の中身に一切依存せず、リポジトリの設定だけで完結することです。エージェントがどんなターミナルを開いても同じ PAT が使われます。

欠点は、.git/config に PAT が平文で残ることです。リポジトリを誰かに共有する場合や、config ファイルをバックアップに含める運用をしている場合は危険なので避けてください。私は /tmp の作業用クローンや、絶対に共有しないローカル専用クローンに限ってこの方式を使っています。

2. URL ベースの credential helper キャッシュ（Keychain を活かしつつ複数アカウントを共存させたい場合）

osxkeychain をそのまま使いつつ、アカウントごとに別のエントリとして保存させる方法もあります。git config credential.{URL}.username を使うと、URL ごとに使うユーザー名を固定できます。

# masakihirokawa オーナーのリポジトリは masakihirokawa として保存・取得する
git config --global credential.https://github.com/masakihirokawa.username masakihirokawa
 
# other-account オーナーのリポジトリは other-account として
git config --global credential.https://github.com/other-account.username other-account

この設定を入れたうえで、各アカウントで一度ずつ push して、それぞれの Keychain エントリを作っておきます。以降は URL の所有者から自動的に正しい資格情報が引かれるようになります。

エージェントが新しいクローンを作っても、リモート URL のオーナー部分を見て自動で振り分けられるため、私のように /tmp/repos/{site} で都度 shallow clone するワークフローと相性が良いです。

3. SSH 鍵をアカウントごとに分け、~/.ssh/config で振り分ける（保守性を最優先したい場合）

HTTPS の PAT 管理に疲れたなら、SSH に寄せるのが最も保守性の高い選択です。アカウントごとに別の鍵を作り、~/.ssh/config でホスト名のエイリアスを切ります。

# ~/.ssh/config
Host github-masakihirokawa
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_masakihirokawa
  IdentitiesOnly yes
 
Host github-other-account
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_other_account
  IdentitiesOnly yes

リモート URL は git@github-masakihirokawa:masakihirokawa/example.git のようにエイリアス側を指すことで、鍵が確実に振り分けられます。PAT の期限切れに振り回されない点が地味に効いてきます。

ただし Antigravity のエージェントに「git clone するときはホスト名をエイリアスに書き換えてね」と毎回伝えるのは現実的ではないので、私は自動投稿パイプラインのような決まった所だけ SSH、それ以外は方式1か2を使い分けています。

エージェントに同じ罠を踏ませないための運用上の工夫

技術的な対策が決まったら、最後に「エージェントが何も知らない状態で作業を始めても、同じエラーを再発させない」ための運用面の整え方をご紹介します。

最初にやっておきたいのは、各リポジトリの AGENTS.md または .claude/AGENTS.md に、認証情報の扱いを一行で書いておくことです。たとえば「このリポジトリは https://masakihirokawa:${ENV_PAT}@github.com/... 形式でリモートが設定されている前提で動かしてください」と書いておくだけで、エージェントが余計な git remote set-url を試すのを抑止できます。

次に、PAT を環境変数として一元管理し、.env ではなく macOS のログインスクリプト（~/.zprofile 等）から読み込むようにしておくと、エージェントがコードベースの中を覗いても秘密が露出しません。私は _documents/_github_tokens/github_tokens.txt のような形でワークスペース内に保管し、参照する側は grep -A1 "サイト名" file | tail -1 で読むワークフローに統一しています。

最後に、git config --global push.default current を入れておくことをおすすめします。エージェントが git push origin main ではなく git push だけを叩いたときでも、現在のブランチに対して安全に push してくれるため、認証エラー以外の事故も減らせます。

それでも Permission denied が消えないときの最終チェック

ここまでの対策を入れたあとで再び Permission to ... denied to ... が出たら、最後に次の3点を確認します。

• PAT の有効期限と権限スコープ: GitHub の Settings → Developer settings → Personal access tokens で repo スコープが付いた状態で有効期限内かを確認する
• 組織の SSO 承認: 組織所有のリポジトリに push する場合、PAT を発行しただけでは足りず、Configure SSO → Authorize を済ませる必要がある
• Keychain の重複エントリ: 「キーチェーンアクセス」アプリで github.com を検索し、古い PAT を持つエントリを物理的に削除します。Keychain は同じ github.com に対して複数エントリを保持できるため、削除前後で security find-internet-password -s github.com を実行して差分を見ると確実です

この3つを潰しても解決しないケースは、私自身まだ遭遇していません。逆にここまでで原因が見つかったら、メモリに残しておくと次回以降のエージェント運用が一気に楽になります。

Antigravity のエージェントは強力ですが、認証まわりだけは人間が下地を整えてあげる必要があります。一度仕組みを作ってしまえば、その後は「push できなかったら諦めて手動で打ち直す」という時間泥棒から解放されます。同じ罠で時間を溶かしている方の参考になれば幸いです。