How do queue depth caps relate to tmux persistence on a shared remote Mac?

Queue depth caps (often around twenty pending jobs per lane) prevent silent backlog while long-lived tmux sessions stay attached. When orchestrator pending jobs exceed the cap, fail fast with a message to retry or use another node rather than stacking processes that all assume exclusive access to shared caches.

What flock lock-wait thresholds pair with interactive tmux workflows?

Use shorter flock -w windows for interactive developers (roughly thirty to one hundred twenty seconds) so a stuck CI job does not block manual work indefinitely; pair with the build queue FAQ values for dependency installs (roughly one hundred twenty to three hundred seconds) and ensure lock-wait is always below per-job timeouts.

When should a team rent a second Mac instead of adding more tmux panes?

Add nodes when median queue wait exceeds your SLA, when serial lanes cannot be isolated on one host, or when GUI-only workflows (Simulator, codesign prompts) collide with headless CI regardless of tmux naming and ACLs.

2026 Shared Remote Mac Session Persistence: tmux Matrix, Permission Isolation & Preemption Checklist

A shared remote Mac fails in predictable ways: someone’s long compile dies because Wi‑Fi blinked, two engineers attach to the “same” interactive shell, or CI and humans fight over one mutable cache. tmux is not a security boundary, but it is a coordination primitive—paired with directory ACLs, named sessions, and the same queue and flock thresholds you already use for builds, you get durable shells without pretending one host is infinitely parallel. This page is for tech leads and on-call: conflict scenarios, a comparison table, a copy-paste tmux baseline, isolation steps, FAQ numbers, and a preemption checklist. Pair it with our build queue and flock FAQ and SSH/VNC permission isolation FAQ.

Shared Node Conflict Scenarios

Most “random” failures on pooled Macs are overlapping assumptions. Interactive developers expect a stable TTY for sudo prompts, fast iteration, and occasional GUI tools; CI runners expect unattended shells, deterministic paths, and non-interactive signing. When both land on one account or one workspace root, you see ghost processes after disconnect, duplicated pod install runs, Simulator boot races, and “it worked in my tmux” reports that do not reproduce under automation.

Preemption here means any higher-priority workload—or simply another job with a lock—invalidates the story your session was telling: a human’s attach is not more special than CI’s flock unless you encode that in lanes, labels, and separate nodes. Naming conventions help humans; POSIX groups and separate trees help the machine. For multi-agent and mesh-style collaboration patterns that span more than one host, see OpenClaw multi-node collaboration on Mac mesh.

Treat these as design inputs, not blame: document which paths are shared mutable, which sessions may attach concurrently, and which operations must stay serial per resource—the same vocabulary as your queue runbooks.

tmux vs Bare SSH Session: Comparison Table

Dimension	Bare SSH session	tmux (named, team policy)
Survives disconnect	No—SIGHUP takes the shell unless `nohup` / disown hacks	Yes—reattach with `tmux attach -t NAME`
Multi-pane visibility	One stream; copy/paste only	Split panes/windows; shared scrollback if policy allows
Coordination / audit	Hard to know who owns the shell	Session names map to people, tickets, or lanes
Isolation from CI	Weak—same user = same files	Still weak without separate users and paths
Risk if misused	Lost work on flaky networks	“Forever” sessions hide stale env, wrong Xcode select

Bottom line: tmux solves transport durability, not tenancy. Combine it with separate OS users or dedicated builder accounts for CI versus humans, and keep long-lived sessions on paths that never overlap automation roots unless orchestrated.

Session Persistence Decision Matrix

Signal	Prefer	Escalation
Flaky laptop VPN; need reconnect	tmux + SSH keepalives	Document attach command in team wiki
One shared cache (Pods, npm)	Serial lane + `flock`	Second node or cache partition
GUI tests + headless CI same host	Split nodes or strict time windows	Dedicated Simulator host
Ad-hoc debugging on prod-like Mac	Break-glass user + ephemeral clone	Rotate creds after session

Minimal tmux Configuration Parameters

Ship a team baseline in ~/.tmux.conf (or /etc/tmux.conf for managed hosts) so scrollback, prefix keys, and terminal features match modern macOS terminals. The goal is predictability, not aesthetics.

