CODESPACE_NAME absent from non-interactive Codespaces SSH process

[delgcame]

🏷️ Discussion Type

Question

Body

In a GitHub Codespaces session reached with GitHub CLI 2.102.0, a non-interactive /bin/sh -s command ran a Python process whose single CODESPACE_NAME lookup returned absent. No command set or removed that variable. Your documentation lists CODESPACE_NAME as a default variable. Is it supported in this SSH execution path, and what supported, non-modifying method lets a command receive the actual provider-established value without supplying the expected name, sourcing unreviewed profiles or reading a full environment? Information only; no account access, remote changes or application-data inspection is requested. No identifiers, credentials, logs or attachments are provided.

[aditya-vermax]

CODESPACE_NAME is documented as a default environment variable, but I wonder if the non-interactive SSH execution path handles environment initialization differently.

Have you tried checking whether other default Codespaces variables are also missing in that same execution context? That might help narrow down whether this is specific to CODESPACE_NAME or an issue with how the SSH session inherits its environment.

[Tejas-Shivaji]

According to GitHub's documentation, CODESPACE_NAME is a default environment variable set for every Codespace. However, the documentation does not explicitly describe its propagation into non-interactive SSH command processes.

I would first isolate whether this is specific to the command execution path rather than Python itself.

For example, compare these two checks inside the same Codespace:

gh codespace ssh -c YOUR_CODESPACE_NAME

In the interactive session:

printenv CODESPACE_NAME

Then test the non-interactive path:

gh codespace ssh -c YOUR_CODESPACE_NAME -- 'printenv CODESPACE_NAME'

If the interactive session returns the value but the non-interactive command does not, that would be useful evidence of an environment propagation difference in the SSH execution path.

I would avoid sourcing shell profiles as a workaround because a provider-established environment variable should ideally be inherited by the process rather than reconstructed from user configuration.

If the difference is reproducible, I think it warrants a Codespaces issue with the exact CLI version and execution commands, since the documented default-variable behavior does not currently explain this discrepancy.