[amluto]

> temporary per-repo permission scope or token that allowed only pull and push to the repo in question

How about pull from the repo but only push to a staging area from which the user, but not the token, can push for real?

Frankly, LLM agents should do this too. Letting your LLM push seems foolhardy to me.

[lifis]

You can just fork the repository, give it access to the fork and then merge what you want

[amluto]

This is a piece of cake using GitHub’s excellent permission system.

(I’m joking, of course. Service accounts are nowhere to be seen. OAuth can’t even scope to an organization, let alone a repository. And this whole github.dev thing illustrates that you don’t even need to explicitly grant permission to issue broadly scoped tokens.)

Also, forking is pretty heavyweight just to launch something that, for all anyone knows before starting actual work, is being used as a read only viewer.

[alostpuppy]

Exe.dev has an integrations feature which is similar allowing you to grant access to specific repos without having give the VMs credentials. I think it’s a similar pattern to iron.sh.

I have been thinking more and more about how I might use this pattern.

[ndegwaduncan]

the scope problem is actually worse with agents than with github.dev. the architectural answer is the same though: the credential the agent operates with should be scoped to the task and expire when the task ends.

[namibj]

Jules is heavily restricted in what it can do to your repos.

[moi2388]

That makes so much more sense.