Runnable

Provider setup

Connect Cursor Origin

Use an Origin-native repository as Runnable’s source of truth, with signed events, repository-scoped checkout credentials, and Origin-native checks.

Join the organization-allowlisted beta

Origin support is gated per Runnable organization while Cursor’s Origin API is in beta.

  • An operator enables the Origin integration and adds the Runnable organization ID to the beta allowlist.
  • The Origin App requests only repository:contents:read, repository:pull_requests:read, and repository:checks:write.
  • GitHub-backed repositories and inbound or outbound Origin mirrors are not imported.

No repository is silently converted

Connecting Origin adds only native Origin repositories. Existing GitHub and Entire repository records keep their identity and checkout configuration.

Install the Origin App

Runnable administrators connect the active organization from repository onboarding.

  1. 1

    Open Connect repositories

    Choose Connect Cursor Origin. Runnable creates a short-lived, same-site installation state and redirects to Cursor.
  2. 2

    Choose a namespace and repositories

    Approve all repositories or a selected set in Cursor. Selected access is the safer beta default.
  3. 3

    Return with the signed receipt

    Runnable verifies Cursor’s Ed25519 installation receipt, state, app identity, installation identity, and exact required scopes.
  4. 4

    Wait for discovery

    Native repositories are synchronized and default-branch workflow files are discovered asynchronously.

Installations cannot cross organizations

An Origin installation already linked to a different Runnable organization is rejected instead of transferred. Suspend or remove the old link before reconnecting it.

Discover and run workflows

Origin uses the same immutable planner, scheduler, runner, logs, artifacts, approvals, manual runs, and UTC schedules as GitHub-backed repositories.

CapabilityOrigin beta behavior
Workflow files.runnable/workflows/*.yml and *.yaml on the selected revision.
Reusable workflowsLocal references in the same Origin repository.
ActionsLocal actions in the same Origin repository and public GitHub actions.
Manual and scheduled runsThe requested or default ref is resolved to an immutable Origin commit before planning.
Rerun and cancellationCreates a new attempt or terminates active work through the provider-neutral run lifecycle.

An empty Origin repository cannot contain a workflow yet. Create and push an initial commit with a workflow file, then repository discovery will make manual and scheduled runs available.

Signed events and Origin checks

Runnable verifies the raw request before persisting a provider-qualified delivery ID, then processes the event asynchronously.

  • Installation and repository events reconcile access, suspension, deletion, metadata, and native repository selection.
  • Push events normalize each non-deleted ref update and use Origin comparisons for changed-file filters.
  • Pull-request events read the current file list and populate the Actions-compatible workflow context.
  • Queued, running, completed, cancelled, and rerequested jobs upsert Origin checks with stable suite/job keys.
  • Every attempt has a distinct external ID, and timestamp ordering prevents an older update from replacing newer state.
  • Origin’s native rerequest event creates a new Runnable attempt for the selected check run.

Keep Origin credentials checkout-only

The runner obtains a short-lived token restricted to the current repository immediately before checkout and refreshes it only for a bounded fetch retry.

  • The token is added to log masking before it appears in a Git command.
  • Origin jobs do not receive GITHUB_TOKEN, and github.token remains null.
  • The authenticated main remote and submodule Git configs are scrubbed before workflow steps run, even when persist-credentials is requested.
  • Cross-repository Origin checkout is rejected; a repository-scoped token cannot be requested for another source.

Current Origin beta boundaries

The initial release deliberately keeps the provider surface narrow.

Native repositories only

Private Origin actions, cross-repository Origin actions and reusable workflows, Origin mirrors, and arbitrary cross-repository Origin checkout are not supported in v1.

Deploy the additive migration first, then a compatible runner, the provider-aware control plane, and the web integration. Enable only rehearsed organization IDs after install, push, pull request, manual, schedule, rerun, cancellation, check rerequest, suspension, and removal have all been verified.

NextWorkflow referenceReview supported syntax and compatibility boundaries.