# macOS runner: "ld: library not found for -lSystem" in CI

> Fix "ld: library not found for -lSystem" on a macos-latest runner - the linker cannot find the base system library because the SDK or Command Line Tools path is wrong after an update.

Source: https://latchkey.dev/learn/github-actions/macos-ld-library-not-found-lsystem-in-ci  
Updated: 2026-06-30

The macOS linker resolves `-lSystem` from the active SDK library directory. When the SDK path is stale or the Command Line Tools are missing, ld cannot find libSystem and the link step fails.

## 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: "ld: library not found for -lSystem" in CI?

There are 2 common causes: the command line tools sdk path is stale and a missing sdkroot or library search path. After an OS or Xcode change the active developer directory points at an SDK that no longer holds the system libraries, so -lSystem cannot resolve.

### How do I fix macOS runner: "ld: library not found for -lSystem" in CI?

There are 2 fixes depending on which cause you have: point the toolchain at the current sdk and reinstall command line tools. Work through them in order, since the first is the most common.

### What does macOS runner: "ld: library not found for -lSystem" in CI actually mean?

A native compile or link (often a Ruby gem, Node native module, or Go cgo build) fails with "ld: library not found for -lSystem" and "clang: error: linker command failed".

### How do I stop macOS runner: "ld: library not found for -lSystem" in CI happening again?

Export SDKROOT from xcrun --show-sdk-path for native builds. 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