Entorno de ejecución del arnés de Codex

Contrato de runtime para turnos del arnés de Codex. Para configuración y enrutamiento, consulta arnés de Codex. Para campos de configuración, consulta referencia del arnés de Codex.

​

Descripción general

Codex posee el bucle de modelo nativo, la reanudación de hilos nativa, la continuación de herramientas nativa y la Compaction nativa. OpenClaw posee el enrutamiento de canales, los archivos de sesión, la entrega de mensajes visibles, las herramientas dinámicas de OpenClaw, las aprobaciones, la entrega de medios y un espejo de transcripción alrededor de ese límite. El enrutamiento de prompts sigue el runtime seleccionado, no solo la cadena del proveedor. Un turno nativo de Codex recibe instrucciones de desarrollador del servidor de aplicaciones de Codex; una ruta explícita de compatibilidad de OpenClaw conserva el prompt de sistema normal de OpenClaw incluso cuando usa autenticación o transporte de OpenAI con estilo Codex. OpenClaw inicia y reanuda hilos nativos de Codex con la personalidad integrada de Codex deshabilitada (personality: "none") para que los archivos de personalidad del workspace y la identidad del agente de OpenClaw sigan siendo autoritativos. Por lo demás, Codex nativo conserva las instrucciones base/de modelo propiedad de Codex y la carga de documentación del proyecto. Las ejecuciones ligeras de OpenClaw (por ejemplo, cron) siguen suprimiendo la carga de documentación del proyecto. Las instrucciones de desarrollador de OpenClaw cubren aspectos del runtime de OpenClaw: entrega del canal de origen, herramientas dinámicas de OpenClaw, delegación ACP, contexto del adaptador y los archivos de perfil del workspace del agente activo. Los catálogos de Skills y los punteros a MEMORY.md enrutados por herramientas se proyectan como instrucciones de desarrollador de colaboración con alcance de turno. Cuando las herramientas de memoria no están disponibles, el contenido activo de BOOTSTRAP.md y el MEMORY.md completo recaen en contexto de entrada de turno sin formato.

​

Vinculaciones de hilos y cambios de modelo

Cuando una sesión de OpenClaw se adjunta a un hilo existente de Codex, el siguiente turno reenvía al servidor de aplicaciones el modelo seleccionado actualmente, la política de aprobación, el sandbox, el revisor de aprobaciones y el nivel de servicio. Cambiar de openai/gpt-5.5 a openai/gpt-5.2 mantiene la vinculación del hilo, pero pide a Codex que continúe con el modelo recién seleccionado.

​

Respuestas visibles y Heartbeats

Los turnos de chat directos/de origen a través del arnés de Codex tienen por defecto la entrega automática final del asistente para superficies internas de WebChat, coincidiendo con el contrato del arnés de Pi: el agente responde con normalidad y OpenClaw publica el texto final en la conversación de origen. Define messages.visibleReplies: "message_tool" para mantener privado el texto final del asistente salvo que el agente llame a message(action="send"). Los turnos Heartbeat de Codex reciben heartbeat_respond en el catálogo buscable de herramientas de OpenClaw de forma predeterminada para que el agente pueda registrar si el despertar debe permanecer silencioso o notificar. La guía de iniciativa de Heartbeat se envía como una instrucción de desarrollador del modo de colaboración de Codex con alcance al turno Heartbeat; los turnos de chat ordinarios permanecen en modo Default de Codex. Cuando HEARTBEAT.md no está vacío, las instrucciones de Heartbeat apuntan a Codex al archivo en lugar de insertar su contenido en línea.

​

Límites de hooks

