Tres formas en que Codex puede usar una computadora: Computer Use, la extensión de Chrome y el navegador integrado

Jason publicó en X una guía larga sobre las capacidades de Codex para usar una computadora. La pregunta práctica es sencilla: Codex ahora puede “usar una computadora” mediante Computer Use, la extensión de Chrome y el navegador integrado, pero sus límites pueden confundirse.

En resumen:

• Si un plugin o MCP puede resolver la tarea, conviene usar primero una herramienta estructurada.
• Usa @Computer cuando la tarea requiera una aplicación de escritorio, ajustes del sistema o una interfaz sin API.
• Usa @Chrome cuando la tarea dependa de tu Chrome ya iniciado, tu cuenta, cookies o varias pestañas.
• Usa @Browser cuando estés desarrollando un sitio web, depurando una página local, revisando diseño adaptable o dejando feedback visual.

El control visual es más útil justo donde las herramientas estructuradas dejan de llegar. Un plugin de Slack suele recuperar un hilo con más precisión que hacer que Codex haga clic por Slack. Un plugin de GitHub también produce acciones más fáciles de inspeccionar que manejar el sitio web. Solo tiene sentido pedirle a Codex que mire la pantalla y haga clic cuando una API, un plugin o MCP no cubre el último paso.

Publicación original: https://x.com/jxnlco/status/2066970432855581052

1. Usa @Computer para escritorio y aplicaciones nativas

Computer Use es la superficie más amplia de las tres. Permite que Codex observe interfaces gráficas en aplicaciones de macOS o Windows que hayas aprobado, y que las opere mediante ventanas, menús, teclado y portapapeles.

También suele ser la más lenta. Un plugin estructurado puede llamar una API directamente. Computer Use necesita mirar la interfaz, decidir dónde hacer clic, esperar la respuesta de la aplicación y revisar el siguiente estado. Ese bucle visual cuesta tiempo, pero permite trabajar con software que no expone una API útil.

En macOS, “lento” no necesariamente significa molesto. Computer Use puede trabajar en segundo plano dentro de aplicaciones aprobadas mientras sigues usando el resto de la computadora. Lo que puede manejar depende de lo que tengas instalado y autorizado: Spotify, Xcode, System Settings, un simulador de iOS o incluso iPhone Mirroring.

Usa @Computer para tareas que dependen de:

• aplicaciones nativas de escritorio, como Spotify, apps financieras o herramientas de diseño;
• un simulador de iOS, iPhone Mirroring u otro flujo que solo se pueda operar con GUI;
• ajustes del sistema o de una aplicación;
• una fuente de datos sin plugin, MCP ni API;
• un flujo que se mueve entre varias aplicaciones locales;
• una acción final de interfaz que falta en una integración estructurada.

Cómo instalarlo:

1. Abre Settings en Codex.
2. Entra en Computer Use.
3. Haz clic en Install y sigue las solicitudes de autorización.

Cómo activarlo:

1

Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.

1

Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again.

Un ejemplo de la publicación original muestra bien el límite: Jason usó Codex para manejar la espera con soporte de Amazon tras el robo de un paquete. Amazon indicaba que tardaría unos 25 minutos en conectar con un agente. Le pidió a Codex que revisara el chat cada cinco minutos, que cambiara a una revisión por minuto cuando apareciera un agente, y que intentara completar el reembolso. Cuando volvió, el reembolso ya estaba hecho.

Otro patrón común es la “última milla”. Codex puede leer feedback desde Slack, cambiar código y renderizar un video, pero tal vez la integración de Slack disponible en ese hilo no pueda subir el archivo. Computer Use solo necesita hacer clic en Add file y completar esa acción que la herramienta estructurada no puede realizar.

El límite de confianza es más amplio aquí. Dale a Computer Use una sola aplicación o flujo claro cada vez. Para acciones financieras, de cuenta, pago, credenciales, privacidad o seguridad del sistema, mantente presente y revisa los permisos.

