Is there a way for an Open in Codespaces badge to automatically open the current repo instead of the upstream if the current repo is a fork?

[matthewruzzi]

🏷️ Discussion Type

Question

Body

Is there a way to make an "Open in GitHub Codespaces" badge in a repository readme that automatically opens the current repo instead of the upstream if the button is clicked from a fork?

[yhay81]

Not with a static Markdown badge today. The target URL has to identify a repository explicitly:

https://codespaces.new/OWNER/REPO-NAME

GitHub's documented variants (branch, PR, quickstart=1, configuration options) all build on that repository-qualified URL: https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/setting-up-your-repository/facilitating-quick-creation-and-resumption-of-codespaces#creating-a-link-to-the-codespace-creation-page-for-your-repository

A fork inherits the README contents literally. GitHub Markdown does not expose an OWNER/REPO template variable, and codespaces.new cannot infer “the repository whose README contained the link” after navigation. A repository-relative URL is not a workaround either; for example, /OWNER/REPO/codespaces/new is not a valid creation route.

There are two practical choices:

1. Keep the upstream-specific one-click badge, and add a short note for fork owners to replace OWNER/REPO-NAME in their fork.
2. Use the repository-neutral creation page:

[![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new)

That opens “Create a new codespace” with a repository picker. It does not automatically select the current fork, but it avoids silently opening the upstream repository and lets the user select their fork.

A redirect service could theoretically examine a query parameter, but the README still has no dynamic current-repository value to pass to it (and relying on the HTTP Referer header would be unreliable/privacy-dependent). An Action that rewrites the README in each fork is also not automatic because workflows in forks are not generally enabled and allowed to commit without action by the fork owner.

So if the requirement is both zero configuration in a fork and one click directly to that fork, the built-in badge/deep-link mechanism does not currently support it. The repository selector is the safest generic fallback.

[iawaisahmd]

I don't think this is currently possible either. The Codespaces deep link requires a specific OWNER/REPO (or falls back to the generic repository picker), and GitHub doesn't expose any Markdown variable that resolves to "the repository currently displaying this README." Because of that, a README in a fork can't automatically rewrite the link to point at itself.

If GitHub ever introduced repository-context variables (similar to templating) or supported relative Codespaces creation URLs, this would become possible. As things stand today, using https://codespaces.new (repository picker) is the closest generic solution when you want the same README to work correctly in both the upstream repository and all forks.

[iawaisahmd]

As far as I know, no. The Open in GitHub Codespaces badge/link is tied to the repository that the README is being rendered from, but GitHub doesn't currently provide a parameter or mechanism that says "if this repository is a fork, open the fork instead of the upstream."

If someone is viewing the fork's README, the button will open a Codespace for the fork. However, if they're viewing the upstream repository, GitHub has no way to infer which fork they intend to use, so it will open the upstream repository.

If your goal is for contributors to work in their own forks, the usual approach is to document that workflow (fork first, then open a Codespace from the fork) rather than relying on the badge to redirect automatically.

If anyone knows of a hidden URL parameter or a recent feature that changes this behavior, I'd be interested as well, but I don't believe GitHub currently supports it.