OpenClaw no usa archivos hooks.json de proyecto o globales de Codex para enrutar comportamiento de Plugin. Para el puente de herramientas nativas y permisos, OpenClaw inyecta configuración de Codex por hilo para PreToolUse, PostToolUse, PermissionRequest y Stop. Cuando las aprobaciones del servidor de aplicaciones de Codex están habilitadas (approvalPolicy no es "never"), la configuración predeterminada inyectada de hooks nativos omite PermissionRequest para que el revisor del servidor de aplicaciones de Codex y el puente de aprobaciones de OpenClaw gestionen escaladas reales después de la revisión. Agrega permission_request a nativeHookRelay.events para forzar el relay de compatibilidad de todos modos. Otros hooks de Codex como SessionStart y UserPromptSubmit siguen siendo controles de nivel Codex; no se exponen como hooks de Plugin de OpenClaw en el contrato v1. Para las herramientas dinámicas de OpenClaw, OpenClaw ejecuta la herramienta después de que Codex solicita la llamada, por lo que el comportamiento de Plugin y middleware se ejecuta en el adaptador del arnés. Para las herramientas nativas de Codex, Codex posee el registro canónico de la herramienta; OpenClaw puede reflejar eventos seleccionados, pero no puede reescribir el hilo nativo a menos que Codex lo exponga mediante el servidor de aplicaciones o callbacks de hooks nativos. Los eventos PreToolUse del modo de informe del servidor de aplicaciones de Codex difieren la aprobación del Plugin a la aprobación correspondiente del servidor de aplicaciones. Si un hook before_tool_call de OpenClaw devuelve requireApproval mientras la carga nativa define openclaw_approval_mode: "report", el relay de hooks nativos registra el requisito de aprobación del Plugin y no devuelve ninguna decisión nativa. Cuando Codex envía más tarde la solicitud de aprobación del servidor de aplicaciones para el mismo uso de herramienta, OpenClaw abre el prompt de aprobación del Plugin y asigna la decisión de vuelta a Codex. Los eventos PermissionRequest de Codex son una ruta de aprobación separada y aún pueden enrutarse mediante aprobaciones de OpenClaw cuando están configurados para ese puente. Las notificaciones de elementos del servidor de aplicaciones de Codex también proporcionan observaciones asíncronas de after_tool_call para finalizaciones de herramientas nativas que aún no estén cubiertas por el relay nativo PostToolUse. Son solo telemetría/compatibilidad; no pueden bloquear, demorar ni mutar la llamada de herramienta nativa. Las proyecciones de Compaction y del ciclo de vida del LLM provienen de las notificaciones del servidor de aplicaciones de Codex y del estado del adaptador de OpenClaw, no de comandos de hooks nativos de Codex. before_compaction, after_compaction, llm_input y llm_output son observaciones de nivel de adaptador, no capturas byte a byte de la solicitud interna o las cargas de Compaction de Codex. Las notificaciones hook/started y hook/completed del servidor de aplicaciones nativo de Codex se proyectan como eventos de agente codex_app_server.hook para trayectoria y depuración. No invocan hooks de Plugin de OpenClaw.

​

Contrato de compatibilidad v1

Compatible con el runtime de Codex v1: No compatible en Codex runtime v1:

​

Permisos nativos y elicitaciones de MCP

Para PermissionRequest, OpenClaw solo devuelve decisiones explícitas de permitir o denegar cuando la política decide. Un resultado sin decisión no es una autorización: Codex lo trata como ausencia de decisión del hook y continúa a su propio guardián o ruta de aprobación de usuario. Los modos de aprobación de Codex app-server omiten este hook nativo de forma predeterminada. Esto se aplica salvo que permission_request se incluya explícitamente en nativeHookRelay.events o que un runtime de compatibilidad lo instale. Cuando un operador elige allow-always para una solicitud de permiso nativa de Codex, OpenClaw recuerda esa huella exacta de proveedor/sesión/entrada de herramienta/cwd durante una ventana de sesión acotada. La decisión recordada es intencionalmente solo de coincidencia exacta: un comando, argumentos, carga útil de herramienta o cwd cambiado crea una nueva aprobación. Las elicitaciones de aprobación de herramientas MCP de Codex se enrutan mediante el flujo de aprobación de plugins de OpenClaw cuando Codex marca _meta.codex_approval_kind como "mcp_tool_call". Los prompts request_user_input de Codex se envían de vuelta al chat de origen, y el siguiente mensaje de seguimiento en cola responde a esa solicitud del servidor nativo en lugar de ser dirigido como contexto adicional. Otras solicitudes de elicitación de MCP fallan de forma cerrada. Para el flujo general de aprobación de plugins que transporta estos prompts, consulta Solicitudes de permisos de plugins.

​

Dirección de la cola

La dirección de cola de ejecución activa se asigna a turn/steer de Codex app-server. Con el valor predeterminado messages.queue.mode: "steer", OpenClaw agrupa los mensajes de chat en modo de dirección durante la ventana de silencio configurada y los envía como una única solicitud turn/steer en orden de llegada. Codex review y los turnos de Compaction manual pueden rechazar la dirección en el mismo turno. En ese caso, OpenClaw espera a que termine la ejecución activa antes de iniciar el prompt. Usa /queue followup o /queue collect cuando los mensajes deban ponerse en cola de forma predeterminada en lugar de dirigir el turno. Consulta Cola de dirección.

​

Carga de comentarios de Codex

