Codex Remote sur Mac en 2026 : guide de déploiement

Le bon hôte se choisit avant l’installation

Le premier piège consiste à considérer Codex Remote comme un simple bureau distant. Le téléphone sert de plan de contrôle : il envoie des consignes, reçoit les sorties et affiche les demandes d’approbation. Le Mac connecté fournit, lui, le dépôt, le système de fichiers, le terminal, les accès aux sites, les outils locaux, les extensions et les autorisations réellement disponibles. (documentation officielle des connexions Remote)

Cette séparation crée au moins quatre contraintes concrètes.

• La disponibilité dépend de l’hôte. Si le Mac s’endort, perd le réseau ou ferme l’application de bureau, l’accès distant s’arrête jusqu’à son retour.
• Les secrets suivent l’environnement local. Une clé SSH, un fichier .env, une session de navigateur ou un accès à un service de déploiement ne sont pas transférés magiquement vers le téléphone. Ils restent utilisables sur la machine qui les possède.
• La concurrence dégrade le poste principal. Une compilation iOS, un rendu vidéo, une analyse audio ou plusieurs agents travaillant sur des branches différentes peuvent monopoliser le stockage, le réseau ou les outils de développement.
• Le verrouillage n’est pas une garantie générale de continuité. La condition opérationnelle reste un hôte éveillé, connecté et capable d’exécuter l’application de bureau. Le comportement exact du verrouillage, de la fermeture du capot et de Computer Use doit être vérifié pour la version installée ; il ne faut pas le déduire d’une démonstration ou d’un commentaire communautaire.

La règle de décision est simple :

• choisissez le Mac principal pour une correction ponctuelle, un test local ou une tâche qui doit rester sous surveillance ;
• choisissez un Mac dédié si la tâche doit rester accessible pendant les absences, si plusieurs projets doivent cohabiter ou si les credentials doivent être séparés ;
• choisissez un Mac distant administré si l’environnement doit être réinitialisable, transmissible à une équipe ou disponible sans laisser le poste personnel allumé.

Pour des usages créatifs, cette distinction est particulièrement importante : un projet de montage vidéo, de design d’interface ou de traitement audio peut nécessiter des applications locales et des volumes de travail qui ne doivent pas entrer en concurrence avec un agent de programmation.

Première étape : vérifier la compatibilité et le périmètre du compte

Avant de scanner un code QR, il faut mettre à jour les deux extrémités et clarifier le périmètre réel de la fonction.

La documentation actuelle indique que Remote prend en charge un hôte équipé de l’application de bureau sur macOS ou Windows, avec contrôle depuis l’application mobile sur iOS ou Android. La disponibilité peut encore dépendre du déploiement progressif, du compte et de l’espace de travail. Dans un espace géré, l’administrateur peut devoir activer l’accès Remote Control. (documentation officielle des connexions Remote)

Pour l’application macOS actuelle, les exigences publiées comprennent macOS 14 et un processeur Apple Silicon M1 ou ultérieur, ou un processeur Intel. Une ancienne version de macOS ne doit donc pas être présumée compatible simplement parce qu’elle exécutait auparavant un outil Codex. (exigences système officielles de l’application macOS)

La vérification peut commencer par les commandes suivantes, qui ne modifient pas le projet :

sw_vers -productVersion
uname -m
which codex
codex --version

Un résultat exploitable ressemble à ceci :

ProductVersion: 14.x
arm64
/opt/homebrew/bin/codex
codex 26.x

La version exacte peut évoluer ; elle doit être comparée à la documentation et à l’interface affichée au moment du déploiement, plutôt qu’inscrite définitivement dans une procédure interne.

Le compte utilisé sur le Mac et celui de l’application mobile doivent également pointer vers le même compte et le même espace de travail. Une authentification multifacteur, une connexion SSO ou une clé d’accès peuvent être demandées pendant l’association.

Le téléphone peut-il se connecter à un Mac qui exécute déjà Codex ?
Oui, si le Mac exécute l’application de bureau actuelle, reste éveillé et en ligne, et utilise le même compte et le même espace de travail. Le téléphone n’exécute toutefois pas les commandes : il consulte et pilote une session déjà attachée à l’hôte.

Deuxième étape : effectuer l’appairage depuis le Mac

