Skip to main content
GitHub is the single source of truth for permissions. You never configure access controls in Pullfrog—it all comes from GitHub.

​
How it works

All Pullfrog users sign in with GitHub. In the console, users can only see repos and organizations they already have access to. There is no separate user list, invite step, or seat assignment in Pullfrog—the first time a teammate signs in, no extra setup is required. Pullfrog stores repository settings and mirrors some GitHub metadata, but it never maintains a separate set of permission grants. Console access is resolved through GitHub with the signed-in user’s token. Sensitive organization-owner gates, including billing changes, discard the cached membership result and read GitHub again before acting.

​
The organization console

Anyone in your GitHub organization can sign into Pullfrog and view the org console at pullfrog.com/console/<org>. They’ll see every repo in the org that they personally have access to on GitHub. Outside collaborators—people who have access to specific repos in the org but aren’t members of it—see a stripped view at pullfrog.com/console/<org> that lists only the repos they collaborate on, with no billing or other org-wide cards. They use the per-repo console for everything else. A handful of cards that govern money are restricted to GitHub organization owners (and the account owner, for personal accounts). These cards stay in place for non-owners so navigation and anchor links still resolve, but the body is replaced with a short “ask an owner” message and marked with a small lock icon next to the heading. The underlying API endpoints enforce the same gate server-side, so financial data is never sent to non-owner browsers in the first place. The owner-only cards are:
  • Billing — Pro status, model usage (Pullfrog Router credit balance, auto-reload schedule, and provider API keys for BYOK), and any attached payment method. Use Update to manage the card and view Pro invoices in the Stripe Customer Portal.
  • Billing history — Pro and legacy pay-as-you-go invoices under Invoices, Router top-ups and credit grants under Router credit.
Everything else on the org console is open to any member of the organization, to read and to edit — you do not need to be an owner:
  • Model — the org-wide default model and reasoning effort. Repos without a model of their own inherit it.
  • Standing instructions — prose prepended to every run in the organization, before each repo’s own instructions. May embed flags.
  • Cross-repo brief and Cross-repo learnings — the org-level inputs to cross-repo runs. See learnings.
  • Custom flags — org-scoped flag aliases. A repo’s own alias of the same name shadows the org one.
Because standing instructions and flag aliases reach every run in every repo of the organization, they carry more reach than an individual member’s repo permissions do. Outside collaborators are not members and cannot see or edit any of it.

​
The repo console

Anyone with access to a specific repo on GitHub can view its console at pullfrog.com/console/<org>/<repo>—including outside collaborators who aren’t members of the parent org. What they can do there follows GitHub’s repo permission ladder.

​
Repo read

Anyone with read access to the repo can:
  • Open the repo console.
  • Trigger runs from the prompt box.
  • View active and historical workflow runs.
A read-only callout replaces the settings panel.

​
Repo write

Adds the ability to edit most of the repo settings panel:
  • Agent — model selection and per-model BYOK key status.
  • Hooks — setup, post-checkout, and pre-push scripts.
  • Modes, Learnings, Flags.
  • All Automations — Mentions, Review PRs, Enrich Issues, Label Issues, Address reviews, Fix CI failures.
  • Danger zone — disable Pullfrog for this repo (and re-enable it later).

​
Repo admin

Anything that touches secrets or shell-level access requires repo admin. These cards still appear for write users so navigation and anchors resolve, but the body is replaced with a Lock icon + short “ask an admin” message.
  • Secrets — add and delete repo-level secrets.
  • Security — shell isolation toggle and environment allowlist.

​
GitHub organization owner

A separate axis from repo permissions. A few flows surface differently for organization owners versus everyone else, marked with the same lock icon used in the org console:
  • The Learnings card on a private repo points owners to billing when a plan is required; non-owners see a short “ask an owner” message in its place.
  • The model selector shows a Pullfrog Router funding hint that points owners at the org billing flow and tells non-owners who to ask.
  • Account-level (org) secrets can only be added or deleted by organization owners. Repo admins who aren’t organization owners still manage their own repo’s secrets.
Owner status comes from GitHub. GitHub’s API represents organization owners with the membership role admin; personal installs use the personal account owner.

​
What this means for your org

  • GitHub-backed access — Membership and permission changes stay governed by GitHub; sensitive owner-only actions recheck the current GitHub role.
  • Scoped visibility — Org members only see repos they have access to on GitHub.
  • Teams — No need to recreate your GitHub team structure.
  • Accurate billing — No stale seats or phantom users.