Note de la rédaction : Cet article passe en revue les trois points d'entrée permettant à Codex d'interagir avec l'environnement externe : Computer Use, l'extension Chrome et le navigateur intégré à l'application. Bien que ces trois méthodes semblent toutes résoudre le problème de « permettre à Codex d'utiliser l'ordinateur », elles correspondent en réalité à différents scénarios de tâches, niveaux d'autorisation et degrés de confiance.

Parmi elles, Computer Use offre la couverture la plus large. Il peut directement manipuler les applications natives, les paramètres système, le simulateur iOS sur macOS/Windows (une fois autorisées), et même exécuter des flux de travail impliquant plusieurs applications. Il est adapté aux processus d'interface graphique qui ne sont pas pris en charge par des API, des extensions ou des outils structurés, mais au prix d'une vitesse plus lente et de limites d'autorisation plus étendues. L'extension Chrome, quant à elle, convient aux tâches dépendant d'un état de connexion, de cookies, de plusieurs onglets et de l'identité du navigateur, comme Gmail, LinkedIn, Salesforce, des back-office internes, ou des recherches nécessitant une connexion sur plusieurs sites. Le navigateur intégré (Browser) est plutôt orienté vers les scénarios de développement et de débogage, particulièrement adapté aux services locaux, aux bugs visuels, aux mises en page responsives et aux annotations de design. Il n'hérite pas des états de connexion du navigateur normal de l'utilisateur, ses capacités sont plus limitées, mais son isolation est également plus forte.

Le jugement central de l'article est que Codex n'a pas qu'une seule façon « d'utiliser l'ordinateur ». Ce qui est vraiment important, c'est de choisir l'interface d'opération la plus étroite, la plus sûre et la plus structurée en fonction de la tâche. S'il est possible d'utiliser une extension ou MCP, il ne faut pas recourir en premier lieu au contrôle visuel. Si la tâche concerne uniquement le développement web, privilégiez le navigateur intégré (Browser). Lorsque l'identité et l'état de connexion du navigateur de l'utilisateur sont nécessaires, passez alors à Chrome. Computer Use ne devrait être utilisé qu'en « dernier kilomètre », uniquement lorsque les outils structurés ne peuvent pas couvrir la tâche et que celle-ci dépend nécessairement de l'interface graphique du bureau.

Les Appshots ne constituent pas une quatrième méthode de contrôle de l'ordinateur, mais plutôt un outil pour « montrer à Codex » le contexte actuel de l'écran. Ils résolvent le problème de la saisie de contexte, tandis que Browser, Chrome et Computer Use résolvent le problème de l'action. Examinés ensemble, cette approche par couches révèle en réalité la clé de la mise en produit des agents IA : il ne s'agit pas de donner des autorisations illimitées au modèle, mais de restreindre constamment les autorisations, de clarifier les limites dans des tâches spécifiques, et de laisser à l'utilisateur le pouvoir d'approuver les actions critiques.

Voici l'article original :

Codex peut utiliser l'ordinateur de trois manières : Computer Use, l'extension Chrome et le navigateur intégré à l'application.

Il existe un certain chevauchement entre elles, suffisant pour créer de la confusion.

Après avoir lu cet article, vous saurez comment installer et déclencher ces trois méthodes, dans quels scénarios utiliser chacune d'elles, comment Appshots et le mode Développeur les relient, et quoi écrire dans AGENTS.md pour que Codex puisse choisir lui-même l'interface d'opération appropriée.

La version simple est :

Cela étant dit, il faut toujours privilégier les extensions ou MCP lorsque c'est possible. Par exemple, l'extension Slack permet de rechercher un thread de manière plus précise qu'en cliquant partout dans Slack ; les opérations générées par l'extension GitHub sont aussi plus faciles à vérifier que de faire piloter la page web par Codex. Le contrôle visuel est plus adapté là où les capacités des outils structurés atteignent leurs limites.

Tout peut être @Computer

