Add the ability to detect what host the codespace is currently running in.

[jongio]

When developing an application that runs in the terminal like a cli or a script, we need to know if the codespace is running in the browser in vs code connected to a codespace or in a dev container.

One possible solution would be to set an environment variable, something like CODESPACES_HOST and set that to either browser, vs code, code spaces or vs code dev container.

[bamurtaugh]

cc @joshspicer - I wasn't sure where this request would fit best, so started here and would love to get your thoughts.

[joshspicer]

All Codespaces should have a $CODESPACES env variable set. It won't however discriminate the kind of client you're connected to (web vs. desktop client).

@joshspicer ➜ /workspaces/repo (main) $ echo $CODESPACES
true

What is your use case?

[jiasli]

This issue is derived from Azure/azure-cli#20315. We want to have different behaviors for Azure CLI's authentication in Codepsace.

We need to know whether Codespace is connected via a local VS Code desktop application or a browser. This is because

1. In a local VS Code desktop application, the port forwarding feature maps localhost on the remote container as 127.0.0.1 on the local machine. This allows the auth code flow to work as expected, as the auth code was sent to localhost (127.0.0.1), thus to the Codespace.
2. But in the browser, the localhost on the remote container is mapped as https://CODESPACENAME-PORT.app.github.dev. As explained in az login does not work in GitHub Codespaces Azure/azure-cli#20315 (comment), a random redirect URI is disallowed by Entra.

Once we have this informaiton, Azure CLI can

1. Use auth code flow in a local VS Code desktop application
2. Use device code flow in a browser

[mitchdenny]

I'd like to pile onto @jongio's request.

I'm currently working on improving .NET Aspire's support for VSCode/Codespaces and various other remote dev scenarios. I would like the ability to distinguish whether the shell is running locally on a desktop or in Codespaces as well.

I'm already using the CODESPACE environment variable to enable translating Aspire dashboard URLs to the *.app.github.dev URLs, but if the Codespace front end is a local VSCode install then knowing this would be good to know so we can opt out of this behavior and use the localhost port forwarded addresses in preference.

Here is the PR on the Aspire side where I am doing the devcontainer setup:

microsoft/aspire#6491

[jongio]

@joshspicer - Those are the scenarios. Any questions? Thanks

[joshspicer]

It sounds like this is a feature request that would need to be implemented by the Codespaces team to differentiate between the different clients that can be used with that product.

For all other remote scenarios except the Codespaces web client experience (like using the VS Code Dev Containers extension) a familiar localhost address is available when port forwarding.

[jongio]

@bamurtaugh - Do you think we should open an issue in a codespaces repo?

[bamurtaugh]

Makes sense to me, to open one in https://github.com/orgs/community/discussions/categories/codespaces and close this out.

[joshspicer]

One of the challenges from the codespace side is that you're able to be connected to a single codespace from various clients (so embedding that information into the container with something like an envariable variable wouldn't be reliable).

If your project that needs to discern whether the port is forwarded on localhost or via a tunnel, could you probe that URL (perhaps with a HEAD request) first?

[~]$ curl --head https://squalid-spooky-toad-4dd66j54977hx87-8000.app.github.dev/
HTTP/2 200
date: Thu, 31 Oct 2024 18:24:30 GMT
content-type: text/html; charset=utf-8
content-length: 421
cache-control: no-cache,no-store
expires: Thu, 01 Jan 1970 00:00:00 GMT
pragma: no-cache
x-content-type-options: nosniff
...
x-ms-ratelimit-used: 1
x-ms-ratelimit-reset:
vssaas-request-id: dfdfe254-3e7c-49d9-a6c2-98737d2a04ad
strict-transport-security: max-age=31536000; includeSubDomains
x-served-by: tunnels-prod-rel-usw3-v3-cluster
x-robots-tag: noindex, nofollow
referrer-policy: same-origin

and change your behavior according to what the HEAD request returns?

You can craft that URL with environment variables within the codespace (if you know the port). Something like:

export PORT=8000
https://${CODESPACE_NAME}-${PORT}.${GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN}

[jongio]

@jiasli thoughts?