Repository-level Codespaces secret existed in settings but was missing from the environment until recreated

[AmigoColombiano]

🏷️ Discussion Type

Bug

Body

Title: Repository-level Codespaces secret existed in settings but was missing from the environment until recreated

Product: GitHub Codespaces
Repository type: Personal repository

Description

I encountered an issue with a repository-level Codespaces secret named GROQ_API_KEY.

The secret was listed under the repository's Settings → Secrets and variables → Codespaces page, and GitHub showed it as recently updated. However, after stopping and restarting the existing Codespace, the environment variable was still absent from the terminal.

I verified that:

• The Codespace was connected to the expected repository.
• Another repository-level Codespaces secret, PROYECTO_ABRAXAS, was available in the terminal.
• The shell was Bash, and the shell startup files checked contained no references to GROQ_API_KEY.
• No secret values were printed or exposed during these checks.

I then deleted and recreated the GROQ_API_KEY repository secret, stopped the Codespace, and reopened it. After that, the environment variable was present in the terminal.

Expected behavior

A repository-level Codespaces secret should become available in the Codespace environment after the documented refresh/restart procedure.

Observed behavior

The secret appeared in repository settings but was initially absent from the environment. Recreating the secret appears to have resolved the issue.

Question

Could this indicate a transient issue or stale configuration affecting the delivery of a Codespaces secret? Are there logs or diagnostic steps that could help establish why the original secret was not available?

I have not established the root cause and am reporting the observed behavior for investigation.

No secret values are included in this report.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[anis-mselmi]

A Codespaces secret is injected when the Codespace is created or restarted, but a secret can be stale in an already-running environment if its configuration changed or the refresh did not complete. Since recreating the secret fixed it, this points to stale provisioning state, but the report alone cannot establish the root cause. For diagnosis, compare the secret name and repository/organization scope, confirm the Codespace was fully stopped and reopened (not just the editor reloaded), and check whether a newly created Codespace receives it. GitHub Support may need the Codespace name, repository, timestamps, and Codespaces logs; never include the secret value in a public report.

[slyyr]

One useful distinction here is that a secret being visible in repository settings doesn't necessarily prove that an already-running Codespace has received the latest configuration.

I'd check a few things before concluding that the original secret was corrupted:

1. Confirm that the Codespace belongs to the expected repository.
2. Check whether the secret is configured at the repository, organization, or user level.
3. Verify that the secret's availability policies allow it to be used by this repository.
4. Stop and recreate or reopen the Codespace, then check whether the environment variable is present.
5. If only one secret is missing while other secrets work, compare their configuration and availability settings.

You can check whether the variable exists without printing its value:

if [ -n "${GROQ_API_KEY:-}" ]; then echo "GROQ_API_KEY is set"; else echo "GROQ_API_KEY is missing"; fi

This avoids accidentally exposing the API key in terminal output or logs.

Since recreating the secret resolved the symptom, I'd record that as a workaround, but I wouldn't assume it proves the root cause. A transient configuration or secret-delivery issue remains possible.

If the problem recurs, recording the Codespace creation/restart time and whether other secrets are available would help narrow down the failure.