Is GitLab Runner macOS Auto-Login Safe? 2026 Acceptance Checklist

A macOS Runner service does not behave like a system service that starts independently of a user session. GitLab documents that the macOS service uses a user-level LaunchAgent. Its availability therefore depends on the account session and the conditions under which that agent is loaded. GitLab also describes automatic login as a way to keep the Runner available after a restart. These are documented behaviors, not proof that every machine will recover successfully in every enterprise setup. GitLab’s macOS Runner installation guide explains the service model and the session dependency.

Treat four outcomes as separate checks:

• User logged in: the intended macOS account has a session.
• LaunchAgent loaded: the Runner service has started within that user’s session.
• Runner available: the registered Runner can receive work.
• Build accepted: a representative job completes with the expected outputs and permissions.

One result does not establish the next. A visible desktop does not prove the LaunchAgent loaded. A Runner marked available does not prove that signing, simulator, or network-dependent jobs will work. A successful build does not prove that the host enforces the correct trust boundaries.

Before changing login behavior, record the installed Runner version, the account that installed and runs it, the LaunchAgent configuration, and what happens when that user logs out. Confirm who can modify the service and how the organization expects it to behave after a restart. If operations rely on a person logging in manually, document who owns that action and how the delay is handled.

A CI host’s risk is determined by what a job can do as its execution identity, not only by the account’s display name. The Runner account may be able to read workspaces, caches, local configuration, development tools, network-mounted files, or credentials. Inventory access as the account actually used for a job; an administrator’s desktop session is not a substitute for that evidence.

For each relevant path and service, record whether the job can read, write, or execute. Include the home directory, project checkout and cache locations, build tools, network resources, and any Keychain the account can access. Check whether the account has administrator privileges. If a task does not need those privileges, remove them or move the task to a separately controlled environment rather than relying on a promise that the pipeline will not invoke privileged actions.

The GitLab macOS setup documentation provides setup guidance, but the enterprise decision still depends on the machine’s effective permissions and local configuration. Preserve evidence from a job running as the Runner identity: the identity itself, accessible locations, and permissions relevant to the workload. A written account policy is useful, but it cannot replace testing the actual job context.

GitLab’s Shell executor runs jobs locally on the Runner host under the Runner user. GitLab warns that this executor offers limited isolation. In practice, a job may access resources available to that account, so separate projects that do not share the same trust level. This warning applies to the Shell executor; do not assume it describes every executor or every possible isolation design. See GitLab’s Shell executor security guidance.

A project label is not a security control by itself. Decide which branches, contributors, and pipeline sources may use each Runner, then check the actual assignment rules. A job that can run untrusted changes on a host holding a release credential can create a credential exposure path even if the pipeline definition for ordinary builds never references that credential.

Architecture recommendation: reserve a shared Shell executor for jobs whose code and access needs are within the same trust boundary. Move external contributions, less-trusted projects, or jobs requiring sensitive signing access to separately controlled capacity. If that separation cannot be demonstrated, do not use automatic login as a reason to keep the shared host continuously available.

Apple’s support guidance notes that automatic login may not be available when FileVault is enabled. That setting limitation matters to restart planning; it does not mean that every Mac configuration has the same recovery outcome. Check the target machine’s actual settings and the organization’s encryption requirements before deciding how the Runner should return after a restart. Apple’s automatic-login guidance describes the setting constraint. Apple’s FileVault security guide explains FileVault as a disk-protection control.

Keep these questions distinct:

• Does the encrypted disk reach the state required for the operating system to start?
• Does the intended user account get a usable session?
• Does the user-level LaunchAgent start?
• Does the Runner become available to accept a job?
• Does a representative build finish correctly?

Do not disable an organization-required disk-protection control merely to make the Runner recover without human intervention. That changes the security posture to solve an availability problem. If the policy prevents the required automatic login path, choose a recovery approach approved by the organization, define the manual unlock or login owner, or redesign how the build capacity is operated.

Record the expected and observed state after a restart. A machine that is powered on but awaiting disk unlock is not equivalent to a logged-in user session; a logged-in session is not equivalent to an available Runner. Keeping these distinctions in the incident procedure helps operations staff identify the failing step instead of repeatedly restarting a host whose actual blocker is encryption or login policy.

A signing account is more sensitive than a test-only account because access to its Keychain and certificates may enable release-related actions. Inventory which certificates, private keys, provisioning assets, and other signing credentials a job can reach. Do not infer access from the pipeline YAML alone: check what the execution account can actually read and which tasks can run on the host.