L’appairage doit commencer sur la machine qui exécutera réellement le projet. Le flux documenté ne part ni du terminal Codex ni de l’extension d’éditeur.

1. Ouvrez l’application de bureau sur le Mac hôte.
2. Accédez à Réglages, puis Connexions.
3. Choisissez Contrôler ce Mac ou ce PC, puis Configurer ou Ajouter.
4. Validez l’accès distant et la vérification demandée.
5. Scannez avec le téléphone le code QR présenté par le Mac.
6. Confirmez dans l’application mobile le même compte et le même espace de travail.
7. Terminez l’authentification multifacteur, SSO ou par clé d’accès si elle est demandée.
8. Vérifiez que le Mac apparaît dans l’onglet Remote.

Les appareils doivent être appairés individuellement avec chaque hôte contrôlé. Une équipe qui ajoute un Mac de secours ne doit donc pas supposer que tous les téléphones autorisés le verront automatiquement.

Après l’association, vérifiez dans les réglages de l’hôte les appareils autorisés, l’option de maintien éveillé, Computer Use et, si nécessaire, l’extension Chrome. Ces options modifient le périmètre de ce que l’agent peut faire ; elles ne doivent pas être activées par habitude.

Troisième étape : isoler le dépôt avant la première tâche

La première tâche ne doit pas viser la branche principale ni un dépôt contenant immédiatement des secrets de production. Il est préférable de préparer un dépôt de test avec une branche jetable ou un worktree.

git status --short
git branch --show-current
git worktree add ../codex-remote-test -b codex/remote-test
cd ../codex-remote-test
git status --short

La sortie attendue doit montrer un répertoire propre et une branche explicitement dédiée :

codex/remote-test

Le premier objectif est de vérifier quatre éléments :

• le dossier ouvert correspond bien au dépôt prévu ;
• la branche ou le worktree est celui attendu ;
• les tests peuvent être lancés sans toucher à la production ;
• le téléphone affiche les différences, les résultats et les sorties de terminal.

Le modèle de permission doit ensuite être documenté séparément pour chaque action.

• Modification de fichiers : autoriser uniquement le dossier du projet choisi.
• Commandes Shell : conserver une approbation humaine pour les commandes destructrices, les migrations et les opérations hors dépôt.
• Accès réseau : ne l’activer que pour les dépendances, API ou environnements explicitement nécessaires.
• Computer Use : le réserver aux tâches qui ont réellement besoin d’un navigateur ou d’une application graphique.
• Outils externes et serveurs MCP : les traiter comme des accès supplémentaires, avec une identité et un périmètre propres.

L’application Codex utilise un cloisonnement configurable et demande par défaut une autorisation pour certaines commandes élevées, notamment celles qui nécessitent l’accès réseau. Les règles de projet ou d’équipe peuvent néanmoins modifier ce comportement ; elles doivent donc être relues avant de confier un dépôt sensible à un agent.

Comment limiter un dépôt, les commandes et les clés sans bloquer toute la tâche ?
Il faut commencer par un dépôt isolé, une branche non protégée, un compte local sans privilège administrateur et des variables d’environnement qui ne contiennent pas de secrets de production. Les commandes réseau, les suppressions, les migrations et les publications doivent rester soumises à approbation. La réduction du périmètre est plus fiable qu’une simple consigne écrite dans le prompt.

Quatrième étape : lancer une tâche courte et observer le contrôle mobile

La première demande doit être volontairement réversible. Une bonne tâche de validation peut demander à Codex d’inspecter le projet, d’expliquer le point d’entrée, d’ajouter un test simple et de ne rien publier.

Exemple de consigne :

Inspecte uniquement ce worktree.
Ne modifie pas la branche principale.
Ajoute un test réversible pour le module indiqué.
N'utilise pas le réseau sans approbation.
À la fin, résume les fichiers modifiés et les commandes exécutées.

Depuis le téléphone, contrôlez ensuite :

• l’arrivée du fil de tâche dans Remote ;
• l’affichage des questions et demandes d’autorisation ;
• la visibilité des sorties de terminal ;
• la présence du diff ;
• le résultat des tests ;
• la possibilité d’envoyer une instruction complémentaire ;
• l’arrêt de la tâche avant toute opération externe.