Computer Use est l'interface d'opération la plus polyvalente parmi ces trois. Il permet à Codex de visualiser et d'opérer l'interface graphique sur macOS et Windows, y compris les fenêtres, les menus, la saisie clavier, ainsi que le presse-papiers dans les applications que vous avez autorisées.

C'est aussi généralement le plus lent. Les extensions structurées peuvent directement appeler une API ; Computer Use doit observer l'interface, déterminer où cliquer, attendre la réponse de l'application, puis vérifier l'état suivant. Cette boucle visuelle consomme du temps, mais signifie également que Codex peut manipuler des applications qui n'ont absolument aucune API disponible.

Sur macOS, « lent » ne signifie pas nécessairement qu'il va vous déranger. Computer Use peut fonctionner en arrière-plan sur les applications que vous avez autorisées, tandis que vous pouvez continuer à utiliser d'autres parties de l'ordinateur. Souvent, en ouvrant une application pendant que j'utilise Codex, je découvre que Codex a déjà tranquillement terminé un flux de travail en arrière-plan.

Selon les applications installées et autorisées sur votre ordinateur, ces objets d'opération peuvent inclure Spotify, Xcode, les Paramètres Système, le simulateur iOS, ou même le contrôle de votre iPhone via iPhone Mirroring. Il peut également basculer entre plusieurs applications pour traiter des flux de travail transversaux.

Utilisez-le lorsque la tâche dépend :

D'applications de bureau natives, comme Spotify ou des applications financières ;

Du simulateur iOS, d'iPhone Mirroring, ou d'autres processus accessibles uniquement via une interface graphique ;

Des paramètres système ou d'application ;

De sources de données sans extension ou API ;

De flux de travail nécessitant de basculer entre plusieurs applications ;

D'une dernière étape manquante dans une intégration structurée.

Installation : Ouvrez Codex > Settings > Computer Use, puis cliquez sur Install.

Déclenchement : Mentionnez @Computer, ou demandez explicitement à Codex d'utiliser Computer Use. À mesure que les capacités du modèle s'améliorent, il pourra aussi l'appeler lui-même lorsque nécessaire à l'avenir.

Vous pouvez d'abord essayer quelques exemples :

Un de mes exemples préférés est né d'un colis volé. Amazon m'a indiqué qu'il faudrait attendre environ 25 minutes pour parler à un agent. J'ai confié un thread Codex à Computer Use, lui demandant de vérifier la fenêtre de chat toutes les cinq minutes, puis toutes les minutes une fois l'agent présent, et de faire de son mieux pour obtenir un remboursement. À mon retour de la douche, le remboursement était déjà effectué.

J'utilise aussi Computer Use comme « dernier kilomètre » dans un flux de travail structuré. Dans une vidéo de mise en production, Codex pouvait lire les retours dans Slack, modifier le code et rendre une nouvelle vidéo, mais l'intégration Slack de ce thread ne pouvait pas téléverser de fichiers. Computer Use a donc cliqué sur « Add file », comblant cette étape manquante.

C'est aussi celui dont la limite de confiance est la plus large. Ne lui confiez qu'une application ou un processus précis à la fois. Gardez les applications sensibles fermées lorsqu'elles ne font pas partie de la tâche ; vérifiez attentivement les fenêtres contextuelles de permission ; pour les opérations liées aux finances, comptes, paiements, identifiants, vie privée et changements de sécurité système, il est préférable d'être présent pour superviser.

Utilisez @Chrome pour gérer les onglets multiples et les états de connexion

L'extension Codex Chrome permet à Codex d'accéder à l'état de connexion de votre Chrome déjà authentifié. Utilisez-la lorsque la tâche dépend d'un compte, de cookies, d'un profil de navigateur, ou d'onglets que vous avez déjà ouverts et authentifiés.

Cette interface est adaptée au travail dans des outils comme :

Gmail ou LinkedIn ;

Salesforce ou des back-office de support client ;

Des tableaux de bord internes ;

Des recherches nécessitant une connexion sur plusieurs sites ;

Des formulaires dépendant de votre compte ou d'extensions de navigateur.

