Skip to content

Container mounts the operator's ~/.config/gh; agent acts as that human on GitHub #157

Description

@sebyx07

Follow-up to #100, which removed the ~/.claude bind-mount. The GitHub credential has the same shape and is still mounted.

README.md and the container docs run the agent with -v ~/.config/gh:/home/claudetm/.config/gh, handing it the operator's gh OAuth token. Every push, PR, comment and merge the agent makes is then attributed to that person, with their full scope — including repos the agent has no business touching. It is the same class of problem as #100 (a human's personal credential standing in for the agent's), just for a different provider.

Not fixed in #156 deliberately: that PR only moved the container-side path from /root to /home/claudetm, so it neither introduced nor widened the exposure, and a real fix is a redesign — GH_TOKEN/GITHUB_TOKEN from a scoped, rotatable credential (a fine-grained PAT or a GitHub App installation token), applied consistently across ~8 files. Bundling that into an 81-file PR would have buried it.

Acceptance

  • No container mounts or reads a human's ~/.config/gh.
  • The agent authenticates to GitHub with a scoped, rotatable credential, revocable without touching anyone's personal gh login.
  • Least privilege: only the repos the agent is meant to work on.
  • Verified that gh inside the container picks up the token — gh honours GH_TOKEN, so this is likely env-only, but confirm against the code paths that shell out to gh before documenting it.

Found by CodeRabbit while reviewing #156.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/infrasize/4h~half a day — substantial, design work

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions