Public repository returns "Repository is disabled" for Git operations

[chaechan]

🏷️ Discussion Type

Question

Body

Hello,

I have administrator access to the following public repository:
https://github.com/chaechan/KBoard-wordpress-plugin

The repository is visible in the browser, and the REST API reports disabled=false, archived=false, and visibility=public. However, Git operations fail:

remote: Repository 'chaechan/KBoard-wordpress-plugin' is disabled.
remote: Please ask the owner to check their account.
fatal: unable to access 'https://github.com/chaechan/KBoard-wordpress-plugin.git/': The requested URL returned error: 403

I verified:

• the remote URL is correct
• the authenticated account has administrator/push permission
• HTTPS and GitHub CLI authentication were both tested
• the repository is not archived

Could you please check whether Git access or the repository's Git service is restricted on the backend and advise how to restore it?

Thank you.

[wellkilo]

The two signals are not contradictory. The REST disabled field describes the repository resource, but the Git smart-HTTP endpoint can also deny access because of an owner/account-level restriction. The exact server message — “Repository ... is disabled. Please ask the owner to check their account.” — is generated before normal Git authorization, so changing the remote URL, PAT, credential helper, or repository collaborator role will not repair it.

I can reproduce the public side of the state: repository metadata is readable and says disabled=false, while an anonymous git ls-remote https://github.com/chaechan/KBoard-wordpress-plugin.git receives the same 403 “repository is disabled” response. That rules out a local credential/cache problem and shows the Git service is blocking the repo independently of the visible REST flag.

Recommended recovery path:

1. The personal-account owner (chaechan), not a repository collaborator, should sign in and check the account banner, verified email, billing/payment, security notices, and https://github.com/settings/admin.
2. Check the owner's email for a GitHub Trust & Safety / Terms / billing notice and complete the requested action.
3. If no remediation banner exists, open a private GitHub Support ticket from the owner account and include the repository URL, exact UTC timestamp, request ID headers if available, and the fact that REST metadata says disabled=false while Git smart HTTP returns a disabled-repository 403.
4. Do not post private support emails, payment details, or identity documents in this public discussion.

An administrator on the repository is not necessarily the account owner and cannot clear an account-level restriction. The current API response also shows the querying identity has pull but not push/admin permission, so the owner needs to perform the escalation.

There is no safe repository setting or Git command that can re-enable a backend-disabled Git service. If GitHub Support restores the owner/repository, clone/fetch will resume without rewriting history. If this identifies the correct escalation path, please mark it as accepted.

[chaechan]

Update: I followed the recommended checks and completed the account-owner troubleshooting: verified email, 2FA, account/security settings, billing notices, repository settings, credential cleanup, and GitHub CLI authentication. The issue remains unchanged: REST reports disabled=false, while anonymous git ls-remote still returns the same 403 “Repository is disabled” response.

I also attempted to transfer the repository to the cosmosfarm organization as KBoard-wordpress, but the transfer page stayed on “Transferring repository…” and the new repository was not created.

The Community guidance did not resolve this. I opened GitHub Support ticket #4776759 and asked Support to check the backend/account-level Git smart-HTTP restriction.

[wellkilo]

Thanks for the follow-up — and for opening the ticket; that was the right call.

I re-checked the public state, and there is now a decisive signal that explains the whole picture:

1. The repository is locked on GitHub's side. The Fork button on chaechan/KBoard-wordpress-plugin is disabled with the tooltip "Cannot fork because chaechan/KBoard-wordpress-plugin is locked". A public repository never shows that because of its own settings, collaborator roles, or archive state.

2. The lock covers the whole fork network. A fork in the same network, e.g. Alghost/KBoard-wordpress-plugin, reports the same thing. So this is applied to the repository network on the backend, and it is not something that can be changed from Settings, credentials, or collaboration permissions.

3. The transfer never happened. https://github.com/cosmosfarm/KBoard-wordpress returns 404, and the source repository is still fully intact (branches, tags and releases are all present). Nothing is half-transferred and there is nothing to clean up — but re-trying the transfer while the repository is locked will most likely hang the same way.

So the limit of what this discussion can do has been reached: only GitHub staff can lift a locked/disabled state. No community member, setting, PAT, or Git command can do it — which is also why every owner-side check came back clean.

For ticket #4776759, I would add these points so it can be routed without another round of back-and-forth:

• The repository renders as locked in the UI (Fork button: "Cannot fork because chaechan/KBoard-wordpress-plugin is locked").
• The lock applies to forks in the network too (e.g. Alghost/KBoard-wordpress-plugin).
• Anonymous git ls-remote https://github.com/chaechan/KBoard-wordpress-plugin.git returns HTTP 403 "Repository is disabled. Please ask the owner to check their account."
• REST still reports disabled=false, archived=false, visibility=public — so the REST flag and the actual access state disagree.
• No account-level notice or remediation banner was found on the owner account.
• Impact: this is a public repository used as a distribution point for the KBoard WordPress plugin, and clone/fetch is unavailable to everyone, not just to the owner.
• Explicit questions: (a) is this an account-level restriction or a repository-level enforcement action? (b) what is the reason, and what is the appeal/reinstatement path? (c) if the repository is intentionally disabled, why does the REST API still report disabled=false?

While Support works through it:

• If you have a complete local clone (all branches and tags), keep it, and consider pushing it to a repository owned by an account/organization in good standing — e.g. the cosmosfarm organization — so downstream users of the plugin can fetch and build again. A local clone is the only reliable recovery path, since the Git service for this repository is blocked for everyone.
• Keep the ticket number, account notices, and any personal/billing details in the ticket rather than in this thread.

Please post Support's answer back here when you get it, even if it is only "account-level restriction confirmed" — that makes this thread useful for the next person who hits the same message.

[chaechan]

Update: The original repository remains locked for Git operations, so I created a public continuity repository under the official Cosmosfarm organization:

https://github.com/cosmosfarm/KBoard-wordpress

The master branch, feature branches, all 38 tags, and all 38 Releases are available there. The repository is intended to be the current distribution source while GitHub Support investigates the lock on chaechan/KBoard-wordpress-plugin. This discussion remains open because the original repository restriction is not resolved.

[chaechan]

Resolution update (2026-09-22 KST): GitHub Support confirmed that the repository lock was removed. I verified that anonymous git ls-remote and git fetch now succeed for https://github.com/chaechan/KBoard-wordpress-plugin.git, and pushed the previously blocked KBoard date/trash fix to master (a4d4e85..a9d835d). The original repository is usable again and is now the primary source. The Cosmosfarm continuity repository remains available as a mirror.

[chaechan]

Resolution update (2026-09-23 KST): GitHub Support has confirmed that the source repository lock was removed. The original repository is publicly accessible again.

For the still-unresolved same-name transfer, Support says there is no supported transfer into an existing repository with the same name (or a fork in the same network). I checked https://api.github.com/repos/cosmosfarm/KBoard-wordpress-plugin; it currently resolves to chaechan/KBoard-wordpress-plugin (repository ID 10930500). Anonymous git ls-remote to both the source and desired organization URLs returns the same master HEAD (44e6e1d). The desired organization URL currently resolves back to the original repository; I cannot verify a separate organization-owned target there.

I asked Support to confirm whether it sees a separate target repository object and to provide the supported way to transfer the original repository to the Cosmosfarm organization with the exact KBoard-wordpress-plugin name while preserving redirects. An alternate name or mirror is not the requested permanent result. The same-name transfer and URL-continuity issue remains open.