3 ms·

Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology

Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.

ozozozd 6mo ago
They mention that as a mechanism for protecting the SSH keys for the repo. Essentially using a repo that doesn’t matter with the coding agent and then creating a cross-repo PR to the real repo.
dddddaviddddd 6mo ago
I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can otherwise restrict access to a single repo with write access. Essentially, though, you'd want to find a way to give the remote host the most limited possible privileges to your Github account.
- thwarted 6mo ago
  Oh, a separate GitHub account that has its own forks of the repos the agent is working on. Yeah, that's probably the most secure, isolated, and safest. The merge to the canonical repo then needs to go through a human, or at least separately controlled, process via a GitHub pull request.
  - deleted 6mo ago
    [deleted]
- throwaway173738 6mo ago
  You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.
  - kstenerud 6mo ago
    I use an overlay copy of my workdir, then the sandboxed LLM doesn't get any of my secrets, can do its own commits, and I pull the ones back that I want.
- dolmen 6mo ago
  On a GitHub project, agents must just be considered untrusted external contributors.
- dezgeg 6mo ago
  Maybe this is doable with scoped API keys instead of SSH keys?

ozozozd 6mo ago

They mention that as a mechanism for protecting the SSH keys for the repo. Essentially using a repo that doesn’t matter with the coding agent and then creating a cross-repo PR to the real repo.

dddddaviddddd 6mo ago

I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can otherwise restrict access to a single repo with write access. Essentially, though, you'd want to find a way to give the remote host the most limited possible privileges to your Github account.

thwarted 6mo ago
Oh, a separate GitHub account that has its own forks of the repos the agent is working on. Yeah, that's probably the most secure, isolated, and safest. The merge to the canonical repo then needs to go through a human, or at least separately controlled, process via a GitHub pull request.
- deleted 6mo ago
  [deleted]
throwaway173738 6mo ago
You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.
- kstenerud 6mo ago
  I use an overlay copy of my workdir, then the sandboxed LLM doesn't get any of my secrets, can do its own commits, and I pull the ones back that I want.
dolmen 6mo ago
On a GitHub project, agents must just be considered untrusted external contributors.
dezgeg 6mo ago
Maybe this is doable with scoped API keys instead of SSH keys?