2. Configure repo access & signals
After the GitHub App is installed, three things determine what ends up in your workspace:
- Which GitHub accounts/orgs the App is installed on — granted in GitHub during install.
- Which of the App-accessible repos this workspace actually tracks — toggled in Kleio's Manage GitHub connections UI.
- Which event types from tracked repos become captures — toggled in Kleio's GitHub Signal Configuration panel.
All three are reversible at any time.
Manage GitHub connections (in-app)
The primary place to add accounts and pick repos is inside the Kleio app:
- Click your profile avatar (top right) › GitHub.
- The Manage GitHub connections page shows every GitHub account/org where Kleio is installed, with a per-account repo count.
From here you can do two things, in order:
Add a GitHub account or org
Click + Add GitHub account to install Kleio on another personal account or organization. This redirects you to GitHub's standard App install flow:
- Pick the account/org to install on.
- Choose All repositories or Only select repositories (you can change this later in either GitHub or Kleio).
- Confirm. GitHub redirects you back to Manage GitHub connections and the new account appears immediately.
Connect specific repos to this workspace
Pick an account, click Next: Manage repositories, and you'll see two lists per account:
- Connected — repos this workspace is actively tracking. Captures, PRs, commits, etc. flow into this workspace.
- Available to connect — repos the GitHub App can see but aren't tracked here yet. Check a box and click Apply changes to start tracking.
Each workspace has a plan-based repo limit (Free: 5, Pro: 25, Team: unlimited). When you hit it, the Available to connect list disables further checkboxes with an upgrade prompt:
"Repo limit reached for this workspace. Upgrade to connect more."
You can still disconnect a tracked repo to free a slot.
If the GitHub App is installed with All repositories access, new repos created in that account may show up in Connected automatically — even without you toggling them on in Kleio. This can push you past the plan repo limit unexpectedly (the screenshot above shows 9 / 5 repos, which is the symptom).
Workaround for now: install on Only select repositories in GitHub if you want strict per-repo control from Kleio's side. We're rolling out a fix that respects the workspace's per-repo connect state regardless of how the App is scoped in GitHub.
When to use the GitHub-side flow instead
Going through GitHub › Settings › Applications is still a valid path, mainly for two cases:
- Auditing what permissions the App holds — GitHub is the source of truth for OAuth scopes.
- Revoking access entirely — uninstalling the App in GitHub immediately stops all webhooks and is the cleanest "kill switch" if you ever need it. GitHub fires
installation_repositoriesandinstallationwebhooks at Kleio for every change, so the Kleio UI catches up within seconds either way.
Steps:
- Go to GitHub › Settings › Applications › Installed GitHub Apps (personal) or ‹org› › Settings › GitHub Apps (org).
- Click Configure next to Kleio.
- Adjust Repository access or click Uninstall under the danger zone.
Disconnecting a repo in Kleio stops it from being tracked in this workspace, but the GitHub App still has access. Uninstalling the App in GitHub revokes all access cleanly and stops every webhook. Either way, existing captures, decisions, and checkpoints stay in your workspace as historical record — nothing gets retroactively deleted.
Tune which signals become captures
Open the profile avatar (top right) › Signals to reach the GitHub Signal Configuration panel. It controls which event types from your connected repos actually create captures. Disabled signals are silently ignored at the webhook layer — they don't count against your monthly capture quota.
| Signal | What it captures | Volume | Default |
|---|---|---|---|
| Git commits | Individual commits pushed to connected repos | High | Off |
| Pull requests | PR opened, closed, or reopened | Moderate | On |
| PR reviews | Review submitted on pull requests | Moderate | On |
| CI runs | GitHub Actions workflow completions | Moderate | Off |
| Deployments | Deployment status transitions | Low | Off |
| Discussions | Discussion created or answered | Low | On |
| Issues | Issue opened or closed | Moderate | On |
| Security alerts | Dependabot, code scanning, security advisories | Low | On |
Recommended: enable commits
Enabling Git commits is the single highest-leverage change you can make for the quality of Kleio's correlations. Commits are how checkpoints, decisions, and PRs all anchor back to specific code — without them, the synthesis pipeline loses the ability to say "this checkpoint corresponds to those three commits, which together form the slice that closed KL-42."
The tradeoff is volume.
On an active codebase, commits can outnumber every other signal type combined. The Free plan's 500 captures/month limit will go fast on a busy week if commits are on across many repos.
In practice:
- Evaluating Kleio → leave commits off. PRs + reviews give you enough signal to see the synthesis loop work end-to-end.
- One or two active repos → enable commits. Code-level correlation is the main thing you're paying for.
- Many repos, large team → enable commits selectively (we'll be adding per-repo signal toggles soon — for now the toggle is workspace-wide).
You can toggle commits off at any time without losing existing captures.
Per-signal reset
Each row has a Reset action that returns that signal to its workspace default. Useful if you've experimented and want to get back to a known baseline without touching unrelated toggles.
Changes apply to new events only
Toggling a signal on does not retroactively backfill historical events — it only affects webhooks Kleio receives from that point forward. To pull in past commits, PRs, and reviews from your connected repos, see the next page on importing history.
Who can change signal config
Only workspace owners and admins see editable toggles. Members can view the current configuration but the switches are disabled with a notice at the bottom of the panel.
You're set on the GitHub side
Repository access decides what Kleio can see; the signal panel decides what becomes a capture. With both configured, you can either start working and let signals stream in, or backfill history first.