The Claude GitHub App: a fourth real identity shape
Grounded in docs/docs/claude.com/docs/claude-tag/admins/configure-github.md ("Configure GitHub access") -- a doc every prior concept page on this site brushes past without citing directly. agent-identity.md's own worked example is "commits and pull requests show the Claude GitHub App as the author"; every one of this site's four seeded access bundles lists github as a connection. This page is that citation, made explicit.
1. GitHub access is configured at two levels
| Level | What you set |
|---|---|
| Organization | Which GitHub organizations are linked to your Claude organization |
| Access bundle | Which repositories Claude can reach -- the bundle's Repositories tab |
-- configure-github.md, opening table. The organization-level link is a one-time identity grant (the Claude GitHub App gets installed on a GitHub org); the bundle-level grant is the same per-scope access_bundles row shape already on this site's access-bundles board -- bundle_desktop_cowork and bundle_desktop_code both already list github in their connections column, and credential_pattern on those rows already notes the local-process-auth distinction from a claude-tag-managed GitHub App install.
2. Pull requests are authored by the identity, not the requester
"Claude Tag gives Claude its own GitHub identity, the Claude GitHub App, so pull requests it opens from a channel are authored by Claude rather than by a person."
-- configure-github.md. This is the exact claim the identities board's attribution_mode = 'service_account' column already generalizes: a channel/service-account identity's actions are attributed to that identity's own account in each tool, GitHub included, never to whoever triggered the session. id_cloud_docker_mcp's own acts_as field already makes this claim for the Docker MCP Toolkit surface; the Claude GitHub App is the same shape, one tool over.
3. What loads when a repository is cloned
"When Claude clones a granted repository into a session, its CLAUDE.md, .claude/CLAUDE.md, and .claude/rules/*.md files load on the next turn after the clone completes... A repository's .mcp.json is never loaded; connections come only from the Access bundle."
-- configure-github.md, "What loads from a repository." This is a real, load-bearing fact about this exact repository: the standing directives already cataloged on the directives board (the cloud-sandbox rule, the naming-ontology enforcement rule) are precisely CLAUDE.md content that "loads on the next turn after the clone completes" whenever any Claude session -- Cowork, Claude Code, or a hypothetical future claude-tag channel -- clones this repository. The directive doesn't travel with the GitHub connection; it travels with the repository itself, exactly as this doc describes.
4. Scheduled work reuses the same connection
"Scheduled jobs use the same GitHub connection as interactive work, with nothing extra to configure. A recurring job that can't reach its repository skips that run and retries on its next schedule; after three consecutive failed runs spanning at least an hour, it disables itself."
-- configure-github.md, "Scheduled work uses the same connection." See subagenttasks.com's routines page for this repo's own real scheduled-work primitive, including its own honest gap: this repo's workers/cron trigger has no documented retry-then-disable policy of its own today, unlike the one this doc specifies.
What this site adds
Four real identity shapes are now cataloged across this site: macOS-local, Docker-Toolkit-provisioned, binary-mediated, and Cloudflare-account identities on the identities board, plus this page's fifth shape -- the Claude GitHub App -- documented rather than seeded as a fifth D1 row, since this repo has no live claude-tag GitHub App install to seed a real row from. The citation stands on its own without inventing data that doesn't exist.