2. Usa @Chrome para sesiones iniciadas, varias pestañas y tareas de cuenta

La extensión de Chrome para Codex permite que Codex use tu estado de Chrome ya iniciado. Si una tarea depende de tu cuenta, cookies, perfil del navegador, pestañas existentes o extensiones, @Chrome suele ser la superficie correcta.

Usa @Chrome para:

• Gmail, LinkedIn u otros sitios con sesión iniciada;
• Salesforce, consolas de soporte o herramientas internas;
• paneles internos de la empresa;
• investigación en varios sitios autenticados;
• formularios que dependen de tu cuenta, cookies o extensiones del navegador.

Cómo instalarlo:

1. Abre Plugins en Codex.
2. Añade Chrome.
3. Sigue el flujo para instalar la extensión de Chrome de Codex y aprobar permisos.
4. Cuando la extensión muestre Connected, inicia un nuevo hilo.

Cómo activarlo:

1

Use @Chrome to review the open customer account, compare it with the support ticket in the other tab, and draft the missing fields. Stop before submitting.

Las tareas de Chrome se ejecutan en grupos de pestañas, lo que mantiene juntas las páginas de un mismo hilo de Codex. A diferencia del navegador integrado, esta superficie usa tu identidad real del navegador. Eso la hace más capaz y también más sensible.

Otra ventaja importante de Chrome es el control de varias pestañas. Puede leer contexto en una pestaña, compararlo con otra y continuar el flujo en una tercera. Computer Use también puede manejar un navegador visualmente, pero Chrome entiende la tarea como un flujo de navegador, no como una secuencia de coordenadas de pantalla.

La publicación original menciona un ejemplo con Strudel Composer: Jason entregó a Codex una pestaña de composición musical que ya estaba abierta y le pidió hacer la música más interesante. Chrome le dio a Codex la pestaña seleccionada y las herramientas WebMCP expuestas por la página. Codex inspeccionó la composición, reescribió la armonía y la forma de cuatro minutos, cambió el tempo, guardó la pista y la dejó sonando. No tuvo que buscar visualmente cada control, porque Chrome pudo combinar el contexto de la pestaña con las capacidades estructuradas de la página.

Chrome también encaja bien con tareas de larga duración. Por ejemplo, puedes pedirle a Codex que cada día use Chrome para revisar tus DM de X, noticias relevantes y feedback, que añada lo duradero a tu vault local, y que no publique ni envíe mensajes:

1
2
3

Every day, use Chrome to check my DMs, read relevant news, and look for
feedback or mentions I should know about. Add anything durable to my vault.
Do not post or send messages.

Lo importante no es que Codex pueda abrir X. Lo importante es que el mismo hilo puede volver con el tiempo al mismo trabajo autenticado, conectar lo que encuentra con archivos locales y dejar un resultado revisable.

El límite de confianza de Chrome también debe quedar claro. Los sitios web pueden tratar los clics, envíos y mensajes de Codex como acciones tuyas. El contenido de una página también puede ser entrada no confiable. Un patrón más seguro es permitir que investigue, navegue y redacte automáticamente, pero exigir tu confirmación antes de enviar, publicar, comprar o presentar algo.

Si toda la tarea vive en el navegador y necesita sesión iniciada, elige Chrome antes que Computer Use.

3. Usa @Browser para desarrollar y depurar sitios web

El navegador integrado es un navegador dentro de un hilo de Codex. Tú y Codex comparten la misma página renderizada, por lo que resulta especialmente útil para desarrollo web, depuración visual y feedback de diseño.

Usa @Browser para:

• servidores locales de desarrollo;
• vistas previas de HTML o archivos locales;
• páginas públicas que no requieren inicio de sesión;
• reproducir bugs visuales;
• revisar diseños adaptables;
• dejar feedback de diseño sobre elementos de la página.

Su restricción más importante es el aislamiento: el navegador integrado no usa tu perfil normal del navegador, cookies, extensiones, sesiones iniciadas ni pestañas existentes. Es una limitación cuando la tarea necesita una cuenta, pero es un límite de seguridad útil cuando no la necesita.

Cómo instalarlo:

1. Abre Plugins en Codex.
2. Añade el plugin Browser.
3. Actívalo.

Cómo activarlo:

1

Use @Browser to open vite app on <http://localhost:3000/>, reproduce the mobile overflow bug, fix it, and verify the same route again at desktop and mobile widths.

Esta superficie es ideal para crear un bucle de feedback estrecho: Codex edita el código, opera la página, revisa el estado renderizado, toma una captura y sigue iterando.

La publicación original destaca especialmente la anotación. Al revisar una app local, puedes hacer clic directamente en un elemento o seleccionar un área y dejar un comentario. También puedes dar feedback más preciso sobre texto, fuentes, espaciado y color. Codex recibe el comentario junto con la captura relevante y el contexto del elemento, cambia el archivo y vuelve a abrir la misma página.

Para trabajo de diseño, puedes darle a Codex una idea, un paquete de investigación o el estado de un proyecto, pedirle que genere un index.html de un solo archivo y abrirlo en el navegador integrado. En vez de volver a describir todo el diseño en otro prompt, puedes anotar la página real:

1
2

Create a single-file index.html for this project brief and open it in the
in-app @Browser.

Así la propia página se convierte en la especificación.

El navegador integrado también sirve como punto de partida para flujos mixtos. La publicación original da un ejemplo con una publicación de X: primero se abre la publicación en el navegador integrado para que Codex confirme cuál es; después se cambia a una CLI de Twitter para recuperar 38 respuestas, incluidas respuestas anidadas que la interfaz del navegador ocultaba. Esa es la regla de la superficie más estrecha en la práctica: usar el navegador para establecer el contexto visible y luego una herramienta estructurada para recuperar más datos.

Pero si la tarea se atasca en el inicio de sesión de Google, un passkey, una extensión del navegador o el estado de cuenta, conviene pasar del navegador integrado a Chrome.

Appshots: señalan contexto, no ejecutan

Appshots no es una cuarta forma de que Codex controle una computadora. Es una forma de entregar a Codex el contexto que tienes delante.

En Mac, al pulsar CMD dos veces se captura la ventana más reciente. Codex adjunta la imagen y cualquier texto disponible al hilo. Puedes hacer un Appshot de un error, un correo, un diseño, un panel de ajustes o un formulario desconocido, y decirle a Codex qué quieres que haga.

Un modelo fácil de recordar es:

Appshots señala algo en tu computadora; Browser, Chrome y Computer Use actúan sobre ello.

Appshots se crea actualmente desde la Codex app en macOS. Captura la ventana en primer plano, no todo el escritorio. Eso lo hace útil para aportar contexto enfocado sin conceder control directo de la aplicación.

Cómo elegir

Para incorporar estas tres superficies en el trabajo diario, puedes seguir este orden:

1. Primero revisa si existe un plugin, MCP, CLI o API. Si se puede completar de forma estructurada, no hagas que Codex haga clic por la interfaz.
2. Si necesitas una app de escritorio, ajustes del sistema, un simulador o varias apps locales, usa @Computer.
3. Si la tarea está en el navegador y depende de tu sesión iniciada, cookies, extensiones o varias pestañas, usa @Chrome.
4. Si la tarea es desarrollo web, revisión de una página pública, vista previa local o anotación de diseño, usa @Browser.
5. Si solo quieres decirle a Codex “mira esta ventana”, empieza con Appshots para aportar contexto y luego decide qué superficie debe actuar.

La diferencia entre estas entradas no es solo de capacidad. También es una diferencia de límite de confianza. Cuanto más cerca esté una superficie de tus cuentas reales y de tu entorno de escritorio, más claro debes definir el objetivo, indicar las acciones que no debe ejecutar y mantener confirmación humana antes de enviar, presentar, pagar o publicar.