Are self-hosted GitHub Actions runners safe?

Safe for code you trust. A self-hosted runner is not a sandbox.

A self-hosted runner is safe for workflows you would run in your own terminal, and not for code from strangers. A job runs as your user: it can read and change your files, reach your network and leave programs running. Codemany keeps public repos off unless you turn one on, gives each job a fresh runner, and keeps your GitHub token on your machine.

What a job can do on your machine

A job runs as your user, just like a command you type. It can:

• read and change your files, SSH keys and source trees;
• reach every device on your network;
• leave programs running after the job ends.

So the rule is simple: only run workflows you would run in your own terminal. Details: What a job can do.

Public repos and fork pull requests

On a public repo, anyone can open a pull request that runs their code. So Codemany refuses public repos unless you turn one on yourself, per repo. It also refuses repos with risky workflow settings, and checks again every 30 minutes, because a repo can be made public later.

• Private repos: keep "Run workflows from fork pull requests" off in the repo or organization settings (GitHub's default).
• Public repos you opt in: GitHub must be set to require approval for all external contributors. Review each run's diff, workflow files and build scripts included, before you approve it.
• pull_request_target and workflow_run run with the base repo's secrets. Never check out or build a pull request's code from them on your own runner.
• Who can push can run code. Anyone with write access to a repo can add a workflow that runs on your machine. Keep that list short and protect the default branch.

What single-use runners protect, and what they don't

Each job gets a fresh runner that is wiped afterwards. That keeps jobs apart from each other: no job starts in another job's runner folder. It does not keep a job away from your Mac or Linux machine. See ephemeral, single-use runners for what is wiped and what carries over, and isolation modes for keeping jobs further apart.

What Codemany can and can't see

Your code stays on your machine. Your GitHub token is never sent to Codemany's servers: on a Mac it is in Codemany's own Keychain item, on Linux in a file only you can read or your desktop keyring. Full list: What leaves your Mac and the Privacy Policy.

Make your runner safer

1. Limit the token

   Use a fine-grained GitHub token, limited to the repos Codemany serves, with an expiry date.

2. Use a clean machine or account

   Use a separate Mac or user account with no personal data.

3. Drop long-lived cloud keys

   Don't keep them on the machine. Use OIDC from the workflow instead:

   jobs:
     deploy:
       runs-on: [self-hosted, codemany]
       permissions:
         contents: read
         id-token: write
       steps:
         - uses: actions/checkout@v4

4. Keep public repos off

   Turn one on only when you have read Public repos are opt-in.

Questions

Should I use a self-hosted runner on a public repo?

Only with care. Codemany refuses public repos unless you turn one on per repo, and an approved fork run still runs as your user. Use a separate machine or account for it.

Can Codemany see my code?

No. Code and your GitHub token stay on your machine. Codemany Console gets job logs with secrets masked, never code.

Are the downloads signed?

Yes. The Mac app is signed and notarized by Apple. On Linux, the apt repository and the install script's checksums are signed with Codemany's key (fingerprint).

Can other devices on my network change settings?

No. Other devices can view the dashboard at port 8825, read-only. Make changes in the Codemany app.

How do I report a security problem?

Send a direct message to @arpwal on X.