By Kedar Salunkhe | Last Updated: March 2026
You typed what felt like a perfectly normal Git command. Maybe it was a clone, maybe a push, maybe just a fetch. And instead of the usual progress output, you got hit with this:
remote: Repository not found.
fatal: repository 'https://github.com/USERNAME/REPO.git/' not foundOr this SSH version:
ERROR: Repository not found.
fatal: Could not read from remote repository.Please make sure you have the correct access rights
and the repository exists.
And now you’re staring at a screen, wondering whether the repository actually disappeared, whether you typed something wrong, whether your access got revoked, or whether something broke on GitHub’s end.
Here’s what most people do next: they refresh GitHub in the browser, see the repository sitting right there looking perfectly fine, and feel even more confused. The repository clearly exists — so why is Git saying it doesn’t?
The answer is almost never that the repository is actually missing. GitHub uses this same generic “Repository not found” message for at least half a dozen completely different problems — everything from a wrong URL to an authentication failure to a renamed repository. It’s one of the least helpful error messages in software development, and it catches developers at every experience level.
This guide cuts through all of that. It explains every real cause of the repository not found error, gives you a clear way to identify which one is happening in your situation, and walks you through the exact fix — step by step — for all seven of them.
Let’s get into it.
Repository Not Found Error in Git – 7 Quick Fixes (Step-by-Step Guide)
What Is the Repository Not Found Error?
The “Repository not found” error appears when Git tries to communicate with a remote repository and the server either can’t find it or won’t show it to you. The key word there is “won’t” — because GitHub intentionally uses the same “not found” message whether the repository genuinely doesn’t exist or whether it exists but you don’t have permission to see it.
This is a deliberate security decision. If GitHub returned “forbidden” for private repositories that exist, it would confirm to any random person on the internet that a specific private repository exists under a specific account — information the owner might not want public. So GitHub uses “not found” as a catch-all that covers both scenarios.
Here are all the variations of this error you might see:
HTTPS version:
remote: Repository not found.
fatal: repository 'https://github.com/USERNAME/REPO.git/' not foundSSH version:
ERROR: Repository not found.
fatal: Could not read from remote repository.Please make sure you have the correct access rights
and the repository exists.
During a clone:
fatal: repository 'https://github.com/USERNAME/REPO.git/' not found
Cloning into 'REPO'…
remote: Repository not found.During a push or fetch:
remote: Repository not found.
fatal: Could not read from remote repository.On GitLab:
remote: The project you were looking for could not be found or you don't have permission to view it.
fatal: repository 'https://gitlab.com/USERNAME/REPO.git/' not foundOn Bitbucket:
remote: Repository not found.
fatal: repository 'https://bitbucket.org/USERNAME/REPO.git/' not foundAll of these point to the same family of causes. Let’s walk through every one of them.
Why Does Git Say Repository Not Found?
There are seven common reasons this error appears. Understanding the full picture is important because the fix for one cause can make a completely different cause worse if applied blindly.
Reason 1 — Wrong Repository URL
The most common cause, and the easiest to fix. A typo in the repository name, a wrong username, an extra character, or a capitalization error in the URL is enough to send Git looking for something that doesn’t exist. Repository URLs are exact — git clone https://github.com/Username/Repo.git and git clone https://github.com/username/repo.git are different URLs, and only one of them will work.
Reason 2 — Authentication Failure Masquerading as Not Found
GitHub doesn’t differentiate between “this private repository doesn’t exist” and “this private repository exists but you’re not authenticated.” Both return “Repository not found.” If you’re not properly authenticated — wrong credentials, expired token, SSH key not loaded — any private repository will appear not found, even one you own.
This is the most counterintuitive cause. The repository is right there in your browser because you’re logged in. But Git is connecting unauthenticated (or with the wrong credentials), so GitHub treats the private repository as if it doesn’t exist.
Reason 3 — No Access to a Private Repository
Your authentication is working, but the account you’re authenticated as doesn’t have permission to access that specific repository. Maybe you were removed as a collaborator, maybe you haven’t been added yet, maybe you’re authenticated as a personal account trying to access an organization repository your account isn’t a member of.
Reason 4 — The Repository Was Renamed or Moved
GitHub does set up redirects when you rename a repository or transfer it to a different owner, but these redirects aren’t perfect across all Git clients and all scenarios. If someone renamed the repository after you set up your local remote URL, your push or fetch might be hitting the old URL which no longer resolves correctly.
Reason 5 — The Repository Was Deleted or Made Private
The repository might actually be gone. Or it was previously public (allowing unauthenticated access) and was changed to private. In both cases, without the right authentication and permissions, you get “Repository not found.”
Reason 6 — Wrong Remote URL Configured Locally
Your local Git repository has a remote URL stored in its config. If that URL is wrong — whether because of a manual typo when setting it up, a copy-paste error, or because you forked a repository and forgot to update the remote — every push, pull, and fetch will fail with repository not found.
Reason 7 — Organization or Team Access Issue
For repositories owned by a GitHub organization, access goes through organization membership and team assignments, not just individual collaborator settings. If your GitHub account isn’t a member of the organization, or if the repository’s team permissions were changed, you might lose access even if you can see the repository in your browser while logged in (because browser access and Git access can be granted differently).
Now let’s fix each one.
Fix 1 — Verify and Correct the Repository URL
Start here, regardless of which cause you suspect. A URL error is the most common and fastest to rule out, and catching it early saves you from chasing authentication or permission issues that don’t exist.
Step 1 — Check the URL You’re Using
If you’re running a clone command, look carefully at the URL you typed:
git clone https://github.com/USERNAME/REPO.gitCompare it character by character against the actual repository URL on GitHub. Things to check:
Correct GitHub username — not your local machine username, not your email, not someone else’s username. The exact GitHub account handle that owns the repository.
Correct repository name — GitHub repository names are case-sensitive. MyProject and myproject are different repositories.
Correct domain — github.com, not github.co, not gitbhub.com, not github.com.
Correct protocol — if you’re using SSH, the URL should look like git@github.com:USERNAME/REPO.git, not https://github.com/USERNAME/REPO.git.
.git suffix — some commands work without it, some don’t. Including it is always safe.
Step 2 — Check the Remote URL in an Existing Repository
If the error is happening during push, pull, or fetch (not a fresh clone), check what remote URL your local repository is pointing to:
git remote -v
This shows something like:
origin https://github.com/USERNAME/REPO.git (fetch)
origin https://github.com/USERNAME/REPO.git (push)Compare the URL shown against the actual repository URL. If there’s any difference, update the remote:
git remote set-url origin https://github.com/CORRECT-USERNAME/CORRECT-REPO.gitOr for SSH:
git remote set-url origin git@github.com:CORRECT-USERNAME/CORRECT-REPO.gitStep 3 — Copy the URL Directly From GitHub
Instead of typing the URL manually, go to the repository on GitHub and click the green Code button. Select either the HTTPS or SSH tab depending on your authentication method, and click the copy icon next to the URL. Paste it directly into your terminal. This eliminates any possibility of a manual typo.
Step 4 — Verify the Repository Exists on GitHub
Open the URL in your browser while logged into GitHub. If the repository page loads, it exists. If it shows a 404, the repository was deleted, renamed, or transferred. If it loads but shows a private repository page (with the lock icon), you can see it because you’re logged in — but Git needs separate authentication to access it.
Fix 2 — Fix Authentication to Resolve False “Not Found” Errors
This is the fix for the most confusing scenario: the repository exists, you can see it in your browser, but Git says it’s not found. Nine times out of ten this means Git is connecting without authentication (or with wrong credentials), and GitHub is hiding the private repository behind a “not found” response.
Step 1 — Check Which Authentication Method You’re Using
Look at your remote URL (git remote -v). If it starts with https://, you’re using HTTPS authentication. If it starts with git@, you’re using SSH.
For SSH Authentication — Verify Your Key Is Working
Run the SSH test command:
ssh -T git@github.com
If it returns:
Hi yourusername! You’ve successfully authenticated, but GitHub does not provide shell access.
Your SSH setup is fine and this isn’t the cause. Move to Fix 3.
If it returns “Permission denied (publickey),” your SSH key isn’t working. The full SSH key setup process is:
Check for existing keys:
ls -al ~/.ssh
Generate a new key if needed:
ssh-keygen -t ed25519 -C "you@example.com"
Start the agent and load the key:
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Copy the public key:
pbcopy < ~/.ssh/id_ed25519.pub (macOS)
xclip -sel clip < ~/.ssh/id_ed25519.pub (Linux)
clip < ~/.ssh/id_ed25519.pub (Windows Git Bash)Add the public key to GitHub → Settings → SSH and GPG keys → New SSH key.
Test again:
ssh -T git@github.com
For HTTPS Authentication — Check Your Token
Since August 2021, GitHub requires a personal access token instead of your account password for HTTPS Git operations. If you’re using your account password, GitHub rejects it and returns “Repository not found” for private repos.
Generate a token at GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic) → Generate new token.
Select the repo scope and generate the token. Copy it immediately.
Clear any stale cached credentials:
macOS:
git credential-osxkeychain erase
host=github.com
protocol=https
[press Enter twice]
Windows (Git Bash):
git credential reject
host=github.com
protocol=https
[press Enter twice]
Or on Windows, open Credential Manager and delete the github.com entry.
Retry your Git command and enter your GitHub username and the token (not your password) when prompted.
Step 2 — Verify You’re Authenticated as the Right Account
Even if authentication is working, you might be authenticated as the wrong GitHub account. This is common when you have multiple GitHub accounts (personal and work) with different SSH keys or different stored credentials.
For SSH, check which account your key authenticates as:
ssh -T git@github.com
The output will say “Hi USERNAME!” — make sure that username is the account that has access to the repository you’re trying to reach.
For HTTPS, check what credentials are stored in your OS credential manager and make sure they belong to the account with repository access.
Fix 3 — Get Access to a Private Repository
If your authentication is working correctly but you still get “Repository not found” for a private repository, your account genuinely doesn’t have access to it. This is an authorization problem, not an authentication problem.
Scenario A — You Need Collaborator Access
For a repository owned by an individual GitHub account, the owner needs to add you as a collaborator.
Ask the repository owner to go to:
Repository → Settings → Collaborators and teams → Add people
They search for your GitHub username and send an invitation. You’ll receive an email notification. Accept the invitation by clicking the link in the email, or go to github.com/notifications to find and accept pending invitations.
After accepting the invitation, retry your Git command.
Scenario B — You Need Organization Repository Access
For a repository owned by a GitHub organization, access works through organization membership and team assignments.
First, confirm you’re a member of the organization. Go to the organization’s page on GitHub. If you see “Request to join” rather than organization content, you’re not a member. Ask an organization admin to invite you.
If you’re already a member but still can’t access the repository, your account might not be on the team that has access to that specific repository. Ask an organization admin to add you to the relevant team, or to add your account directly to the repository’s collaborators.
If your organization uses SAML SSO and you’re using SSH, your SSH key also needs to be authorized for the organization:
Go to GitHub → Settings → SSH and GPG keys.
Find the key you’re using.
Click Authorize next to the organization name.
Complete the SSO authorization flow.
This step is separate from adding the key to your account and is easy to miss, especially when joining a new organization.
Scenario C — You Have a Pending Invitation You Haven’t Accepted
If someone added you to the repository recently and you haven’t accepted the invitation, you won’t have access yet. Check github.com/notifications for pending invitations or look for the invitation email.
Scenario D — You Were Removed From the Repository
If you previously had access but now don’t, you may have been removed as a collaborator, removed from the team, or removed from the organization. Contact the repository owner or organization admin to restore access.
Fix 4 — Fix a Renamed or Transferred Repository
GitHub creates redirects when a repository is renamed or transferred, but these redirects work reliably in browsers and not always reliably through Git over SSH. If someone renamed or transferred the repository after you set up your local remote URL, you might be hitting the old URL.
Step 1 — Find the Repository’s New URL
Go to GitHub and search for the repository by name. If you can find it (because you still have access), the URL in your browser is the current correct URL. Copy it.
Alternatively, ask the repository owner for the new URL.
Step 2 — Update Your Local Remote URL
git remote set-url origin https://github.com/NEW-OWNER/NEW-REPO-NAME.gitOr for SSH:
git remote set-url origin git@github.com:NEW-OWNER/NEW-REPO-NAME.gitVerify the update:
git remote -vStep 3 — Try Fetching or Pushing Again
git fetch origin
git push origin mainIf the repository was renamed but not transferred, GitHub’s redirect should have handled it. If updating the URL fixes it, keep the new URL — don’t rely on the redirect being permanent.
If the Repository Was Transferred to an Organization
When a repository moves from a personal account to an organization, the URL changes from:
to:
Update the remote URL accordingly:
git remote set-url origin https://github.com/ORGANIZATION-NAME/REPO.git
Fix 5 — Handle a Deleted or Newly Privatized Repository
Scenario A — The Repository Was Made Private
If a repository was previously public (accessible without authentication) and was recently set to private, unauthenticated Git connections will now get “Repository not found.” The fix is to set up proper authentication — either SSH keys or a personal access token — so Git can connect with credentials.
Follow Fix 2 in this guide to set up authentication. Once authenticated as an account that has access to the private repository, the “not found” error will resolve.
Scenario B — The Repository Was Deleted
If the repository was actually deleted, there’s no remote fix. You need to either:
Re-create the repository on GitHub and push your local code back up:
Go to github.com/new and create a new repository with the same name.
Update your local remote URL if it changed:
git remote set-url origin https://github.com/USERNAME/NEW-REPO.git
Push your existing local history:
git push -u origin mainOr recover the repository from a backup or a fork if one exists. GitHub does not offer a self-service repository recovery option for deleted repositories. If the deletion was accidental and recent, contact GitHub Support — they may be able to restore it, but this isn’t guaranteed.
Scenario C — The Repository Was Archived
Archived repositories on GitHub are read-only. You can still clone and fetch them, but pushing will fail. If your Git operation involves a push and the repository was recently archived, that’s the cause.
To check: go to the repository on GitHub. If it shows a yellow banner at the top saying “This repository has been archived,” it’s read-only.
The repository owner needs to unarchive it (Repository → Settings → scroll down → Unarchive) before you can push to it again.
Fix 6 — Fix the Wrong Remote URL in a Local Repository
Sometimes the problem isn’t with authentication or access at all — it’s that your local repository’s config has been pointing to the wrong URL from the beginning, or the URL got corrupted at some point.
This is particularly common when:
You cloned a fork and edited the remote URL manually, making a typo.
You copied a remote URL from somewhere and it included extra whitespace or characters.
The repository was renamed or transferred and you’ve been using an old URL.
You set up the remote with the wrong username or repository name.
Step 1 — Inspect Your Current Remote Configuration
git remote -v
Look at both the fetch and push URLs. Check them carefully against the actual URL of the repository on GitHub.
Step 2 — Inspect the Full Git Config
git config –list | grep remote
This shows all remote-related configuration. If you see anything unexpected — multiple remotes, duplicate entries, or unusual URLs — that’s where to focus.
You can also view the raw config file:
cat .git/config
Look for the [remote “origin”] section and inspect the url field directly.
Step 3 — Remove the Wrong Remote and Re-Add It
If the URL is clearly wrong, the cleanest approach is to remove the remote and add it back correctly:
git remote remove origin
git remote add origin https://github.com/CORRECT-USERNAME/CORRECT-REPO.git
Verify:
git remote -v
Or if you just need to update the URL without removing and re-adding:
git remote set-url origin https://github.com/CORRECT-USERNAME/CORRECT-REPO.git
Step 4 — Verify With a Fetch
$ git fetch origin
If this runs without errors, the remote URL is now correct.
Step 5 — Fix the Upstream Tracking Branch If Needed
If you removed and re-added the remote, your local branches might have lost their tracking relationship. Re-set the tracking branch:
git branch –set-upstream-to=origin/main main
Replace main with your branch name if it’s different.
Fix 7 — Fix Organization and Team Access Issues
Organization repositories have a more complex permission system than personal repositories, and the “Repository not found” error is especially common in organization contexts. This fix covers the organization-specific scenarios that aren’t fully addressed in Fix 3.
Step 1 — Confirm Your Organization Membership Is Active
Go to the organization’s page on GitHub (github.com/ORG-NAME). Look for your username in the member list. If you’re listed, you’re a member. If you’re not listed, you need an admin to invite you.
One important detail: GitHub organization invitations expire. If someone invited you weeks ago and you never accepted it, the invitation may have expired. Ask an admin to re-invite you.
Step 2 — Check Whether Your Membership Is Public or Private
GitHub organization memberships can be public or private. Even if you’re a confirmed member, if your membership is private, you might experience access issues in some contexts. To make your membership public:
Go to the organization page → People tab → find your username → click Make public.
Step 3 — Authorize Your SSH Key or Token for SAML SSO
If the organization uses SAML Single Sign-On (common in larger companies and enterprise accounts), your credentials need to be explicitly authorized for the organization, separate from your regular account access.
For SSH keys:
Go to GitHub → Settings → SSH and GPG keys.
Find the key you use for Git operations.
Click Configure SSO → Authorize → [Organization Name].
Complete the SAML authentication flow.
For personal access tokens:
Go to GitHub → Settings → Developer settings → Personal access tokens.
Find the token you use.
Click Configure SSO → Authorize → [Organization Name].
Complete the SAML authentication flow.Without this authorization step, your SSH key or token will work fine for your personal repositories but return “Repository not found” for every organization repository — even ones you can clearly access through the GitHub web interface.
Step 4 — Check Repository Visibility and Team Permissions
Even within an organization you’re a member of, individual repositories can be restricted to specific teams. Being a member of the organization doesn’t automatically grant access to every repository.
Ask an organization admin to check:
The repository’s Settings → Manage access — is your account or a team you’re in listed there?
Your team’s permissions for that repository — are you on a team that has been granted access?
If you’re supposed to have access and don’t, the admin can add you directly as a collaborator or add your team to the repository’s access list.
Step 5 — Check Organization-Level Base Permissions
Organizations have a base permission setting that applies to all repositories for all members. If base permissions are set to “No access,” members only get access to repositories they’re explicitly added to. An admin can check this at:
Organization → Settings → Member privileges → Base permissions
If this is set to “No access” and you haven’t been added to the specific repository, you won’t have access.
Real Terminal Example — Full Diagnostic Session
Here’s a complete session showing the error appearing across multiple scenarios, the diagnostic process, and the fix. This example covers the most common real-world case: a private repository where the authentication method is wrong.
$ git clone https://github.com/devcompany/private-project.git
Cloning into 'private-project'…
remote: Repository not found.
fatal: repository 'https://github.com/devcompany/private-project.git/' not found
[First instinct: check if URL is correct]
$ git ls-remote https://github.com/devcompany/private-project.git
remote: Repository not found.
fatal: repository 'https://github.com/devcompany/private-project.git/' not found
[URL is correct — repo exists in browser while logged in. Authentication must be the issue]
$ ssh -T git@github.com
git@github.com: Permission denied (publickey).
[SSH isn't set up — need to check credentials for HTTPS]
$ git config --global credential.helper
osxkeychain
[Using macOS Keychain — let's clear stale credentials]
$ git credential-osxkeychain erase
host=github.com
protocol=https[Generated a new Personal Access Token on GitHub with repo scope]
$ git clone https://github.com/devcompany/private-project.git
Cloning into 'private-project'…
Username for 'https://github.com': devuser
Password for 'https://devuser@github.com': [pasted token]
remote: Enumerating objects: 847, done.
remote: Counting objects: 100% (847/847), done.
remote: Compressing objects: 100% (412/412), done.
remote: Total 847 (delta 291), reused 832 (delta 278), pack-reused 0
Receiving objects: 100% (847/847), 2.14 MiB | 4.27 MiB/s, done.
Resolving deltas: 100% (291/291), done.
[Clone successful][Now setting up SSH to avoid this next time]
$ ssh-keygen -t ed25519 -C "dev@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/user/.ssh/id_ed25519
Your public key has been saved in /home/user/.ssh/id_ed25519.pub
$ eval "$(ssh-agent -s)"
Agent pid 19283
$ ssh-add ~/.ssh/id_ed25519
Identity added: /home/user/.ssh/id_ed25519 (dev@example.com)
$ pbcopy < ~/.ssh/id_ed25519.pub
[Pasted into GitHub Settings → SSH and GPG keys → New SSH key]
$ ssh -T git@github.com
Hi devuser! You've successfully authenticated, but GitHub does not provide shell access.
$ git remote set-url origin git@github.com:devcompany/private-project.git
[Switched existing repo from HTTPS to SSH]
$ git fetch origin
From github.com:devcompany/private-project
branch main -> FETCH_HEAD
[Everything working over SSH now — no more credential prompts]Prevention Tips — How to Stay Out of This Situation
The “Repository not found” error is fixable every time, but avoiding it is even better. These habits keep you from ever hitting it.
Tip 1 — Always Copy Repository URLs Directly From GitHub
Never type repository URLs by hand. Always go to the repository on GitHub, click the Code button, select your preferred protocol (SSH recommended for long-term use), and copy the URL using the copy icon. Paste it directly into your terminal. This eliminates the entire category of URL typo errors.
Tip 2 — Set Up SSH Authentication Once and Forget About It
HTTPS authentication requires token management — tokens expire, get stale in credential managers, and occasionally need to be regenerated. SSH key authentication, once properly configured with the ~/.ssh/config file set up with AddKeysToAgent yes, works indefinitely on the same machine without any maintenance. Set it up once:
Host github.com
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519And you’ll never see an authentication-caused “Repository not found” error again.
Tip 3 — Accept Collaboration Invitations Immediately
When someone adds you as a collaborator on a repository, accept the invitation right away. Invitations expire, and sitting on them creates a window where you think you have access but the invitation hasn’t been acted on yet. Get into the habit of checking github.com/notifications whenever you expect to have been given access to something.
Tip 4 — Verify Remote URLs When Cloning a Fork
When you fork a repository and then clone your fork, the clone URL should point to your fork (github.com/YOUR-USERNAME/REPO.git), not the original repository. Trying to push to the original when you only have fork access is a common source of “Repository not found” errors. Always double-check git remote -v after cloning to confirm the remote URL points where you expect.
Tip 5 — Update Remote URLs When Repositories Are Renamed or Transferred
If you’re a repository owner or maintainer, communicate to your collaborators whenever you rename or transfer a repository. Give them the new URL and the exact command to update their local remote:
git remote set-url origin https://github.com/NEW-OWNER/NEW-NAME.git
GitHub’s redirects work for a while, but they’re not guaranteed forever and don’t work in all SSH scenarios.
Tip 6 — For Organization Repositories, Always Authorize SSO Early
If your company uses GitHub with SAML SSO, authorize your SSH key and personal access token for the organization the moment you join. Don’t wait until you’re blocked in the middle of a task. Go to GitHub → Settings → SSH and GPG keys, find your key, and click Configure SSO → Authorize. Do the same for any access tokens you use.
Tip 7 — Use git ls-remote to Test Access Before Cloning
Before running a full git clone on a large repository you’re not sure you have access to, test with:
git ls-remote https://github.com/USERNAME/REPO.git
This contacts the remote and lists references without downloading anything. If it returns “Repository not found,” you know the issue is access or URL — not something that will surface halfway through a 2GB download. If it returns a list of refs (branches, tags), you have access and the clone will work.
Tip 8 — Keep Your GitHub Organization Memberships Current
If you leave a company or project and your GitHub organization membership gets revoked, you lose access to all private repositories under that organization. This is expected, but it can catch you off guard if you’re still working with a local clone of a repository you no longer have remote access to. Periodically review which organizations you’re a member of and which repositories you should still have access to.
FAQ
Q: The repository is right there on GitHub in my browser. Why does Git say it’s not found?
The most common reason is that you’re browsing GitHub while logged into your account, but Git is connecting without valid credentials (or with credentials for a different account). GitHub shows the repository to you in the browser because you’re logged in. Git, operating separately, doesn’t have your login session — it needs its own authentication. Set up SSH key authentication (Fix 2) or a personal access token and the “not found” error will resolve.
Q: Why does GitHub use “Repository not found” instead of “Access denied” or “Permission denied”?
This is intentional. If GitHub returned “Forbidden” or “Permission denied” for private repositories, it would confirm to any unauthenticated person that a specific private repository exists under a specific account. By returning “not found” for both genuinely missing repositories and inaccessible private ones, GitHub prevents information leakage about the existence of private repositories. It’s more secure, but also more confusing to debug.
Q: I own the repository. Why am I getting “Repository not found” when I try to push?
The most likely causes for a repository owner: your credentials are wrong or cached incorrectly (an expired token or a stale password in the OS credential manager), your remote URL has a typo (check git remote -v), or your SSH key isn’t loaded in the agent (run ssh -T git@github.com to check). If you can see the repository in your browser while logged in, the repository itself is fine — the problem is the credential chain between your terminal and GitHub.
Q: I forked a repository and now I get “Repository not found” when I push. Why?
When you fork a repository, your local clone’s remote URL should point to your fork (https://github.com/YOUR-USERNAME/REPO.git), not the original. If you cloned the original and are trying to push to it, you’ll get this error because you don’t have push access to someone else’s repository. Check git remote -v. If the remote URL shows the original repository owner’s username instead of yours, update it to point to your fork:
git remote set-url origin https://github.com/YOUR-USERNAME/REPO.gitQ: Can git ls-remote help diagnose this error?
Yes, and it’s one of the best diagnostic tools for this specific error. Run:
git ls-remote https://github.com/USERNAME/REPO.gitIf it returns a list of branches and tags, you have full access and the issue is something local (like a wrong remote URL in your repository config). If it returns “Repository not found,” the issue is authentication or permissions to that URL. It’s faster than a full clone attempt and gives you clean output without side effects.
Q: The repository was renamed by the owner. How do I update my local remote?
Get the new URL from the repository owner or by finding the repository on GitHub. Then update your local remote:
git remote set-url origin https://github.com/OWNER/NEW-REPO-NAME.gitOr for SSH:
git remote set-url origin git@github.com:OWNER/NEW-REPO-NAME.git
Verify with git remote -v and test with git fetch origin.
Q: I’m getting this error in a CI/CD pipeline. What’s usually the cause?
In CI/CD environments, the most common cause is missing or expired credentials. The runner starts fresh with no SSH agent, no cached credentials, and no stored tokens. For GitHub Actions, use the built-in actions/checkout with GITHUB_TOKEN or a repository secret containing a PAT. For other CI systems, configure an SSH deploy key or inject a personal access token as an environment variable and use it in the remote URL. Make sure any tokens or deploy keys haven’t expired. See Fix 2 for the credential setup commands.
Q: I added a collaborator to my repository but they still get “Repository not found.” What am I missing?
Check whether they’ve accepted the invitation. GitHub sends an email invitation and the collaborator must accept it before gaining access. Go to Repository → Settings → Collaborators and teams — if the invitation is still pending, it’ll show as “Pending” next to their username. They need to accept it from the email or from github.com/notifications. Also confirm they’re using the correct GitHub account — if they’re logged into a different GitHub account in their terminal’s credential manager than the one you invited, they’ll still get “not found.”
Q: What if the error only happens on push, not on fetch or pull?
If fetch and pull work but push returns “Repository not found,” you likely have read access but not write access. This is common when you’re a collaborator with read-only access, when you’re trying to push to a fork’s upstream, or when the repository was recently archived (archived repositories are read-only). Check your collaborator role in the repository settings, confirm you’re pushing to the right remote (your fork, not the upstream), and verify the repository isn’t archived.
Q: Does renaming my GitHub account affect repository access?
Yes. If you rename your GitHub account (change your username), all URLs containing your old username break — including remote URLs in local repositories and SSH config host aliases. GitHub sets up redirects for renamed accounts, but these aren’t reliable in all scenarios, especially over SSH. After renaming your account, update the remote URLs in all your local repositories and update any hardcoded URLs in CI/CD configurations, deployment scripts, and documentation.
Related Errors
These errors are closely related to “Repository not found” and often appear in the same troubleshooting session.
remote: Invalid username or password. / fatal: Authentication failed
The HTTPS cousin of the repository not found error. Where “Repository not found” appears for private repositories when authentication fails, “Authentication failed” appears when GitHub explicitly rejects the credentials. Both are fixed the same way — generating a valid personal access token and configuring your credential manager. The key difference: “Repository not found” can mean the repo doesn’t exist OR credentials are wrong, while “Authentication failed” definitively means credentials are wrong.
git@github.com: Permission denied (publickey)
The SSH version of an authentication failure. Your SSH key isn’t set up, isn’t loaded in the agent, or isn’t registered on GitHub. Fix it with ssh-keygen, ssh-add, and adding the public key to GitHub → Settings → SSH and GPG keys. Once SSH authentication works, “Repository not found” errors caused by authentication failures will resolve automatically.
error: The requested URL returned error: 403
A 403 means authentication worked but authorization failed — you’re known to the server but don’t have permission for this action. This is GitHub’s more explicit version of the authorization failure that “Repository not found” usually obscures. Fix it by checking your repository permissions and token scopes.
fatal: repository ‘https://…’ not found — after git init
If you run git push before connecting your local repository to a remote, Git might give a “not found” error because there’s no remote configured at all. Run git remote add origin YOUR-REPO-URL first, then push.
remote: Repository not found — on push after forking
Extremely common. You forked a repository, cloned it, and your remote still points to the original. You don’t have push access to the original. Update the remote to point to your fork:
git remote set-url origin https://github.com/YOUR-USERNAME/REPO.git
fatal: ‘origin’ does not appear to be a git repository
A local configuration error — no remote named “origin” is configured. Add it:
git remote add origin https://github.com/USERNAME/REPO.git
error: src refspec main does not match any
Appears when you try to push a branch that doesn’t exist locally. This happens when you initialize a new repository but haven’t made your first commit yet, so the main branch doesn’t exist. Make an initial commit first:
git add .
git commit -m “Initial commit”
git push -u origin main
Conclusion
The “Repository not found” error is one of Git’s most misleading messages — not because there’s anything wrong with Git, but because GitHub deliberately uses the same response for both missing repositories and inaccessible private ones. That single design decision turns what should be a simple “check your URL” problem into a debugging exercise that spans authentication, permissions, remote configuration, and organization membership.
The diagnostic path through this error is straightforward once you know it. Start with the URL (Fix 1) — confirm it’s correct by checking it character by character against GitHub and by running git ls-remote to test access. If the URL is right but the error persists, check authentication (Fix 2) using ssh -T git@github.com for SSH or by verifying your personal access token for HTTPS. If authentication is working but the repository is still not found, the issue is access (Fix 3 and Fix 7) — check collaborator status, pending invitations, and SSO authorization.
The remaining causes — renamed or transferred repositories (Fix 4), deleted or privatized repositories (Fix 5), and corrupted local remote configuration (Fix 6) — each have their own clear diagnostic step and clean fix.
The pattern across all seven fixes is the same: confirm the URL is right, confirm authentication is working, confirm access has been granted. Once all three are true, the repository will never be “not found” again.
If you’re still seeing the error after working through all seven fixes, run git ls-remote REPO-URL with verbose SSH output (GIT_SSH_COMMAND=”ssh -vvv” git ls-remote git@github.com:USERNAME/REPO.git) and read the output carefully. It logs every step of the connection attempt and will identify exactly where the process breaks down.
Related Resources
GitHub Docs — Troubleshooting cloning errors
GitHub Docs — Inviting collaborators to a personal repository
Github Blogs – This website contains huge collection of github related articles.
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.
If this guide saved you time, share it with a teammate — or bookmark it for the next time a repository suddenly “disappears.”