2026 Small-Team Shared Remote Mac: Git Credential Helper per Account, Concurrent Pulls & Token Rotation Matrix

Pair this guide with the Jump Host and SSH certificate rotation matrix for network ingress, and with secrets with minimum permissions on mesh nodes when OpenClaw or other gateways also hold tokens. For branch-level disk isolation, see the Git worktree and lockfile matrix—credentials and worktrees fail together when both are sloppy.

SSH user certificates vs HTTPS + credential helper

Small teams usually pick one transport and regret it later. SSH shines when you already operate a certificate authority and want non-exportable, short-lived machine identity. HTTPS with a personal access token (PAT) or GitHub App installation token fits vendors that ban SSH, or when you need per-repository scope in a single URL. Neither is “more secure” without partitioning and rotation discipline.

Keychain partitioning and includeIf

On macOS, git credential-osxkeychain stores secrets in the login Keychain. Without care, two automation users writing to the same service URL overwrite each other. Partition in three layers: per-path HTTPS credentials (useHttpPath), split Git config files via includeIf "gitdir:…", and separate SSH identities per org or customer. Interactive developers should avoid sudo to a shared service account—that flattens Keychain context and reproduces “random user” bugs under load.

• HTTPS: set credential.useHttpPath true globally, then rely on distinct clone URLs or credential.<URL> overrides so each repo stores its own tuple.
• Config files: keep ~/.gitconfig minimal; move team-specific user.name, helper, and insteadOf rules into included files keyed by repository root.
• SSH: never rely on “first key wins” when twelve keys load into one agent; pin with IdentityFile and CertificateFile per host alias.

Concurrent pulls and conflict avoidance

Git serializes writes to .git metadata. Two jobs that hit git fetch against the same object database at the exact same time can stall or throw transient lock errors. Separate clones or worktrees reduce contention; flock around maintenance scripts still matters when you run automatic garbage collection or git maintenance on a schedule.

Token rotation runbook (PAT / App tokens)

Treat rotation as a two-phase commit: create the replacement secret, prove it with a read-only call, update storage, re-run a sample CI job, then revoke the old credential. Document which principal owns each token—mixing a human PAT into a LaunchAgent without labeling is how midnight pages happen. For GitHub, prefer fine-grained PATs limited to the smallest repo set; for organization-wide automation, a GitHub App installation token often beats long-lived PAT sprawl.

1. Inventory: list Keychain items and config files that reference github.com or your forge’s hostname.
2. Mint the new secret in the vendor UI; avoid reusing names that collide in Keychain search.
3. Update git credential approve or store via a controlled script; never echo tokens into shared shell history.
4. Verify with GIT_TERMINAL_PROMPT=0 git ls-remote from the same user context as production jobs.
5. Revoke the old token only after green checks; keep a rollback window of hours, not minutes, for multi-repo fleets.

Least-privilege acceptance checklist

• Transport: SSH CA or HTTPS path-scoped tokens are chosen explicitly; nobody uses embedded passwords in remote URLs.
• Scope: tokens grant read-only where CI only pulls; writers are limited to release lanes.
• Storage: helper files are 0600; no world-readable .netrc in shared home directories.
• Agents: interactive and automation sessions do not share one unnamed SSH agent socket unless identities are pinned.
• Concurrency: each CI job uses its own working tree; fetch storms are capped or staggered.
• Audit: mapping from Keychain entry to owner and rotation date is written in your internal runbook.

Executable snippets and verification

Split Git config by repository root (adjust paths):

# ~/.gitconfig
[user]
    name = Shared Builder
    email = builder@example.com
[credential]
    helper = osxkeychain
    useHttpPath = true
[includeIf "gitdir:~/builds/customer-a/"]
    path = ~/.gitconfig-customer-a
[includeIf "gitdir:~/builds/customer-b/"]
    path = ~/.gitconfig-customer-b

Per-customer HTTPS override:

# ~/.gitconfig-customer-a
[credential "https://github.com/org-a"]
    username = org-a-ro-bot

SSH host alias with pinned identity:

# ~/.ssh/config
Host github.com-org-a
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_org_a
    CertificateFile ~/.ssh/id_ed25519_org_a-cert.pub
    IdentitiesOnly yes

Verify HTTPS credential lookup (non-interactive probe):

printf "protocol=https\nhost=github.com\npath=org-a/repo.git\n\n" | git credential-osxkeychain get
GIT_TERMINAL_PROMPT=0 git ls-remote https://github.com/org-a/repo.git

Verify SSH principal:

ssh -T git@github.com-org-a

If diagnostics need HTTP traces, run a single manual GIT_CURL_VERBOSE=1 GIT_TRACE_CURL=1 git fetch in a disposable clone—never leave verbose tracing enabled in shared automation logs because it can leak Authorization headers.

FAQ

Should one shared Mac use a single global Git credential?

Avoid it for multi-customer or multi-org pools. Partition by SSH host aliases or HTTPS path-scoped secrets so rotation and blast radius stay predictable.

How do we rotate tokens without freezing CI?

Create the replacement first, validate with ls-remote, swap storage, rerun a canary job, then revoke the old token.

Why do concurrent jobs authenticate as the wrong user?

Typically shared agents, unordered SSH keys, or a global credential helper entry. Pin identities and scope HTTPS secrets per repository path.

Does Keychain partitioning replace separate macOS users?

It helps for HTTPS, but separate OS users remain the stronger boundary for interactive work; combine both when contracts demand strict separation.