GitHub
Pairing GitHub lets ~Alter recognise your technical contribution pattern: the rhythm of your work, the collaborators you ship with, the languages and surfaces you reach for. None of it leaves the recognition layer without a second consent.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Push commits, open pull requests, or modify any repository.
- •Open, comment on, or close issues; review pull requests; merge changes.
- •Post to your account in any form. GitHub does not see a request from ~Alter beyond the read-only OAuth scope.
- •Add or remove collaborators, change repository settings, or transfer ownership.
- •Read or transmit the contents of any private repository, even when the OAuth grant would permit it.
- •Share your contribution data with any third party without a separate consent row scoped to that recipient.
The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.
What we read
- Public profile fields the OAuth scope exposes: ~handle, display name, avatar URL, public bio, account creation date.
- Public repository list and primary languages, enough to recognise the shape of your work, not the contents.
- Public commit timing patterns (when you ship, not what), read once when you pair and reduced to summary statistics. Never per-commit content.
- Co-collaborator graph at the public-repo level: who you ship alongside.
What we don't read
~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.
- Private repositories. Full stop. Even when the OAuth scope grants access, the connector strips them at the boundary.
- Commit contents, diffs, or any code body.
- Issue or pull-request body text, comment threads, or review prose.
- Email addresses harvested from commit author lines, even when public.
- Star, watch, or sponsor relationships (no popularity ranking).
Where it lives
Evidence is stored in ~alter's pairing ledger keyed to your ~handle, encrypted at rest, with a tier badge (T1 OAuth-attested or T2 ownership-confirmed). The OAuth token is encrypted at rest, never exposed to any other surface, and cleared the moment you revoke. Summary patterns feed your identity vector only after a separate consent row is granted.
How to revoke
Revocation is immediate. Ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.
One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.
Prefer the command line? The CLI is the optional deeper path and revokes the same connector:
CLI (optional)
alter pair revoke githubPairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.