L’application mobile peut afficher le contexte du projet, les validations, les captures, les sorties de terminal, les différences et les résultats de test. Codex n’est pas pour autant sélectionnable comme une session locale complète depuis le Web ou le mobile ; l’accès aux conversations de bureau prises en charge passe par l’onglet Remote.

Il est utile de tester deux modes de supervision.

• Queue : ajouter une instruction qui devra être traitée après la fin ou l’étape courante, par exemple demander un second contrôle des tests.
• Steer : corriger immédiatement la direction lorsque l’agent travaille sur la mauvaise hypothèse, le mauvais dossier ou une stratégie devenue manifestement inadaptée.

Queue convient à une suite logique déjà prévue. Steer doit rester réservé aux corrections de trajectoire ; l’utiliser pour empiler des exigences contradictoires rend la session difficile à auditer.

Cinquième étape : rendre l’hôte réellement disponible pendant une longue tâche

Une longue tâche dépend moins du téléphone que de la continuité de l’hôte. Si la machine dort, perd son réseau ou ferme l’application, l’accès s’interrompt. Sur un Mac portable, le capot fermé peut nécessiter un écran externe, tandis que le choix explicite du mode veille arrête l’accès distant.

Pour un Mac dédié, la préparation doit inclure :

• alimentation permanente ;
• connexion réseau stable ;
• réglage de maintien éveillé lorsque l’option est disponible ;
• espace disque suffisant pour les dépendances, journaux et worktrees ;
• compte utilisateur séparé du compte quotidien ;
• redémarrage contrôlé après une mise à jour ;
• procédure de reconnexion de l’application de bureau ;
• test de reprise après perte réseau volontaire.

Une vérification locale peut confirmer les réglages d’alimentation, sans prétendre garantir le comportement de toutes les versions de macOS :

pmset -g custom
pmset -g assertions

Le résultat doit être interprété avec prudence. Une machine qui refuse la mise en veille n’est pas forcément capable de poursuivre une tâche si l’application est fermée, si l’utilisateur est déconnecté ou si un outil graphique attend une interaction. Pour Computer Use, le comportement doit suivre la documentation de la version active et un test contrôlé ; il ne faut pas considérer le verrouillage de session comme équivalent à une exécution sans surveillance.

Codex Remote continue-t-il après le verrouillage du Mac ?
La réponse opérationnelle ne doit pas être « oui » ou « non » sans préciser le cas. La condition officiellement documentée est que l’hôte soit éveillé, connecté et que l’application de bureau fonctionne. Le verrouillage, la fermeture du capot et les tâches qui utilisent Computer Use peuvent avoir des contraintes propres. Il faut donc valider chaque scénario sur l’environnement retenu, puis conserver une tâche d’essai avant de lui confier un dépôt important.

Pour des travaux de design, d’audio ou de vidéo, cette vérification est encore plus importante : l’agent peut continuer une opération textuelle ou de terminal, alors qu’une application graphique ouverte, une fenêtre de confirmation ou un périphérique indisponible peut interrompre le flux.

Sixième étape : ajouter des contrôles avec Codex Hooks

Les Hooks permettent d’injecter des scripts déterministes dans le cycle de Codex. Ils peuvent servir à rechercher des secrets dans les prompts, lancer des validations, journaliser les échanges ou appliquer des règles propres à un dépôt. Les Hooks non gérés doivent être examinés et approuvés avant leur exécution. (documentation officielle des Hooks)

Un emplacement de dépôt typique est :

<repo>/.codex/hooks.json

Un contrôle de validation peut ressembler à ceci, à adapter à la syntaxe documentée de la version installée :

{
  "hooks": {
    "Stop": [
      {
        "type": "command",
        "command": "./scripts/check-remote-task.sh"
      }
    ]
  }
}

Le script appelé doit rester lisible, versionné et testable sans privilège élevé :

#!/bin/zsh
set -eu

if git diff --name-only | grep -E '(^|/)(\.env|credentials|secrets)' >/dev/null; then
  print "Fichier sensible détecté : validation manuelle requise" >&2
  exit 1
fi

git diff --check

Un tel contrôle ne remplace ni la gestion des secrets ni la revue humaine. Il ajoute une barrière vérifiable avant la fin de session. Les Hooks peuvent être chargés depuis plusieurs niveaux de configuration ; si plusieurs Hooks correspondent au même événement, ils peuvent tous s’exécuter, et des commandes correspondantes peuvent démarrer en parallèle. Cette propriété doit être prise en compte pour éviter des journaux incomplets ou des validations concurrentes.

