Connections
Link GitHub, PostHog, or Zernio once, or bring any MCP server, then approve tools per routine.
A connection gives a project a way to reach an external system. Work on Repeat supports two kinds:
- Managed providers — GitHub and PostHog use OAuth; Zernio uses an API key.
- Self-managed MCP servers — any Streamable HTTP MCP server you host or subscribe to, configured with a URL and optional encrypted headers.
Both kinds end up in the same place: a connection whose tools are discovered per routine and disabled by default.
GitHub and PostHog (OAuth)
Open Connections and select Connect GitHub or Connect PostHog. You are redirected to the provider, approve the scopes, and return to the dashboard.
| Provider | Scopes requested | MCP server |
|---|---|---|
| GitHub | read:user, repo | https://api.githubcopilot.com/mcp/ |
| PostHog | openid, profile, email, insight:read, event_definition:read, query:read | https://mcp.posthog.com/mcp |
PostHog uses PKCE with S256. GitHub OAuth apps do not support PKCE, so that
flow relies on the client secret and a single-use state.
Every authorization request stores a state bound to your user and the active
project, valid for ten minutes and consumed on first use. The callback is
refused when the state is unknown, expired, already used, or finished by a
different session.
Access tokens are encrypted at rest with ENCRYPTION_KEY and are never
returned by the API. Re-authorizing replaces the stored credentials in place
rather than creating a second connection.
If a provider's connect button is disabled, that deployment has not configured its OAuth client. See Deployment.
Zernio (API key)
Zernio holds the social accounts you have already connected — X, LinkedIn, Instagram, TikTok, and others. Rather than re-authorizing each network here, paste a Zernio API key from your Zernio dashboard.
The key is verified immediately against GET /v1/accounts. A key Zernio
rejects is never stored. On success the dashboard lists each connected social
account with its platform, handle, and whether it is active, read live from
Zernio so it always reflects the current state.
Self-managed MCP servers
Any Streamable HTTP MCP server can be registered with a name, a URL, and optional headers. See Connect your own MCP server for the walkthrough, including the header limits and network rules.
Connection status
| Status | Meaning |
|---|---|
untested | Saved, but tool discovery has not succeeded yet. |
ready | Discovery succeeded at least once. |
error | The last attempt to use the connection failed. |
Discover tools
Open a routine, choose a connection, and select Discover tools. The API asks the MCP server for its current tool definitions and creates a per-routine policy for each.
Every discovered tool is disabled by default. Rediscovery refreshes the remote schema and resets prior approvals, so changed server behaviour cannot inherit an old automatic-execution grant.
Explicit execution approval
MCP annotations such as readOnlyHint are shown as context, but the remote
server controls those annotations and they are not treated as authorization.
Allowing any external tool to run automatically requires a separate
confirmation that names the tool and explains that it may read or change
connected data.
Automatic execution is a distinct choice and requires the tool to be enabled first. Tool calls and results appear in the run trace. See Tool permissions.
Disconnect
Selecting Disconnect deletes the stored credentials and the connection. Revoke the grant at the provider as well — GitHub under Applications, PostHog under Authorized applications, Zernio by deleting the API key.
Network controls
Production connections reject unsafe destinations such as loopback, link-local, and private network addresses. The validated public DNS answers are pinned to the outbound connection to prevent DNS rebinding between validation and use. Local development can connect to an explicit fixture server for testing.