And since the issue you want to solve are the the movers from github.com to company.ghe.com, I'd just add "GH_TOKEN" and "GITHUB_TOKEN" to the list for everything not github.com, as then it's github enterprise as far as I understand?

I think the problem with that then becomes that we'd break all existing GitHub.com users who are not going to migrate, if I'm understanding that proposal correctly.

I think if we were to do anything like this, I think it might look something like a GH_GHEC_TOKEN that can override GH_TOKEN for company.ghe.com only.

Then you misunderstood my suggestion.
The complete solution would then be:
github.com: as today - GH_TOKEN. if not set. then GITHUB_TOKEN
Anything not github.com (i.e. Github Enterprise): - GH_ENTERPRISE_TOKEN. if not set, then GITHUB_ENTERPRISE_TOKEN, if not set, then GH_TOKEN, if not set, then GITHUB_TOKEN.
This is like dokumented, except Github enterprise fallback to GH_TOKEN and then to GITHUB_TOKEN.
With this, github.com will be as today.
Github Enterprise will be simpler to understand in the docs.
AND it solves customers moving from regular github.com to tenant.ghe.com that were already using GH_TOKEN or GITHUB_TOKEN in their actions.
What it don't solve is
people moving from tenant.ghe.com to regular github.com using only GH_ENTERPRISE_TOKEN.
But as your explaination for why it was like this, you only marked people moving from github.com -> ghe.com
So as for this code, change it more to like:

        // github.com and localhost should not return the enterprise token
        // as documented in the unit tests, but
        // whatever IsEnterprise (this is as is) and IsTenant should (this is new)
	if normalizedHost != github || normalizedHost != localhost {
		if token := os.Getenv(ghEnterpriseToken); token != "" {
			return token, ghEnterpriseToken
		}

		if token := os.Getenv(githubEnterpriseToken); token != "" {
			return token, githubEnterpriseToken
		}
	}
	// If we haven't already returned the token for GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN
	// for IsEnterprise or IsTenant above, OR it's none of those, i.e.
	if token := os.Getenv(ghToken); token != "" {
		return token, ghToken
	}

	if token := os.Getenv(githubToken); token != "" {
		return token, githubToken
	}

Now this satisfies every unit test here, except for the last one
If that is still a rule, that can be fixed by changing the last part to this:

        // the last unit test rule is important, then the second part of the code over should be inside this if clause
        // For github owned hosts, fallback to GH_TOKEN, then GITHUB_TOKEN
	if normalizedHost == github || IsTenancy(normalizedHost) || normalizedHost == localhost {
		if token := os.Getenv(ghToken); token != "" {
			return token, ghToken
		}

		if token := os.Getenv(githubToken); token != "" {
			return token, githubToken
		}
	} 

Now, I haven't tested the code I copied and pasted from your code and tried to change slightly to show how I would have solved your issue.
If you think the suggestion is OK, I'd be happy to do a PR to change the code and actually test it also.
Typically, I'd add unit tests for tenant.ghe.com to check that it would fallback to GH_TOKEN and then GITHUB_TOKEN and also add the GH_ENTERPRISE_TOKEN and GITHUB_ENTERPRISE_TOKEN to the last test ("given GH_TOKEN or GITHUB_TOKEN are set, when I get the token for any host not owned by GitHub, we do not get those tokens").

This suggestion solves:

• Everything in your unit tests
• moving from github.com -> tenant.ghe.com using GH_TOKEN or GITHUB_TOKEN
• moving from tenant.ghe.com -> github.com using GH_TOKEN or GITHUB_TOKEN

Current and suggested change does not solve:

• moving from tenant.ghe.com -> github.com using GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN
• moving from company.com -> github.com using GH_ENTERPRISE_TOKEN or GITHUB_ENTERPRISE_TOKEN

If there are other concerns, they're not in the tests or haven't been raised in the discussion so far.

Just to be clear @BagToad, my suggestion is to switch the fetching of tokens, so the enterprise tokens are checked before the regulare tokens.
That way, everything works as today and it will also allow for the enterprise tokens to be used for *.ghe.com hosts (which is actually logical).
It doesn't change anything for the ones that move from github.com to ghe.com using GH_TOKE, as if the *_ENTERPRISE_TOKEN is not set, we fallback to the regular GH_TOKEN/GITHUB_TOKEN.

And as I said, I'm happy to provide code + unit tests for this also.

Hey @escarls, apologies for the delayed reply.

Anything not github.com (i.e. Github Enterprise): - GH_ENTERPRISE_TOKEN. if not set, then GITHUB_ENTERPRISE_TOKEN, if not set, then GH_TOKEN, if not set, then GITHUB_TOKEN.

This is like dokumented, except Github enterprise fallback to GH_TOKEN and then to GITHUB_TOKEN.

Unfortunately we can't do something like this because sending GITHUB_TOKEN or GH_TOKEN to any host that is not GitHub.com or a GHEC tenant is a critical security issue. We have published security advisories in the past for this exact behavior in the past; we wouldn't reintroduce this security flaw intentionally.

There's also the simple reasoning that changing what token is used for what hosts is a dramatic change that affects every gh user that authenticates with env vars (certainly every user with gh in their CI).

Key point - GITHUB_TOKEN and GH_TOKEN is for GitHub controlled hosts.

That said, we've been discussing different implementations of additional env vars (non-breaking) to improve flexibility for env var authentication and we're thinking about this solution #12928 which is similar to a design that Hashicorp landed on in their CLI.

I think this will improve the situation with your original use-case:

So because of this, how can I create a setup, where I only have to set/unset GH_HOST to switch between work (ghe.com) and hobby projects (github.com)?

The reason for not wanting to use the "gh auth login" and create config, is that I'm mostly developing in devcontainers and then it's alot easier to just work with env variables for everything.

Hey @escarls, apologies for the delayed reply.

Anything not github.com (i.e. Github Enterprise): - GH_ENTERPRISE_TOKEN. if not set, then GITHUB_ENTERPRISE_TOKEN, if not set, then GH_TOKEN, if not set, then GITHUB_TOKEN.
This is like dokumented, except Github enterprise fallback to GH_TOKEN and then to GITHUB_TOKEN.
Unfortunately we can't do something like this because sending GITHUB_TOKEN or GH_TOKEN to any host that is not GitHub.com or a GHEC tenant is a critical security issue. We have published security advisories in the past for this exact behavior in the past; we wouldn't reintroduce this security flaw intentionally.

With my suggestion, it won't.
Do you mind if I show you with code?

It's soo much simpler for me to show you the code than trying to explain, as it seems whatever I say is not understood the way I mean.

There's also the simple reasoning that changing what token is used for what hosts is a dramatic change that affects every gh user that authenticates with env vars (certainly every user with gh in their CI).
Key point - GITHUB_TOKEN and GH_TOKEN is for GitHub controlled hosts.

This I agree with an will be satisfied in my suggested change.

That said, we've been discussing different implementations of additional env vars (non-breaking) to improve flexibility for env var authentication and we're thinking about this solution #12928 which is similar to a design that Hashicorp landed on in their CLI.
I think this will improve the situation with your original use-case:

Yeah, that is also a good solution, and it will solve more than 2 also.