GitHub/Codespace/Q/If devcontainer.json adds new Codespaces repository read permissions does an existing codespace get re-prompted or re-sync on rebuild

• In GitHub/Codespace I am prompted for read permissions when I create a codespace; if I download or merge an updated devcontainer that lists new read permissions for other repos, must I delete the codespace to go through authorization again, or is there a way to re-sync permissions from devcontainer.json without creating a new codespace?

• Answer

  • My Notes

    • My experience backs this up.

    • Follow-up question: is there any way to find out what permissions I have granted in my currently created codespace?

      • AI/Response
        • There is no documented first‑party way to print a full matrix of “repos × fine‑grained scopes” for the GITHUB_TOKEN inside a running codespace the way you might with classic PAT X-OAuth-Scopes headers. Official material explains classes of access (home repo read vs read/write, plus other repos if you authorized them) but not a listing API tied to the live VM token (Security in GitHub Codespaces — Authentication).
        • Closest REST helper: GET /repos/{owner}/{repo}/codespaces/permissions_check?ref=REF&devcontainer_path=PATH returns only {"accepted": true|false} — whether you have accepted the permissions declared in that devcontainer.json at that git ref for that repository. It answers “have I approved this config on this branch?” not “enumerate every scope on the token in my current shell” (Check if permissions defined by a devcontainer have been accepted by the authenticated user).
        • What people do in practice for this codespace: (1) read customizations.codespaces.repositories in the checked‑out .devcontainer / devcontainer.json and remember what you chose at creation time; (2) probe—call the REST API or gh repo view owner/other-repo using GITHUB_TOKEN and treat 403 on that resource as “not granted for that repo/permission”; (3) list codespaces via API/CLI for metadata (devcontainer_path, repository, branch) but expect no field that spells out token grants (the public codespace schema has no such property in GitHub’s OpenAPI).
        • Safety: do not paste GITHUB_TOKEN into chat or logs; if you experiment with JWT‑shaped tokens, decode locally only and avoid exfiltrating secrets.
  • AI/Response
    • You cannot re-sync the Codespaces-issued GITHUB_TOKEN extra-repo permissions onto an existing codespace by rebuilding. GitHub’s docs state explicitly that any custom permissions you add or change only apply to new codespaces created after those changes are committed, and that if you add or change permissions from inside a codespace, they do not apply to the current codespace—even if you rebuild the codespace (Managing access to other repositories within your codespace).
    • Authorization prompts: Permissions defined in devcontainer.json are reviewed when you create a codespace (or a prebuild configuration). GitHub remembers what you authorized and does not re-prompt unless the set of requested permissions in devcontainer.json changes—but satisfying that “changed set” still means creating a new codespace (or new prebuild flow), not refreshing the token on the VM you already have (same doc, “Authorizing requested permissions”).
    • You do not have to delete the old codespace if you only need a workspace with the new scopes: you can open a second codespace on the same repository/branch after the updated devcontainer.json is on the branch you use to create it. The old codespace keeps its old token; delete it only to save quota/cost or reduce clutter—not as a strict requirement for the prompt.
    • If you must stay in the same running codespace and cannot create a new one, the documented workaround is not “re-sync from devcontainer” but your own credential: e.g. a fine-grained PAT (or a Codespaces secret / env var) scoped to the other repo, as described under “Authenticating to repositories that you didn't create the codespace from” (Troubleshooting authentication to a repository).