Les clés API, certificats de signature et identifiants de production doivent rester hors du dépôt et hors des prompts. Pour une équipe, il faut privilégier des comptes de service limités, des clés séparées par environnement et une rotation planifiée. En cas de doute, la tâche doit être arrêtée avant d’ajouter un secret au Mac distant.

La checklist d’acceptation avant de laisser Codex travailler seul

• [ ] Le Mac hôte utilise une version de macOS et une application de bureau compatibles.
• [ ] Le téléphone et le Mac utilisent le même compte et le même espace de travail.
• [ ] L’appairage QR a été réalisé depuis l’hôte prévu.
• [ ] Le dépôt de test est isolé de la branche principale.
• [ ] Les commandes réseau et destructrices demandent une approbation.
• [ ] Les fichiers .env, clés SSH et certificats de production ne sont pas présents dans le dépôt.
• [ ] Le Mac reste alimenté, connecté et éveillé pendant la durée prévue.
• [ ] Une coupure réseau contrôlée a été testée.
• [ ] Le téléphone affiche les sorties, les différences et les résultats de test.
• [ ] Une procédure d’arrêt manuel de la tâche est connue.
• [ ] Les Hooks ont été lus, exécutés avec un compte limité et validés.
• [ ] Les appareils autorisés peuvent être retirés depuis les réglages de connexion.
• [ ] Les clés SSH peuvent être révoquées ou remplacées sans interrompre les autres projets.

Après sept jours : garder le Mac principal ou migrer

La validation ne doit pas se limiter à « le téléphone a réussi à se connecter ». Pendant la première semaine, il faut relever les interruptions, les temps d’attente d’approbation, les erreurs de contexte, les conflits entre projets et le temps nécessaire pour remettre l’environnement en état.

Le Mac principal reste pertinent si les tâches sont courtes, peu nombreuses et exécutées sur des dépôts peu sensibles. Un Mac dédié devient préférable lorsque le poste personnel doit rester libre pour du montage, du design, de l’audio ou du travail quotidien, ou lorsque plusieurs agents doivent utiliser des worktrees et des outils différents.

Un environnement SSH ou un Mac distant administré est plus cohérent si le projet vit déjà sur une machine distante. Cette architecture ne doit pas être confondue avec Codex Remote mobile. Dans le premier cas, l’application de bureau ouvre un projet sur un hôte SSH ; dans le second, le téléphone contrôle une session accessible depuis un Mac ou un environnement déjà relié. Le choix dépend donc du lieu où résident les fichiers, les dépendances, les politiques et les secrets.

Si le Mac personnel doit rester constamment sous tension, si plusieurs tâches se disputent le même environnement ou si personne ne sait clairement qui peut approuver une commande, le montage local atteint rapidement ses limites. Il faut alors comparer une machine dédiée, un environnement SSH administré et un Mac cloud prêt à déployer, notamment selon le besoin de réinitialisation, de remise à une autre personne et de séparation des projets.

Le choix final pour un déploiement durable

Le Mac principal coûte moins cher à mettre en route, mais il mélange les projets personnels, les sessions de navigateur, les clés, les applications créatives et les tâches Codex. Il impose aussi de le laisser disponible et peut perturber les travaux audio, vidéo ou de design.

Un Mac dédié améliore l’isolation et la prévisibilité, mais il faut encore gérer l’alimentation, les mises à jour, le réseau et la récupération après incident. Un Mac distant proposé par NodeMini ajoute une couche de livraison et de contrôle qui peut être plus adaptée lorsque l’environnement doit être temporaire, réinitialisable ou transmissible à une équipe. La décision est moins liée à la puissance brute qu’à la durée des tâches, au niveau de confidentialité et au coût d’une interruption.

Pour une expérimentation courte, le Mac principal suffit. Pour une semaine de tâches continues, plusieurs projets ou des credentials séparés, le Mac dédié devient le choix raisonnable. Lorsque l’équipe veut éviter l’achat d’une machine, ne souhaite pas laisser un poste personnel allumé et a besoin d’un environnement accessible à distance, il est pertinent d’examiner les solutions de Mac cloud NodeMini avant de basculer la charge de travail.