Separate signing work from ordinary tests when ordinary jobs do not need release credentials. Use Runner assignment and project trust rules to restrict which workloads can reach the signing environment. Keep an auditable record of access, changes to Keychain permissions, and the process for revoking or rotating credentials. If all jobs use one interactive account with broad Keychain access, the account is the effective boundary; a separate job name does not create isolation.

A signing task should pass review only when its allowed code sources, Runner eligibility, execution identity, and credential access all match the release policy. If those conditions cannot be shown, remove signing access from the shared host or defer production use until the trust boundary is fixed.

Test in an isolated environment before changing a production node. Use the same macOS security policy, Runner service mode, account permissions, and relevant build tooling expected in production. A successful test is evidence for that tested setup; it is not a guarantee that a different host or policy will behave the same way.

Use this sequence:

• [ ] Record the host’s login and FileVault requirements, the Runner account, and whether the service is installed as a user-level LaunchAgent.
• [ ] Review the LaunchAgent’s start and stop conditions, then verify how the account session is expected to begin after a restart.
• [ ] Inventory the Runner account’s file, network, tool, administrator, and Keychain access. Confirm that every permission is needed by an accepted workload.
• [ ] List which projects, branches, contributors, and job types may use the host. Identify external or otherwise less-trusted code and decide whether it needs a separate Runner boundary.
• [ ] Restart the isolated host under the approved security policy. Record disk state, user-session state, LaunchAgent state, and Runner availability separately.
• [ ] Run a representative non-signing build, then a signing test only if the host is approved to hold the relevant credentials. Verify expected outputs and retain the job identity and access evidence.
• [ ] Document what an operator must do if the disk, user session, LaunchAgent, or Runner does not recover. Assign that action to a named operational role, not an assumed user.
• [ ] Approve, adjust, or defer deployment based on the observed recovery path and policy requirements. Repeat the acceptance test after a material change to the service setup or security policy.

For the release record, keep the test date, host identity, relevant settings, observed state transitions, job results, and any manual intervention. This lets reviewers distinguish “Runner is online” from “the production workload is safe and recoverable.” If a state failed to recover, record the actual blocker and remediation rather than marking the test as successful after a manual workaround.

Why does GitLab Runner on macOS need automatic login?

The macOS service is a user-level LaunchAgent, so its lifecycle depends on a user session. Automatic login may restore that session after a restart, but it solves only that part of the recovery path. Verify the LaunchAgent, Runner registration and availability, and a representative build independently. If your organization does not permit automatic login, document an approved manual recovery path rather than weakening a required control.

Can a Runner recover automatically after a restart with FileVault enabled?

Do not assume it can. Apple documents a restriction on automatic login when FileVault is enabled, so the approved encryption configuration may prevent that recovery method. Test the target setup without changing the required disk-protection policy. Record whether disk unlock, user login, LaunchAgent startup, Runner availability, and a real build each succeed, and assign an owner to any required manual step.

Can the Shell executor isolate builds from different projects?

The Shell executor provides limited isolation: jobs run locally under the Runner account, with access shaped by that account’s permissions. Project names do not create a security boundary. Route only workloads with compatible trust and access needs to a shared host. Separate less-trusted contributions or projects when they could reach internal files, network resources, tools, or credentials available to the shared account.

Where should iOS signing credentials be available?

Make signing credentials available only to an approved signing identity and the jobs that need them. Keep ordinary test jobs off that credential path through Runner assignment, project trust rules, and account permissions. Verify Keychain access in the actual job context, retain access-change and credential-use evidence, and define revocation and rotation procedures. If the boundary cannot be proved, use a separate signing environment or delay release use.

For teams comparing a self-managed Mac build host with remote capacity, the right choice depends on the operational boundary as well as the hardware. A locally purchased Mac can mean upfront procurement, maintenance ownership, and a recovery process tied to local staff; a shared host can also leave project trust and credential separation unresolved. Renting a Mac does not remove those security decisions, but it can be worth evaluating when capacity is temporary or a dedicated test environment is needed. Review the published NUKCLOUD remote Mac service information and available ordering options, then confirm access methods, login recovery conditions, and delivered configuration before committing. If the workload needs sustained heavy use or a physical interface, a remote rental may not fit; if it is a pilot or temporary CI node, compare the actual recovery and access evidence with the current setup before deciding.