Skip to content

docs: note Workflows permission for bot GitHub App#10

Merged
amcheste merged 1 commit intodevelopfrom
docs/bot-app-workflows-permission
Apr 25, 2026
Merged

docs: note Workflows permission for bot GitHub App#10
amcheste merged 1 commit intodevelopfrom
docs/bot-app-workflows-permission

Conversation

@amcheste-ai-agent
Copy link
Copy Markdown
Contributor

Summary

Two gotchas discovered while setting up CI workflows in amcheste/overleaf-mcp — both worth capturing in the canonical bot-account design doc so the next repo setup doesn't repeat the discovery:

  1. Workflows: Read & Write is required for any push that creates or updates a file under .github/workflows/. The original permissions table only listed Contents, Pull requests, and Metadata. Without Workflows, GitHub rejects the push with refusing to allow a GitHub App to create or update workflow ... without 'workflows' permission.

  2. Permission changes don't auto-propagate to existing installations. Updating the App's declared permissions is step one; the installation also has to accept the new scope from Settings → Installations → Configure → Review permissions. Without the second click, runtime tokens still have the old scope.

What changed

  • Added the Workflows: Read & Write row to the GitHub App permissions table in §2 with a one-line explanation of why
  • Added a callout block right after the table about the accept-at-installation step

Both edits land in the same canonical place where someone setting up a new repo would already be looking.

Test plan

  • Reviewer sanity-checks the wording matches their understanding of the GitHub App permission model

🤖 Generated with Claude Code

Two gotchas discovered while wiring CI for amcheste/overleaf-mcp:

- The permissions table didn't list Workflows: Read & Write, but
  it's required for any push that creates or updates a file under
  .github/workflows/. GitHub rejects bot pushes that touch workflow
  files with a clear "refusing to allow a GitHub App ... without
  'workflows' permission" message. Adding the entry to the canonical
  permissions table so future repo setups don't trip over it.

- Changing an App's declared permissions is half the work; each
  existing installation also has to accept the new scope from
  Settings → Installations → Configure → Review permissions. Without
  that second click, the installation token issued at runtime still
  has the old scope and the workflow-push still fails with the same
  error.

Both were learned the hard way today; documenting them so the next
person setting up a new repo doesn't have to repeat the discovery.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@amcheste-ai-agent amcheste-ai-agent Bot requested a review from amcheste as a code owner April 25, 2026 13:50
@github-actions github-actions Bot added the docs label Apr 25, 2026
Copy link
Copy Markdown
Owner

amcheste commented Apr 25, 2026

Merge activity

  • Apr 25, 7:18 PM UTC: A user started a stack merge that includes this pull request via Graphite.
  • Apr 25, 7:18 PM UTC: @amcheste merged this pull request with Graphite.

@amcheste amcheste merged commit 504c9e9 into develop Apr 25, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants