💬 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. ⭐

Your enabled/disabled-dotfiles comparison isolates an important difference: the same repository and requested permissions work when the personal dotfiles setting is off. That supports investigating how Codespaces combines those two access paths. It does not establish the exact token-generation implementation, so I would leave the overwrite explanation as a hypothesis.

A workaround to try, building on the successful case you already tested, is to leave personal dotfiles auto-install off, keep the explicit repository permissions in devcontainer.json, and install your dotfiles from the existing submodule yourself after it is initialized. You can run your own setup script manually first; if that works, put the setup in an appropriate dev-container lifecycle command such as postCreateCommand. That lets you test installation and write access together without adding a separate broad OAuth credential.

Two details matter:

• Create a new codespace after committing permission changes. GitHub documents that rebuilding an existing codespace does not apply new repository permissions.
• The lifecycle script should be idempotent and preserve any existing setup command. This project-level workaround does not replace account-wide personalization for unrelated projects.

I have not reproduced this permission interaction myself, and this is a workaround to validate rather than confirmation that the platform bug is fixed. Your report already has the relevant comparison for GitHub Support.

References: additional repository permissions, lifecycle setup commands, dotfiles personalization.

I have one more data point, and a workaround that I am using for now.

To keep this readable, I will use these names:

• <owner>/dotfiles: the repository selected as my personal dotfiles.
• <owner>/app: the repository whose devcontainer.json requests write access to <owner>/dotfiles, and which has <owner>/dotfiles as a submodule.
• "the app codespace" and "the dotfiles codespace": codespaces created from <owner>/app and from <owner>/dotfiles.

The dotfiles codespace can push

With the personal dotfiles setting still on, the dotfiles codespace can push to <owner>/dotfiles. Only the app codespace cannot.

So <owner>/dotfiles is not read-only in every codespace. The write access is missing only when <owner>/dotfiles is requested through customizations.codespaces.repositories from a codespace of another repository.

Workaround: relay the commits through <owner>/app

Until this is fixed, I relay the commits through <owner>/app, which the app codespace can write to. I am describing it here in case it helps someone else.

In the app codespace, I push the commits from the <owner>/dotfiles submodule to a temporary branch of <owner>/app. Git accepts commits with an unrelated history, so this works even though the two repositories share nothing:

$ git push https://github.com/<owner>/app.git HEAD:refs/heads/transfer/dotfiles/<branch>

In the dotfiles codespace (a local clone of <owner>/dotfiles works too), I fetch that temporary branch from <owner>/app and push it to <owner>/dotfiles:

$ git fetch https://github.com/<owner>/app.git transfer/dotfiles/<branch>
$ git switch --create <branch> FETCH_HEAD
$ git push --set-upstream origin <branch>

After that, I delete the temporary branch from <owner>/app.

The commits arrive unchanged, so their hashes and signatures are preserved. If <owner>/app is private, the devcontainer.json of <owner>/dotfiles needs to request contents: read for <owner>/app, so that the dotfiles codespace can fetch from it.

@jaspreetsinghdev786
Thanks for looking into this.

Turning off the automatic dotfiles installation and installing from the submodule in postCreateCommand would work for the one repository that has my dotfiles repository as a submodule. However, the setting is account-wide. I rely on it in the codespaces of my other repositories, and those repositories do not have the dotfiles repository as a submodule.

Turning the setting off is the trade-off I described under "Why this matters", so I will keep it on and wait for a fix. In the meantime I use the workaround described in my other comment in this discussion, which leaves the setting as it is.

One thing that stands out to me is that this seems to be a permission-resolution issue rather than a repository permission issue.

The interesting part is that the same <owner>/dotfiles repository is writable from a Codespace created from the dotfiles repository itself, but becomes read-only when it is requested as an additional repository from another repository's devcontainer.json.

That makes me wonder whether Codespaces is treating the personal-dotfiles repository as a special dependency when generating the GITHUB_TOKEN, and that access path is taking precedence over the permissions declared under customizations.codespaces.repositories.

If that's the case, perhaps the permission resolution could work more like:

effective_permissions = max(personal_dotfiles_permissions, devcontainer_requested_permissions)

rather than allowing the personal-dotfiles access policy to override the explicitly requested permissions.

It would also be useful if the permission prompt surfaced this distinction....for example, showing that a repository is already being granted access for dotfiles installation but has additionally been requested with contents: write.

The fact that disabling the personal dotfiles setting immediately restores write access seems like a particularly strong signal that these two permission paths are being resolved differently.