set -g mouse on — enables scroll wheel and pane selection in Terminal.app and most SSH clients.
set -g history-limit 50000 — enough buffer for long Xcode logs without unbounded RAM growth; tune down on very small VMs.
set -g default-terminal "screen-256color" (or tmux-256color if terminfo installed) — reduces color and key quirks over SSH.
setw -g aggressive-resize on — avoids stale dimensions when multiple clients attach.
set -g detach-on-destroy off — keeps unrelated windows alive when one pane exits (fewer accidental full-session loss).

Operational naming: enforce tmux new -s team-initials-ticket or pool-ci-lane-2—never default unnamed sessions on shared hosts. Publish a one-liner wrapper script in your internal repo so onboarding is copy-paste.

Pair server-side ClientAliveInterval / ClientAliveCountMax in sshd_config with client ServerAliveInterval; tmux survives drops, but idle NAT timeouts still benefit from explicit keepalives.

User and Directory Permission Isolation Steps

Split identities: create builder-ci and dev-shared (or per-person) accounts. CI never logs in as a human’s primary user.
Group-first ownership: for shared trees such as /srv/builds, use a POSIX group (for example builders), chmod 2770 on directories that must inherit group write, and umask 027 in shell profiles for those accounts.
Per-developer work roots: /srv/builds/<user>/... or per-repo Git worktrees under disjoint paths—align with your lockfile and parallel-build policy.
ACLs only where needed: on macOS, supplement default ACLs for Break-glass read-only access to logs; avoid world-writable /tmp build staging.
Keychain and codesign: separate login keychains per role where feasible; never share Apple ID–bound sessions across people—map to the permission isolation FAQ for VNC and signing boundaries.

Verify with namei -l from each account’s home through the build root, and add a monthly cron or MDM audit that flags directories that drifted to 777 or user-only ownership on shared caches.

Build Queue and File Lock Threshold FAQ

Why tie tmux to flock at all? Because a durable shell encourages long-running processes that hold advisory locks or implicit resources (Simulator, USB, keychain UI). Your shell policy and your queue policy must tell the same story.

Pending job cap: keep global or per-lane pending depth near twenty so saturation surfaces as a clear error—details and tuning live in the flock and build queue FAQ.

Lock-wait vs job timeout: flock -w should stay well below the CI job timeout. If a developer’s tmux pane waits hours, you have either a stuck holder or a critical section that is too large—fix the holder before blaming the network.

Interactive fairness: for shared hosts mixing humans and automation, prefer flock -n on CI so jobs fail fast to another node, while humans use shorter -w windows for deliberate cache updates.

Alerting: alert on median wait crossing roughly fifteen minutes sustained and on repeated lock timeouts in a sliding window—the same signals that justify renting an additional Mac for a dedicated serial lane.

Build Session Preemption Avoidance Checklist

1
Publish session naming and a single attach/detach doc; ban anonymous tmux on pooled hosts.
2
Map tmux lanes to runner labels so CI concurrency groups match real isolation—no hidden parallelism on one cache.
3
Time-box interactive locks; escalate stuck holders with runner id, PID, and lock path logged.
4
Review monthly: orphaned tmux sessions, zombie simulators, and directories that slipped to overly permissive modes.
5
Scale out before raising concurrency: add a second rented node for GUI or signing lanes when checklist items recur weekly.

Summary, Multi-Node Guidance & Next Steps

tmux makes shared remote Macs usable under flaky networks; groups, directories, and queues make them safe enough for small teams. The decision matrix is simple: persistence fixes disconnects, but only extra nodes and explicit serial lanes fix contention. Standardize the minimal tmux.conf, name every session, and keep flock and pending-depth numbers aligned with your CI runbooks.

When you outgrow one host, rent a second Mac for interactive or signing-heavy work before you add a third pane. Use the Meshmac homepage to compare hardware tiers and browse nodes without logging in; open plans & pricing for team capacity, help for SSH and security basics, and the blog index for pool quotas, runner routing, and mesh collaboration. Related reads: shared pool FAQ and conflict checklist and multi-node collaboration on Mac mesh.

Standardize Sessions—or Add a Node

Meshmac remote Macs fit small-team pools with SSH and VNC. Paste the tmux baseline into your runbook, align flock thresholds with your queue policy, and scale to multiple nodes when the checklist stops being theoretical.

Rent a Mac (no login to browse) Plans & pricing Help center All blog posts

Prefer boring infrastructure: named tmux sessions on every shared host, two nodes before heroic concurrency, and the same queue numbers in YAML and runbooks.