Installation : Ouvrez Codex > Plugins, ajoutez Chrome, et suivez le processus de configuration. Codex vous guidera pour installer l'extension Codex Chrome et approuver les permissions de Chrome. Une fois que l'extension affiche « Connected », ouvrez un nouveau thread.

Déclenchement : Mentionnez @Chrome, ou demandez explicitement à Codex d'utiliser votre navigateur Chrome connecté :

Les tâches Chrome s'exécutent dans des groupes d'onglets, ce qui aide à regrouper les onglets liés à un thread Codex particulier. Contrairement au navigateur intégré, cette interface transporte l'identité de votre navigateur. Cela la rend plus puissante, mais aussi plus sensible.

Un autre avantage majeur est le contrôle multi-onglets. Chrome peut associer plusieurs onglets à une même tâche, lire le contexte sur une page, comparer des informations sur une autre, et poursuivre le flux de travail sur une troisième. Computer Use peut aussi piloter un navigateur visuellement, mais Chrome interprétera la tâche comme un flux de travail de navigateur, plutôt qu'une série d'opérations sur des coordonnées d'écran.

Récemment, dans un thread, j'ai confié à Codex un onglet Strudel Composer déjà ouvert, en lui demandant de rendre la musique plus intéressante. Chrome lui a donné l'onglet sélectionné et les outils WebMCP exposés par cette page. Codex a examiné la structure du morceau, réécrit les harmonies et la forme globale sur quatre minutes, modifié le tempo, sauvegardé le morceau et l'a laissé continuer à jouer. Il n'a pas eu besoin de chercher visuellement chaque contrôle dans l'interface, car Chrome peut combiner le contexte de l'onglet avec les capacités structurées fournies par la page.

Je l'utilise aussi pour maintenir un thread Twitter de longue durée. L'instruction approximative était :

Ce qui est intéressant, ce n'est pas que Codex puisse ouvrir Twitter, mais que ce thread puisse revenir à plusieurs reprises dans le même environnement de travail connecté, connecter le contenu découvert à des fichiers locaux, et laisser un résultat que je puisse vérifier.

La limite de confiance est ici cruciale. Les sites web peuvent interpréter les clics, soumissions de formulaires et envois de messages de Codex comme des actions que vous entreprenez vous-même. Le contenu de la page web est lui-même une entrée non fiable. Distinguez clairement les étapes à conséquences importantes : la recherche, la navigation et la rédaction peuvent être automatisées ; l'envoi, la publication, l'achat ou la soumission doivent être approuvés par vous au préalable.

Si la tâche entière se déroule dans le navigateur, privilégiez Chrome plutôt que Computer Use. Chrome possède le contexte natif du navigateur nécessaire pour ce type de tâche, sans étendre l'accès à l'ensemble du bureau.

Utilisez le navigateur intégré @Browser pour traiter les sites que vous développez

Le navigateur intégré (Browser) est un navigateur qui existe à l'intérieur d'un thread Codex. Vous et Codex partagez la même page rendue, ce qui le rend particulièrement adapté à la construction et au débogage d'applications web.

Je commence généralement par là pour traiter :

Les serveurs de développement locaux ;

Les pages de prévisualisation basées sur des fichiers ;

Les pages publiques ne nécessitant pas de connexion ;

La reproduction de bugs visuels ;

La vérification des mises en page responsives ;

Le partage de retours de design sur des éléments de page.

Sa contrainte la plus importante est l'isolation. Le navigateur intégré n'utilise pas votre profil de navigateur normal, vos cookies, vos extensions, vos sessions de connexion ou vos onglets existants. Lorsque la tâche nécessite une identité, c'est une limitation ; mais lorsque la tâche n'en a pas besoin, cela constitue une limite utile.

Configuration : Ouvrez Codex > Plugins, ajoutez et activez l'extension Browser.

Déclenchement : Mentionnez @Browser dans votre prompt, ou demandez explicitement à Codex d'utiliser le navigateur intégré :