Cuando se aprueba /diagnostics [note] para una sesión en el arnés nativo de Codex, OpenClaw también llama a feedback/upload del app-server de Codex para los hilos de Codex relevantes, incluidos los registros de cada hilo listado y los subhilos de Codex generados cuando estén disponibles. La carga pasa por la ruta normal de comentarios de Codex hacia los servidores de OpenAI. Si los comentarios de Codex están deshabilitados en ese app-server, el comando devuelve el error del app-server. La respuesta de diagnósticos completada lista los canales, los identificadores de sesión de OpenClaw, los identificadores de hilo de Codex y los comandos locales codex resume <thread-id> para los hilos que se enviaron. Si rechazas o ignoras la aprobación, OpenClaw no imprime esos identificadores de Codex y no envía comentarios de Codex. La carga no reemplaza la exportación local de diagnósticos del Gateway. Consulta Exportación de diagnósticos para la aprobación, la privacidad, el paquete local y el comportamiento en chats grupales. Usa /codex diagnostics [note] solo cuando quieras la carga de comentarios de Codex para el hilo actualmente adjunto sin el paquete completo de diagnósticos del Gateway.

​

Compaction y espejo de transcripción

Cuando el modelo seleccionado usa el arnés de Codex, la Compaction nativa del hilo pertenece al app-server de Codex. OpenClaw no ejecuta Compaction previa para turnos de Codex, no reemplaza la Compaction de Codex con Compaction del motor de contexto ni recurre a OpenClaw o a la generación de resúmenes pública de OpenAI cuando la Compaction nativa no puede iniciarse. OpenClaw mantiene un espejo de transcripción para el historial del canal, la búsqueda, /new, /reset y futuros cambios de modelo o arnés. Las solicitudes explícitas de Compaction, como /compact o una operación de compactación manual solicitada por un plugin, inician la Compaction nativa de Codex con thread/compact/start. OpenClaw mantiene abiertos la solicitud y el arrendamiento del cliente compartido hasta que Codex emite el elemento de finalización contextCompaction correspondiente y luego informa el turno de Compaction como completado. Si ese turno terminal supera el tiempo de espera de Compaction configurado, OpenClaw solicita una interrupción de turno nativa. El arrendamiento y la barrera de Compaction por hilo permanecen retenidos hasta que Codex informa el estado terminal o confirma la RPC de interrupción. Si Codex no confirma dentro del período de gracia de interrupción, OpenClaw retira la conexión antes de liberar la barrera. Las conexiones remotas también separan la vinculación del hilo correspondiente para que el trabajo posterior no pueda solaparse con un turno remoto no confirmado. Otros turnos en una conexión retirada fallan y pueden reintentarse en un cliente nuevo. El cierre del cliente, la cancelación de la solicitud o un turno de Compaction fallido devuelven una operación fallida. La Compaction automática por presión de contexto es responsabilidad de Codex; OpenClaw solo inicia la Compaction nativa para activadores solicitados manualmente. Cuando un motor de contexto solicita la proyección de arranque de hilo de Codex, OpenClaw proyecta nombres e identificadores de llamadas a herramientas, formas de entrada y contenido redactado de resultados de herramientas en el hilo nuevo de Codex. No copia valores sin procesar de argumentos de llamadas a herramientas en esa proyección. El espejo incluye el prompt del usuario, el texto final del asistente y registros ligeros de razonamiento o plan de Codex cuando el app-server los emite. OpenClaw registra el inicio y el estado terminal de la Compaction nativa, pero no expone un resumen de Compaction legible por humanos ni una lista auditable de qué entradas conservó Codex después de la Compaction. Como Codex posee el hilo nativo canónico, tool_result_persist no reescribe registros de resultados de herramientas nativos de Codex. Solo se aplica cuando OpenClaw escribe un resultado de herramienta de transcripción de sesión propiedad de OpenClaw.

​

Medios y entrega

OpenClaw sigue siendo responsable de la entrega de medios y de la selección del proveedor de medios. La generación de imágenes, video, música, PDF, TTS y la comprensión de medios usan ajustes de proveedor/modelo correspondientes, como agents.defaults.imageGenerationModel, videoGenerationModel, pdfModel y messages.tts. Texto, imágenes, video, música, TTS, aprobaciones y salida de herramientas de mensajería continúan por la ruta normal de entrega de OpenClaw; la generación de medios no requiere el runtime heredado. Cuando Codex emite un elemento nativo de generación de imágenes con un savedPath, OpenClaw reenvía ese archivo exacto por la ruta normal de medios de respuesta, incluso si el turno de Codex no tiene texto de asistente.

​

Relacionado

• Arnés de Codex
• Referencia del arnés de Codex
• Plugins nativos de Codex
• Hooks de plugins
• Plugins de arnés de agente
• Exportación de diagnósticos
• Exportación de trayectoria