Can I See Who Forked My GitHub Repo
Yes, you can view every public account that makes a copy of your project. Many developers ask can i see who forked my github repo when they share code. The platform tracks every fork created through its built-in button. You can check the repo network list or query the platform API to see the owners. How can i see who forked my github repo in practice A fork is a server-side copy of a repo under another user account. The platform keeps a database link between the source project and the new co
GitHub Actions Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Yes, you can view every public account that makes a copy of your project. Many developers ask can i see who forked my github repo when they share code.
The platform tracks every fork created through its built-in button. You can check the repo network list or query the platform API to see the owners.
How can i see who forked my github repo in practice
A fork is a server-side copy of a repo under another user account. The platform keeps a database link between the source project and the new copy.
This link powers the fork counter at the top of your project page. Anyone with read permissions on the project can open that list.
The view shows the username and repo name for each direct copy. It also displays copies made from those copies in a tree view.
Engineers and AI agents can also fetch this data through the platform API. An agent sends a read request to the forks endpoint for that project.
The response returns a list of user accounts, timestamps, and repo URLs. Teams use these automated checks to track community interest or audit internal code copies.
Still, this tracking only works when users click the fork button on the site. A user can clone your code to a local drive and push it elsewhere.
That manual copy breaks the platform link. Neither the web page nor the API will show a manual clone.
Why fork visibility matters for code and secret safety
Knowing who copied your project helps you manage both open source and private work. In a company account, admins set rules on where teams can fork private code.
When a developer forks a private project, permissions govern who can read that new copy. Static roles and repo rules control this initial copy action.
GitHub Actions Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Yet fork lists do not solve the problem of leaked secrets in your git history. If a developer commits an API key or database password, every fork gets that secret.
Deleting the secret in a new commit does not erase it from older forks. Anyone who forked the project before the fix still holds the old commit history.
AI coding agents make this risk grow faster. An agent might fork a repo to test a fix or run a build script.
If your project stores static keys in files, every forked copy spreads those keys further. Also, you might expose test data that holds real emails, phone numbers, or card numbers.
Once a fork exists, you cannot force the other owner to run your cleanup scripts. You must rotate the exposed credentials right away at the source system.
Limits of fork tracking vs active session control
Repo roles only check who can read or copy code at a single moment. They do not watch how an engineer or agent uses credentials inside an active session.
A user might copy a database script from a fork and run it on a laptop. Git permissions cannot stop a bad query once someone holds a raw database password.
Teams should keep live credentials and sensitive data out of code repos. Instead, you can control database and cloud sessions at the moment a command runs.
Data masking can also rewrite matched fields like national IDs or emails in query results. This keeps raw personal data out of local test files that someone might commit and fork.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can I see if someone clones my repository instead of forking it?
No, the platform does not show a public list of users who run a git clone. Repo owners only see basic traffic counts, not the specific user accounts that cloned the code.
What happens to forks if I delete or make my repository private?
If you delete a public repo or change it to private, existing public forks stay online. The platform picks one of the remaining copies to serve as the new root of the network.
Can I block users from forking my private repository?
Yes, admins can turn off forking for private repos in the project or team settings. For public repos, you cannot disable the fork feature because public code allows open copying.