Cela crée une boucle de rétroaction serrée : Codex peut éditer le code, manipuler la page, vérifier l'état du rendu, capturer des captures d'écran, puis revérifier le même flux après la correction.

Ma partie préférée est l'annotation. Lorsque j'examine une application locale, je peux cliquer directement sur un élément, ou sélectionner une zone et laisser un commentaire. Les contrôles de style me permettent aussi de prévisualiser et de donner un retour plus précis sur le texte, la police, l'espacement et les couleurs. Je combine souvent cela avec la saisie vocale et le guidage du processus : j'examine la page, je laisse des commentaires, et j'ajoute d'autres avis en file d'attente pendant que Codex traite le retour actuel. La page elle-même devient le cahier des charges.

C'est particulièrement utile pour le travail de design. Je demande souvent à Codex de structurer une idée, un dossier de recherche ou un état de projet en un seul fichier index.html, puis de l'ouvrir dans le navigateur intégré. Plutôt que d'essayer de décrire tout un design dans un autre prompt, je peux annoter directement sur la page réelle : « Cette hiérarchie est inversée », « Ici, ne ressemble pas trop à une carte », « Ces contrôles ont besoin de plus d'espace », ou « Utilise cette proportion de tailles de police sur tout le site ». Codex reçoit les commentaires avec les captures d'écran pertinentes et le contexte des éléments, modifie le fichier, puis rouvre la même page pour le tour suivant.

Cette boucle se rapproche davantage du travail avec un designer sur la même toile, plutôt que de s'échanger des captures d'écran et des descriptions textuelles.

Le navigateur intégré convient aussi comme point de départ pour des flux de travail hybrides. Dans un autre thread, j'ai utilisé le navigateur intégré pour ouvrir un post X, en demandant à Codex d'enquêter sur les discussions associées. La page visible l'a aidé à confirmer à quel post je faisais référence ; ensuite, Codex est passé au CLI de Twitter, a récupéré 38 réponses, y compris des réponses imbriquées masquées dans la vue navigateur. C'est une mise en pratique du principe « utiliser l'interface d'opération la plus étroite » : utiliser le navigateur pour confirmer le contexte à l'écran, puis utiliser des outils structurés pour une recherche plus approfondie.

Il y a aussi des compromis. L'isolation du navigateur intégré en fait une bonne interface de développement, mais signifie également qu'il n'est pas adapté aux sites nécessitant une connexion Google, des passkeys, ou dépendant d'extensions de navigateur. Lorsque l'identité est importante, passez à Chrome.

Appshots

Les Appshots ne sont pas une quatrième façon pour Codex de contrôler l'ordinateur. C'est une méthode pour diriger l'attention de Codex vers le contexte que vous avez sous les yeux.

Sur Mac, appuyez deux fois sur la touche CMD pour capturer la fenêtre la plus récente. Codex joindra une image et tout le texte disponible au thread. Vous pouvez faire un Appshot d'une erreur, d'un email, d'un design, d'un panneau de paramètres ou d'un formulaire inconnu, et simplement dire :

C'est le modèle mental le plus facile à retenir selon moi : les Appshots sont la façon dont vous pointez quelque chose sur votre ordinateur ; Browser, Chrome et Computer Use sont les façons dont Codex agit.

Les Appshots sont actuellement créés via l'application Codex sur macOS. Ils capturent la fenêtre la plus au premier plan, et non tout le bureau. Cela en fait un moyen utile de fournir un contexte ciblé sans accorder le contrôle de l'application concernée.

Comment suivre ces évolutions

Ces interfaces d'opération évoluent rapidement. Si vous voulez obtenir des détails pratiques sans attendre un énorme article récapitulatif :

Suivez Ari Weinstein (@AriX) pour Computer Use et Appshots ;

Suivez James Sun (@JamesZmSun) pour le contenu lié à Browser ;

Suivez Andrew Ambrosino (@ajambrosino) pour les sorties de l'application Codex et le récit produit plus large sur le bureau ;

Suivez OpenAI Developers (@OpenAIDevs) pour les nouvelles plus générales sur Codex et la plateforme OpenAI.