# macOS runner: "No such file or directory @ rb_sysopen" (Ruby/gem) in CI

> Fix Ruby "Errno::ENOENT: No such file or directory @ rb_sysopen" on a macos-latest runner - a gem or script tried to open a path that does not exist on the runner.

Source: https://latchkey.dev/learn/github-actions/macos-ruby-rb-sysopen-no-such-file-in-ci  
Updated: 2026-06-30

Ruby raised Errno::ENOENT from rb_sysopen, meaning a file open failed because the path is missing. In CI this is usually a path that exists locally but not on the runner: a config, a vendored asset, or a tool a gem expects.

## Diagnose it: is the job queued, or is the runner gone?

A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.

```.github/workflows/ci.yml
- name: Runner facts
  run: |
    echo "runner name: $RUNNER_NAME"
    echo "os/arch:     $RUNNER_OS/$RUNNER_ARCH"
    nproc; free -h; df -h /
    echo "labels this job asked for: ${{ toJSON(job) }}"
```

> If the job sits in `queued` and never picks up, no runner matches every label you listed. Labels are ANDed: `runs-on: [self-hosted, linux, gpu]` needs one runner carrying all three, not three runners carrying one each.

## The failures that are not your workflow

- Exit 137 is the kernel out-of-memory killer, not an application error. Check `free -h` above against your peak usage.
- Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
- A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
- A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.

## FAQ

### What causes macOS runner: "No such file or directory @ rb_sysopen" (Ruby/gem) in CI?

There are 2 common causes: a file present locally is absent in ci and a relative path resolves from the wrong directory. An untracked config, a gitignored secret, or a generated file that is not produced in CI leaves the path missing when the gem opens it.

### How do I fix macOS runner: "No such file or directory @ rb_sysopen" (Ruby/gem) in CI?

There are 2 fixes depending on which cause you have: provide the missing file or generate it and run from the correct working directory. Work through them in order, since the first is the most common.

### What does macOS runner: "No such file or directory @ rb_sysopen" (Ruby/gem) in CI actually mean?

A Ruby tool (Fastlane, CocoaPods, a Rake task) fails with "No such file or directory @ rb_sysopen - <path> (Errno::ENOENT)".

### How do I stop macOS runner: "No such file or directory @ rb_sysopen" (Ruby/gem) in CI happening again?

Materialize required config and secret files before Ruby steps. The prevention section lists 3 changes that keep it from recurring.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt