Respuesta rápida
Los plugins de Codex sirven fuera del código cuando mueven contexto entre archivos, navegador, documentos de equipo y reglas repetibles. Los usaría para borradores, revisión de PDF, limpieza de hojas, QA en navegador, revisión de diseño e investigación interna. No los dejaría ejecutar pagos, borrados, mensajes a clientes ni cambios de cuenta sin revisión, registro y ruta de reversión.
- El valor de los plugins de Codex está en unir archivos, estado del navegador, documentos de equipo y reglas repetibles en un mismo flujo.
- Documents, PDF, Spreadsheets, Browser, Chrome, Computer Use, Figma, Drive, Slack y SharePoint tienen límites de riesgo distintos.
- La pregunta no es si Codex puede escribir o hacer clic, sino si una persona puede revisar pruebas y recuperar el flujo si algo sale mal.
- Conviene empezar con recopilación de contexto, borradores, QA y material de traspaso antes de permitir acciones irreversibles.
- Un buen piloto empieza con un flujo, un responsable, una señal de fallo y una ruta de reversión.
- Ideal para
- Responsables de operaciones, producto, planificación de servicios y automatización que evalúan Codex para trabajo no centrado en código.
- Tema
- Automatización
- Última revisión
- 16 jun 2026
- OpenAI Codex
- Codex plugins
- Documents
- Spreadsheets
- Presentations
- Browser
- Chrome
Mapa del flujo
Un mapa práctico para convertir esta guía en un flujo de automatización.
- 01 Entrada
Define primero la tarea repetida, los datos necesarios, el responsable y el criterio de éxito.
- 02 Paso de IA
Usa IA en pasos con límites claros: redacción, clasificación, resumen, enrutamiento o llamadas a herramientas.
- 03 Revisión humana
Mantén aprobaciones, excepciones, límites de coste y decisiones sensibles bajo revisión humana.
- 04 Salida
Convierte el resultado en una checklist, un prompt guardado, un SOP o una automatización monitorizada.
- OpenAI Codex
- Codex plugins
- Documents
- Spreadsheets
- Presentations
- OpenAI Codex
- plugins de Codex
- automatización IA
- automatización de workflows
- Computer Use
Nota operativa
No conviertas una elección de herramienta en un atajo operativo.
Si la entrada, la revisión y el registro de errores no están claros, la automatización solo acelera el desorden.
Dónde confiar en la herramienta, dónde vigilarla y dónde detenerla.
Ayudar a decidir qué plugins de Codex encajan en automatización de trabajo no centrada en código y dónde debe mantenerse la revisión humana.
8 Fuentes consultadas
Verifica funciones y precios cambiantes con las fuentes enlazadas y las páginas oficiales.
Comparativas
Empieza con un piloto pequeño y amplía solo cuando el punto de revisión esté claro.
- El valor de los plugins de Codex está en unir archivos, estado del navegador, documentos de equipo y reglas repetibles en un mismo flujo.
- Documents, PDF, Spreadsheets, Browser, Chrome, Computer Use, Figma, Drive, Slack y SharePoint tienen límites de riesgo distintos.
- La pregunta no es si Codex puede escribir o hacer clic, sino si una persona puede revisar pruebas y recuperar el flujo si algo sale mal.
- Conviene empezar con recopilación de contexto, borradores, QA y material de traspaso antes de permitir acciones irreversibles.
Ruta de workflow
Dónde encaja esta guía
Usa esta sección para conectar la guía que estás leyendo con el workflow más amplio que apoya.
Una ruta para comparar plataformas de automatización, builders de apps, builders de agentes, contabilidad y asistentes de IA.
Abrir ruta de workflow- Mejor encaje
- equipos que deciden entre comprar una herramienta simple, construir un flujo interno o adoptar una plataforma más amplia
- No es ideal si
- Necesitas una prueba práctica completa de una sola herramienta, no criterios de encaje en el flujo.
Codex suele entrar por el lado del desarrollo. Abrir un repositorio, leer archivos, cambiar código, correr pruebas y revisar un diff. Ahí se entiende rápido.
La conversación cambia cuando aparecen los plugins. OpenAI presenta los plugins como paquetes que pueden incluir skills, integraciones de apps y servidores MCP. En la app de Codex eso acerca documentos, PDF, hojas de cálculo, presentaciones, Browser, Chrome, Computer Use, Figma, GitHub, Google Drive, SharePoint y Slack al mismo ciclo de trabajo.
Eso no convierte a Codex en un empleado administrativo completo. Esa expectativa lleva a malos diseños. Yo lo veo más como una mesa de trabajo: reúne archivos dispersos, estado del navegador, contexto del equipo y reglas repetibles para producir borradores, revisiones, comparativas o traspasos.
Fuera del código, el valor está ahí. No en que escriba bonito. En reducir el tiempo que se pierde copiando, pegando, reformateando, revisando pantallas y repitiendo explicaciones.
Criterio práctico desde operación
Miro primero dónde se corta el contexto del trabajo. No empiezo preguntando qué plugin es más potente. Así todos parecen buenos: Documents, PDF, Chrome, Computer Use, Figma, Drive, Slack.
Un flujo candidato suele tener esta forma:
- La fuente está repartida entre PDF, hoja, documento, página web o conversación interna.
- Alguien necesita una nota de decisión, tabla comparativa, resultado de QA, esqueleto de slides o revisión de datos.
- La tarea se repite lo suficiente como para escribir reglas.
- Hay un responsable humano final.
- El error puede detenerse antes de llegar a cliente, pago, borrado o cambio de cuenta.
En ese terreno los plugins sí tienen sentido. No son adornos. Son puentes de contexto.
Qué cambia con los plugins
Sin plugins, un asistente de IA vive dentro del chat. Pegas un documento, describes una captura, pegas un trozo de CSV, escribes el requisito y pides salida. Sirve para tareas aisladas. Cuando el trabajo cruza herramientas, se vuelve torpe.
Con plugins cambia el modelo operativo.
| Área de trabajo | Buen uso | Punto de revisión | No usar como ruta por defecto |
|---|---|---|---|
| Documents | Nota de decisión, borrador de política, acta depurada | Responsable revisa tono y contexto faltante | lenguaje legal o contractual final |
| Extraer afirmaciones, comparar versiones, verificar páginas | Persona revisa número de página y sentido | aprobación de cumplimiento a ciegas | |
| Spreadsheets | Limpiar columnas, detectar anomalías, proponer fórmulas | Responsable revisa fórmulas y filas | reporte financiero sin revisión |
| Presentations | Convertir brief en estructura de slides | Presentador revisa historia y números | deck final para dirección |
| Browser | Vista local, QA público, revisión de layout | Captura y lista de incidencias | acciones en cuenta autenticada |
| Chrome | Revisar flujos con sesión iniciada | Permisos y estado visible del navegador | operación de cuenta en segundo plano |
| Computer Use | Pasos GUI sin API disponible | Persona observa estado de la app | trabajo de escritorio largo sin supervisión |
| Figma | Comparar pantalla, revisar espaciado, detectar diferencias | Diseño o producto revisa intención | juicio final de gusto |
| Drive, SharePoint, Slack | Buscar archivos, resumir hilos, preparar seguimiento | Links fuente y responsable | enviar mensajes sensibles |
El nombre del plugin importa menos que el límite operativo.
Documentos y PDF
Para trabajo no centrado en código, empezaría por Documents y PDF. El riesgo es manejable y el ahorro se nota pronto.
Un caso típico: hay una nota larga de requisitos, un PDF de precios, una respuesta de seguridad del proveedor y un memo interno a medio escribir. A mano, alguien lee todo, copia detalles, ajusta tono, apunta dudas y pide a otra persona verificar fuentes.
Con Codex pediría una salida fija:
- Qué cambió.
- Qué fuente lo respalda.
- Qué sigue incierto.
- Qué decisión falta.
- Qué frase todavía no debe usarse.
Ese entregable sirve porque es revisable. No finge ser la decisión final.
Criterios de fallo: si la extracción del PDF pierde referencias de página, o si el memo incluye afirmaciones sin fuente, ese flujo no sirve para material de decisión. Bájalo a resumen o lista de lectura.
Elegiría este plugin cuando el trabajo pesa en borrador y contraste de fuentes. No lo elegiría para redacción final donde una palabra puede crear riesgo legal, laboral, financiero o de cliente.
Hojas de cálculo y datos
Las hojas parecen una victoria rápida. También son un sitio donde conviene frenar.
Normalizar columnas, encontrar filas vacías, marcar IDs duplicados, proponer fórmulas o convertir un export desordenado en una tabla comparable ahorra tiempo real. Preguntas como “qué leads no tienen responsable” o “qué facturas cambiaron dos veces de estado” salen más rápido.
El riesgo es que la hoja parece objetiva. Una fórmula mala se ve limpia. Un filtro omitido produce un gráfico convincente. Un error de fechas mueve ingresos a otro mes y nadie lo nota de inmediato.
Mi regla: Codex puede preparar la hoja, pero debe mostrar supuestos. Nombres de columnas claros, fórmulas visibles, filas modificadas marcadas y una nota corta de lo que no verificó.
Buen uso:
- Convertir un export en tracker.
- Comparar dos versiones de CSV.
- Crear un primer modelo de priorización.
- Marcar filas que necesitan revisión humana.
- Ordenar etiquetas inconsistentes para poder pivotar.
Mal uso:
- Cerrar un reporte mensual sin revisar filas.
- Editar el archivo fuente sin backup.
- Sustituir la regla de negocio del responsable por una conjetura del modelo.
Si baja el tiempo de edición pero no baja el tiempo de revisión, el flujo solo está medio resuelto.
Presentaciones y relato
Una presentación no es solo hacer slides. Lo caro es decidir qué va primero, qué se elimina y qué debe recordar la audiencia.
Codex puede ayudar si las entradas son claras: PRD, nota de research, tabla, lista de problemas de clientes y audiencia. Puede producir títulos, una afirmación por slide, evidencia necesaria y banderas de datos faltantes.
La bandera de datos faltantes importa. Sin ella, el borrador parece terminado demasiado pronto.
Para una reunión de producto, la salida debería parecerse a esto:
- Problema: suben los tickets después del onboarding.
- Evidencia necesaria: categorías, segmento afectado, horas de soporte.
- Decisión: corregir onboarding, añadir automatización o cambiar routing.
- Riesgo: los datos actuales pueden contener tickets duplicados.
Eso es útil. Da dirección y checklist. No es un deck final para dirección.
Usaría plugins de presentación para estructura inicial, no para delegar la responsabilidad del argumento.
Browser, Chrome y Computer Use
Los plugins de navegador necesitan límites claros.
El in-app browser encaja con vistas locales, páginas públicas, revisión de layout, capturas de evidencia y QA de flujos simples. “Abre esta página, pulsa el filtro, revisa si las tarjetas se rompen en móvil y reporta” es una tarea razonable.
Chrome es distinto porque puede aprovechar la sesión iniciada del usuario mediante la extensión. Eso es potente y más riesgoso. Una página autenticada puede contener datos privados, clientes, facturación, permisos de admin y botones difíciles de revertir.
Computer Use va más lejos. Puede manejar apps de escritorio cuando navegador o API no alcanzan. Lo reservaría para pantallas antiguas, herramientas locales o verificaciones GUI puntuales sin alternativa limpia.
Mi frontera:
- Browser para QA público o local.
- Chrome solo cuando la sesión iniciada sea necesaria y visible.
- Computer Use solo cuando archivo, navegador, conector o API no sirvan.
Señal de fallo: el agente tiene que adivinar qué significa un botón, la UI cambia durante la tarea, o aparece borrado, pago, mensaje a cliente, cambio de contraseña o envío irreversible. Ahí se detiene y entra una persona.
Figma, Drive, Slack y SharePoint
Figma sirve cuando la pregunta es concreta: comparar una pantalla con el diseño, listar problemas de espaciado, detectar diferencias de componentes o convertir contexto de diseño en notas de implementación. “Hazlo más premium” no alcanza. “La navegación móvil tapa el título; revisa espaciado, área táctil y selector de idioma” sí es trabajo.
Drive y SharePoint sirven para encontrar material y convertir documentos dispersos en un resumen de trabajo. Slack sirve para resumir hilos, extraer acciones y preparar mensajes de seguimiento. No es vistoso, pero ahí se pierde mucho tiempo.
En estos plugins, el modelo de permisos pesa más que la calidad del resumen. Si el plugin puede ver una carpeta o canal, antes debe quedar claro qué puede citar, qué links debe dejar y qué contenido no puede entrar en un documento público.
Los usaría para preparar trabajo, no para publicarlo. Una buena salida deja fuentes, preguntas abiertas y responsable siguiente.
No lo elijas para esto
Que sea técnicamente posible no lo convierte en buen candidato.
No usaría Codex plugins como ruta por defecto para:
- Enviar mensajes a clientes sin revisión.
- Cambiar pagos, cuentas, seguridad o permisos.
- Borrar archivos, tickets, issues, registros o usuarios.
- Enviar formularios a reguladores, bancos, plataformas o proveedores.
- Aprobar contratos, nómina, gastos, reembolsos o accesos.
- Modificar datos fuente sin backup ni diff.
- Tomar una decisión de negocio con evidencia incompleta.
Codex todavía puede preparar: borrador, fuentes, checklist, diff y riesgos. La acción final debe quedarse en una persona cuando el error cuesta caro.
Criterios de fallo
La forma más fácil de usar mal los plugins es confiar en una primera salida limpia y convertirla en proceso.
Estos son los criterios de fallo que miraría:
| Señal de fallo | Qué suele indicar | Qué hacer |
|---|---|---|
| No hay links fuente | No se puede auditar | Exigir citas o limitar entrada |
| El responsable relee todo | El esfuerzo cambió de sitio | Reducir alcance o añadir checks |
| La misma excepción vuelve cada semana | Falta regla, no modelo | Actualizar skill o checklist |
| Pide demasiados permisos | El flujo es demasiado amplio | Separar lectura, borrador y ejecución |
| Texto pulido pero vago | Se pidió estilo, no evidencia | Pedir supuestos, datos faltantes y decisión |
| El navegador cambia estado de cuenta | La frontera de riesgo está mal | Mover a aprobación humana |
| No hay rollback | No está listo para operación | Añadir backup, diff y recuperación |
| El equipo deja de confiar | La carga de revisión es alta | Retirar el flujo o bajar ambición |
Esto pesa más que una precisión abstracta. En operación real, la confianza viene de trazabilidad y recuperación.
Plan de piloto
Empezaría con un flujo aburrido y repetible.
Ejemplo: entrada de comparación de proveedores.
Los inputs son PDF del proveedor, página de precios, notas de seguridad, tabla de requisitos y comentarios internos. La salida es una nota comparativa con fuentes, riesgos abiertos, respuestas faltantes y estado: avanzar, pausar o rechazar.
El piloto no automatiza la decisión del proveedor. Automatiza la preparación.
Configuración mínima:
- Definir un responsable.
- Definir entradas permitidas.
- Definir plantilla de salida.
- Marcar fuentes obligatorias.
- Escribir lo que Codex no debe decidir.
- Añadir revisión de referencias.
- Guardar originales y salida juntos.
- Registrar excepciones repetidas.
Tras dos o tres ciclos aparece el patrón. Si se repite el mismo arreglo, se convierte en skill. Si falta siempre la misma fuente, se mejora la conexión. Si aparece la misma pregunta de aprobación, entra en la plantilla.
Ahí los plugins dejan de ser una lista de herramientas y empiezan a parecer una forma de operar.
Antes de elegir
La pregunta no es si Codex puede hacer trabajo fuera del código. Puede hacer partes útiles.
La pregunta buena es qué parte del trabajo es traslado de contexto, borrador, comparación, revisión y traspaso. En esas zonas los plugins pueden ganarse un lugar.
Si hay juicio, permisos, dinero, impacto en cliente o cambios difíciles de revertir, pondría Codex un paso antes. Que prepare evidencia, muestre diff y haga visible la parte tediosa. La decisión queda en una persona.
No me parece una automatización débil. En muchas organizaciones, esa es la automatización que sobrevive.
Preguntas frecuentes
¿Los plugins de Codex son solo para desarrolladores?
No. Codex entra de forma natural por desarrollo, pero sus plugins llegan a documentos, PDF, hojas, presentaciones, navegador, diseño, archivos de equipo y comunicación. Fuera del código, las entradas, salidas y reglas de revisión importan todavía más.
¿Conviene activar siempre Chrome o Computer Use?
No. Browser basta para muchas revisiones públicas o locales. Chrome sirve cuando se necesita sesión iniciada. Computer Use debe quedarse para tareas GUI donde archivo, navegador, conector o API no resuelven bien.
¿Qué flujo probar primero?
Uno donde la decisión final siga en una persona: comparación de proveedores, revisión de política, memo desde PDF, limpieza de hoja, QA de diseño o triage de hilos de soporte. No empieces con pagos, borrados, cambios de cuenta o mensajes a clientes.
¿Cómo encajan plugins y skills?
Los plugins dan acceso a herramientas y contexto. Las skills guardan método repetible y criterios de revisión. La combinación práctica es plugin para acceder, skill para ejecutar el método y revisión humana para mantener la responsabilidad.
Fuentes consultadas
Principales páginas públicas usadas para comprobar detalles de producto, contexto de precios y afirmaciones comparativas.
- Codex plugins OpenAI
- Codex app features OpenAI
- Codex Chrome extension OpenAI
- Computer Use in Codex OpenAI
- In-app browser in Codex OpenAI
- Agent Skills OpenAI
- Model Context Protocol in Codex OpenAI
- GPT web generated image OpenAI
