2026 Petites équipes : persistance tmux sur Mac distant partagé — matrice, isolation et anti-préemption

Les échecs « aléatoires» viennent le plus souvent de prémisses qui se chevauchent : un développeur garde un shell interactif pour des invites sudo ou un outil graphique, pendant que la CI suppose des chemins figés, des caches non partagés et aucune interaction. Sur un même compte ou une même racine de clone, vous obtenez des processus fantômes après déconnexion, des pod install doublonnés, des courses sur le Simulateur et des rapports « ça marchait dans mon tmux » irreproductibles en automation.

Préemption, ici, désigne tout travail prioritaire — ou un autre job détenant un verrou — qui invalide l’histoire que votre session racontait : l’attache humaine n’est pas magiquement prioritaire sur le flock de la CI sauf si vous l’encodez dans des couloirs, labels et nœuds séparés. Les conventions de nommage aident les humains ; les groupes POSIX et arbres distincts aident la machine. Pour les quotas et files côté « pool » partagé, croisez avec la FAQ pool Mac : file, quotas et conflits.

Documentez quels chemins sont mutable partagé, quelles sessions peuvent s’attacher en parallèle, et quelles opérations restent sérielles par ressource — le même langage que vos runbooks de file et de verrous.

En résumé : tmux règle la durabilité du transport, pas le multilocation. Associez-le à des comptes builder dédiés pour la CI et des comptes humains distincts, et évitez les sessions longues sur des chemins qui recouvrent les racines d’automation sans orchestration explicite.

Diffusez une base d’équipe dans ~/.tmux.conf (ou /etc/tmux.conf sur hôtes gérés) : préfixe, historique et terminal cohérents avec Terminal.app et les clients SSH modernes. Objectif : prévisibilité, pas la décoration.

• set -g mouse on — molette et sélection de volets.
• set -g history-limit 50000 — tampon pour logs Xcode ; réduisez sur petites VM.
• set -g default-terminal "screen-256color" (ou tmux-256color si terminfo présent).
• setw -g aggressive-resize on — dimensions à jour avec plusieurs clients.
• set -g detach-on-destroy off — moins de pertes de session entière quand un volet se termine.

Nommage opérationnel : imposez tmux new -s initiales-ticket ou pool-ci-couloir-2 — interdisez les sessions anonymes sur les hôtes pool. Couplez ClientAliveInterval / ClientAliveCountMax côté sshd_config avec ServerAliveInterval côté client : tmux survive aux coupures, mais les timeouts NAT idle réclament des keepalive explicites.

Matrice de décision rapide (persistance / files)

1. 1
   Identités séparées : comptes du type builder-ci et dev-partage (ou par personne). La CI ne se connecte jamais comme l’utilisateur principal d’un humain.
2. 2
   Groupe d’abord : sur /srv/builds (exemple), groupe POSIX builders, chmod 2770 sur les répertoires à héritage d’écriture de groupe, umask 027 dans les profils concernés.
3. 3
   Racines par développeur : /srv/builds/<user>/… ou worktrees Git disjoints — aligné avec votre politique lockfile / builds parallèles.
4. 4
   ACL ciblées (macOS) : lecture break-glass sur journaux ; évitez un staging de build world-writable sous /tmp.
5. 5
   Trousseau et codesign : trousseaux de connexion séparés par rôle si possible ; pas de session Apple ID partagée entre personnes — recoupez avec la fiche SSH/VNC liée en tête d’article.

Vérifiez avec namei -l depuis chaque compte jusqu’à la racine de build ; planifiez un audit mensuel (ou MDM) qui signale les 777 et les caches passés en propriété exclusive par erreur.

Pourquoi lier tmux à flock ? Un shell durable incite à des processus longs qui retiennent des verrous consultatifs ou des ressources implicites (Simulateur, USB, UI trousseau). La politique de session et la politique de file doivent raconter la même histoire.

Plafond de jobs en attente : viser environ vingt jobs pending par couloir (ou global) pour que la saturation soit une erreur lisible — détail et réglages dans la FAQ flock et file déjà citée.

Attente de verrou vs timeout job : flock -w doit rester nettement inférieur au timeout CI. Si un volet tmux attend des heures, vous avez un détenteur bloqué ou une section critique trop large — traitez le détenteur avant d’accuser le réseau.

Équité interactif / automation : sur hôte mixte, flock -n côté CI pour échouer vite vers un autre nœud ; les humains utilisent des -w courts pour des mises à jour de cache volontaires.

Alertes : médiane d’attente soutenue au-delà d’environ quinze minutes et rafales de timeouts de verrou — les mêmes signaux qui justifient de louer un Mac supplémentaire pour un couloir sériel ou interactif dédié.

1. 1
   Publier la convention de noms de session et une seule procédure attach/detach ; bannir tmux anonyme sur les pools.
2. 2
   Aligner couloirs tmux et labels runner : pas de parallélisme YAML « caché » sur un seul cache mutable.
3. 3
   Limiter dans le temps les verrous interactifs ; escalader avec runner, PID et chemin du lock journalisés.
4. 4
   Revue mensuelle : sessions tmux orphelines, simulateurs zombies, répertoires devenus trop permissifs.
5. 5
   Scaler en nœuds avant d’augmenter la concurrence YAML : si la liste se répète chaque semaine, un second Mac loué coûte moins cher en heures humaines qu’un incident permanent.

tmux rend le Mac distant partagé utilisable sous réseau capricieux ; groupes, répertoires et files le rendent exploitable pour une petite équipe. La matrice est simple : la persistance répare les déconnexions, mais seuls des nœuds supplémentaires et des couloirs sériels explicites réparent la contention. Standardisez le tmux.conf minimal, nommez chaque session, et gardez les chiffres flock / profondeur de file alignés avec la CI.

Avant d’ajouter un troisième volet, louez un second Mac pour l’interactif ou le signing lourd. Parcourir les forfaits et offres (sans compte pour comparer), le centre d’aide pour SSH et bonnes pratiques, le blog pour le routage runner et le mesh. Lectures proches : collaboration multi-nœuds OpenClaw sur Mac mesh et guide de mise en place d’un nœud de build Mac partagé. Accueil Meshmac pour choisir un nœud adapté à votre équipe.