StarSling
Configuration

GitHub App Permissions

What permissions StarSling requests and why

View Markdown

The StarSling GitHub App requests specific permissions to provide runner functionality and AI-powered optimizations.

Required Permissions

Repository Permissions

PermissionAccessPurpose
ActionsRead & WriteRegister runners and receive workflow job events
ChecksRead & WriteReport runner assignment and job status
ContentsRead & WriteRead workflow and source files for AI optimization scanning, and commit proposed changes to pull request branches
Pull requestsRead & WriteOpen AI optimization pull requests
WorkflowsRead & WritePropose changes to .github/workflows files via pull requests
Code scanning alertsReadRepository context for AI optimization analysis
DeploymentsReadRepository context for AI optimization analysis
DiscussionsReadRepository context for AI optimization analysis
IssuesReadRepository context for AI optimization analysis
MetadataReadBasic repository information (required by all GitHub Apps)
PagesReadRepository context for AI optimization analysis
WebhooksReadReceive webhook deliveries and view hook metadata

Organization Permissions

PermissionAccessPurpose
Self-hosted runnersRead & WriteRegister and manage runners at the organization level
MembersReadOrganization membership for access management
WebhooksReadReceive webhook deliveries and view hook metadata

Account Permissions

Granted when you sign in to StarSling with GitHub, not when the app is installed on a repository.

PermissionAccessPurpose
Email addressesReadCreate your StarSling account and send account email such as the welcome message

Permission Details

Actions (Read & Write)

Why: StarSling needs to register self-hosted runners with your repository and receive webhook events when workflows start.

What we do:

  • Register ephemeral runners
  • Remove runners after job completion
  • Receive workflow_job webhooks

What we don't do:

  • Modify your workflow files outside of a pull request you review (see Workflows)
  • Access workflow run logs (except for optimization scanning)

Checks (Read & Write)

Why: To report runner assignment status and provide visibility into job execution.

What we do:

  • Update check status when runner is assigned
  • Report runner health information

Contents (Read & Write)

Why: To read workflow definitions and repository source code for AI optimization scanning, and to commit proposed changes to pull request branches.

What we do:

  • Read workflow definitions for optimization scanning
  • Read source code files in your repository to provide context for AI optimization suggestions
  • Process file contents in memory during analysis
  • Commit optimization changes to a new branch and open a pull request

What we don't do:

  • Persist the checkout beyond the temporary 24-hour AI analysis window (see Data Handling). Source code a workflow prints to the console — a diff, a file dump, a stack trace — is part of the retained job log and follows that log's retention instead
  • Push to your default branch or existing branches — changes are isolated to pull request branches for your review

Pull Requests (Read & Write)

Why: To open AI optimization pull requests against your repository.

What we do:

  • Open pull requests with optimization changes and explanations

What we don't do:

  • Approve or merge pull requests
  • Close or modify PR metadata

Workflows (Read & Write)

Why: To propose optimizations to your GitHub Actions workflow files.

What we do:

  • Include updated .github/workflows/*.yml files in optimization pull requests

What we don't do:

  • Change workflow files outside of a pull request you review and merge

Email Addresses (Read)

Why: GitHub sign-in does not return your email address unless the app asks for it, and StarSling identifies your account by email.

What we do:

  • Create your StarSling user account when you first sign in
  • Send account email, such as the welcome message
  • Match your GitHub commit author email to your Slack user if you enable pull request notifications

What we don't do:

  • Read the mailbox itself — GitHub exposes only the addresses on your account
  • Sell, share, or use your address for marketing

Read-Only Permissions

The remaining read scopes — deployments, discussions, issues, pages, code scanning alerts, repository and organization webhooks, and organization members — give StarSling's agents repository and organization context for optimization analysis and let the app receive the webhook events that trigger runner provisioning. None of these are used to modify your repositories or organization.

Data Access Summary

Data TypeAccessedStoredRetained
Workflow eventsYesNoNo
Workflow definitionsYesNoNo
Source code (AI analysis)YesTemporarily24 hours
Workflow job logsYesYesNo longer than 12 months
SecretsNoNoNo
Environment variablesNoNoNo
Account emailYesYesUntil you delete your account

For a full breakdown of access, storage, and retention, see Data Handling.

Security Practices

Secrets Passthrough

Your GitHub secrets are passed directly to the runner by GitHub. StarSling's control plane never receives, stores, or logs secret values — there is no code path that reads them.

The one place a secret value can reach what we retain is the job's console output, and only if the workflow prints it. We fetch that log from GitHub's own Actions log archive, so values registered as Actions secrets arrive already masked by GitHub; anything else a job echoes is in the output, exactly as it is in GitHub's copy. See Workflow Job Logs.

Ephemeral Runners

Each job runs on its own dedicated, single-use machine that's destroyed when the run finishes — there's nothing for a later job or a fork pull request to persist on or reach, and the boundary between two customers is a machine boundary. See Isolation for details.

Encrypted Transit

All communication uses TLS 1.3. Webhooks are verified using GitHub's signature.

Revoking Access

To remove StarSling:

  1. Go to your repository or organization settings
  2. Navigate to IntegrationsGitHub Apps
  3. Find StarSling and click Configure
  4. Click Uninstall

After uninstalling:

  • All runners are immediately deregistered
  • No further webhooks are received
  • Retained job logs age out on the retention schedule in the Data Access Summary. Uninstalling does not itself delete them — to have them removed, request deletion via Data Deletion

On this page