Saltar al contenido principal
Esta referencia cubre la configuración detallada del plugin codex incluido. Para decisiones de configuración y enrutamiento, empieza con arnés de Codex.

Superficie de configuración del Plugin

Todas las opciones del arnés de Codex se encuentran en plugins.entries.codex.config.
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          discovery: {
            enabled: true,
            timeoutMs: 2500,
          },
          appServer: {
            mode: "guardian",
          },
        },
      },
    },
  },
}
Campos de nivel superior:
CampoPredeterminadoSignificado
discoveryhabilitadoOpciones de descubrimiento de modelos para model/list del app-server de Codex.
appServerapp-server stdio gestionadoOpciones de transporte, comando, autenticación, aprobación, sandbox y tiempo de espera.
codexDynamicToolsLoading"searchable"Usa "direct" para colocar las herramientas dinámicas de OpenClaw directamente en el contexto inicial de herramientas de Codex.
codexDynamicToolsExclude[]Nombres adicionales de herramientas dinámicas de OpenClaw que se omitirán en los turnos del app-server de Codex.
codexPluginsdeshabilitadoCompatibilidad nativa con plugins/apps de Codex, incluido el acceso opcional a apps de cuentas conectadas. Consulta Plugins nativos de Codex.
computerUsedeshabilitadoConfiguración de Codex Computer Use. Consulta Codex Computer Use.

Transporte del app-server

De forma predeterminada, OpenClaw inicia el binario gestionado de Codex que se envía con el plugin incluido (actualmente @openai/codex 0.142.5):
codex app-server --listen stdio://
Esto mantiene la versión del app-server vinculada al plugin codex incluido, en lugar de a cualquier CLI de Codex independiente que esté instalada localmente. Configura appServer.command solo cuando quieras usar intencionalmente otro ejecutable. Para un app-server que ya está en ejecución, usa el transporte WebSocket:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            transport: "websocket",
            url: "ws://gateway-host:39175",
            authToken: "${CODEX_APP_SERVER_TOKEN}",
            requestTimeoutMs: 60000,
          },
        },
      },
    },
  },
}
Campos de appServer:
CampoPredeterminadoSignificado
transport"stdio""stdio" inicia Codex; "websocket" se conecta a url.
homeScope"agent""agent" aísla el estado de Codex por agente de OpenClaw. "user" comparte el $CODEX_HOME nativo o ~/.codex, usa la autenticación nativa y habilita la gestión de hilos exclusiva del propietario. El alcance de usuario requiere stdio.
commandbinario de Codex gestionadoEjecutable para el transporte stdio. Déjalo sin establecer para usar el binario gestionado.
args["app-server", "--listen", "stdio://"]Argumentos para el transporte stdio.
urlsin establecerURL del app-server WebSocket.
authTokensin establecerToken Bearer para el transporte WebSocket. Acepta una cadena literal o SecretInput como ${CODEX_APP_SERVER_TOKEN}.
headers{}Encabezados WebSocket adicionales. Los valores de encabezado aceptan cadenas literales o valores SecretInput, por ejemplo x-codex-client-session-token: "${CODEX_CLIENT_SESSION_TOKEN}".
clearEnv[]Nombres adicionales de variables de entorno que se eliminan del proceso app-server stdio iniciado después de que OpenClaw construye su entorno heredado.
remoteWorkspaceRootsin establecerRaíz remota del espacio de trabajo del app-server de Codex. Cuando se establece, OpenClaw infiere la raíz del espacio de trabajo local a partir del espacio de trabajo de OpenClaw resuelto, conserva el sufijo del cwd actual bajo esta raíz remota y envía solo el cwd final del app-server a Codex. Si el cwd está fuera de la raíz del espacio de trabajo de OpenClaw resuelto, OpenClaw falla en modo cerrado en lugar de enviar una ruta local del Gateway al app-server remoto.
requestTimeoutMs60000Tiempo de espera para llamadas del plano de control del app-server.
turnCompletionIdleTimeoutMs60000Ventana de silencio después de que Codex acepta un turno o después de una solicitud del app-server con alcance de turno mientras OpenClaw espera turn/completed.
postToolRawAssistantCompletionIdleTimeoutMs300000Guardia de inactividad de finalización y progreso usada después de una transferencia de herramienta, finalización de herramienta nativa, progreso del asistente sin procesar posterior a herramienta, finalización de razonamiento sin procesar o progreso de razonamiento mientras OpenClaw espera turn/completed. Usa esto para cargas de trabajo confiables o pesadas en las que la síntesis posterior a herramienta puede permanecer legítimamente en silencio durante más tiempo que el presupuesto final de entrega del asistente.
mode"yolo" salvo que los requisitos locales de Codex no permitan YOLOPreajuste para ejecución YOLO o revisada por guardián.
approvalPolicy"never" o una política de aprobación de guardián permitidaPolítica de aprobación nativa de Codex enviada al inicio de hilo, reanudación y turno.
sandbox"danger-full-access" o un sandbox de guardián permitidoModo sandbox nativo de Codex enviado al inicio y reanudación de hilo. Los sandboxes activos de OpenClaw restringen los turnos danger-full-access a workspace-write de Codex; la bandera de red del turno sigue la salida del sandbox de OpenClaw.
approvalsReviewer"user" o un revisor de guardián permitidoUsa "auto_review" para permitir que Codex revise las solicitudes de aprobación nativas cuando esté permitido.
defaultWorkspaceDirdirectorio del proceso actualEspacio de trabajo usado por /codex bind cuando se omite --cwd.
serviceTiersin establecerNivel de servicio opcional del app-server de Codex. "priority" habilita el enrutamiento de modo rápido, "flex" solicita procesamiento flex y null borra la anulación. El valor heredado "fast" se acepta como "priority".
networkProxydeshabilitadoOpta por la red de perfil de permisos de Codex para comandos del app-server. OpenClaw define la configuración permissions.<profile>.network seleccionada y la selecciona con default_permissions en lugar de enviar sandbox.
experimental.sandboxExecServerfalseSuscripción preliminar que registra en Codex app-server 0.132.0 o posterior un entorno de Codex respaldado por el sandbox de OpenClaw para que la ejecución nativa de Codex pueda ejecutarse dentro del sandbox activo de OpenClaw.
appServer.networkProxy es explícito porque cambia el contrato de sandbox de Codex. Cuando está habilitado, OpenClaw también establece features.network_proxy.enabled y default_permissions en la configuración del hilo de Codex para que el perfil de permisos generado pueda iniciar la red gestionada por Codex. OpenClaw genera de forma predeterminada un nombre de perfil openclaw-network-<fingerprint> resistente a colisiones a partir del cuerpo del perfil; usa profileName solo cuando se requiera un nombre local estable.
export default {
  plugins: {
    entries: {
      codex: {
        config: {
          appServer: {
            sandbox: "workspace-write",
            networkProxy: {
              enabled: true,
              domains: {
                "api.openai.com": "allow",
                "blocked.example.com": "deny",
              },
              allowUpstreamProxy: true,
              proxyUrl: "http://127.0.0.1:3128",
            },
          },
        },
      },
    },
  },
};
Si el runtime normal del servidor de aplicaciones fuera danger-full-access, habilitar networkProxy usa en su lugar acceso al sistema de archivos de estilo workspace para el perfil de permisos generado. La aplicación de red gestionada por Codex es networking en sandbox, por lo que un perfil de acceso completo no protegería el tráfico saliente. El Plugin bloquea handshakes de servidor de aplicaciones antiguos o sin versión: el servidor de aplicaciones Codex debe informar la versión estable 0.125.0 o posterior. OpenClaw trata las URL WebSocket de servidor de aplicaciones que no son loopback como remotas y requiere autenticación WebSocket con identidad mediante appServer.authToken o un encabezado Authorization. appServer.authToken y cada valor appServer.headers.* pueden ser un SecretInput; el runtime de secretos resuelve SecretRefs y la abreviatura de env antes de que OpenClaw cree las opciones de inicio del servidor de aplicaciones, y los SecretRefs estructurados sin resolver fallan antes de que se envíe cualquier token o encabezado. Cuando se configuran plugins nativos de Codex, OpenClaw usa el plano de control de plugins del servidor de aplicaciones conectado para instalar o actualizar esos plugins y luego actualiza el inventario de apps para que las apps propiedad del plugin sean visibles para el hilo de Codex. app/list sigue siendo la fuente autoritativa de inventario y metadatos, pero la política de OpenClaw decide si thread/start envía config.apps[appId].enabled = true para una app accesible listada aunque Codex la marque actualmente como deshabilitada. Los ids de app desconocidos o faltantes siguen fallando de forma cerrada; esta ruta solo activa plugins de marketplace mediante plugin/install y actualiza el inventario. Conecta OpenClaw solo a servidores de aplicaciones remotos en los que confíes para aceptar instalaciones de plugins gestionadas por OpenClaw y actualizaciones de inventario de apps.

Modos de aprobación y sandbox

Las sesiones locales de servidor de aplicaciones por stdio usan por defecto el modo YOLO: approvalPolicy: "never", approvalsReviewer: "user" y sandbox: "danger-full-access". Esta postura de operador local de confianza permite que los turnos y Heartbeat desatendidos de OpenClaw avancen sin prompts de aprobación nativos que nadie puede responder. Si el archivo local de requisitos del sistema de Codex no permite valores implícitos de aprobación YOLO, revisor o sandbox, OpenClaw trata el valor implícito predeterminado como guardian y selecciona permisos guardian permitidos. tools.exec.mode: "auto" también fuerza aprobaciones de Codex revisadas por guardian y no conserva overrides heredados inseguros de approvalPolicy: "never" o sandbox: "danger-full-access"; configura tools.exec.mode: "full" para una postura intencional sin aprobación. Las entradas [[remote_sandbox_config]] que coinciden con el hostname en el mismo archivo de requisitos se respetan para la decisión predeterminada de sandbox. Configura appServer.mode: "guardian" para aprobaciones de Codex revisadas por guardian:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            mode: "guardian",
            serviceTier: "priority",
          },
        },
      },
    },
  },
}
El preset guardian se expande a approvalPolicy: "on-request", approvalsReviewer: "auto_review" y sandbox: "workspace-write" cuando esos valores están permitidos. Los campos individuales de política sobrescriben mode. El valor de revisor anterior guardian_subagent aún se acepta como alias de compatibilidad, pero las configuraciones nuevas deben usar auto_review. Cuando un sandbox de OpenClaw está activo, el proceso local del servidor de aplicaciones Codex sigue ejecutándose en el host del Gateway. Por tanto, OpenClaw deshabilita Codex Code Mode nativo, los servidores MCP de usuario y la ejecución de plugins respaldada por apps para ese turno, en lugar de tratar el sandbox del lado del host de Codex como equivalente al backend de sandbox de OpenClaw. El acceso shell se expone mediante herramientas dinámicas respaldadas por el sandbox de OpenClaw, como sandbox_exec y sandbox_process, cuando las herramientas normales de exec/process están disponibles.
En hosts de sandbox de OpenClaw respaldados por Docker (agents.defaults.sandbox.mode configurado en un backend Docker), openclaw doctor comprueba si el host permite los namespaces de usuario sin privilegios (y, cuando la salida de red del sandbox Docker está deshabilitada, de red) que bwrap anidado de Codex necesita para la ejecución shell workspace-write dentro del contenedor sandbox. Una comprobación fallida suele aparecer como bwrap: setting up uid map: Permission denied o bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted en hosts Ubuntu/AppArmor. Corrige la política de namespaces del host indicada para el usuario de servicio de OpenClaw y reinicia el gateway; prefiere un perfil AppArmor acotado para el proceso de servicio antes que el fallback para todo el host kernel.apparmor_restrict_unprivileged_userns=0, y no concedas privilegios más amplios al contenedor Docker solo para satisfacer bwrap anidado.

Ejecución nativa en sandbox

El valor predeterminado estable es fallar de forma cerrada: el sandbox activo de OpenClaw deshabilita las superficies de ejecución nativa de Codex que de otro modo se ejecutarían desde el host del servidor de aplicaciones Codex. Usa appServer.experimental.sandboxExecServer: true solo cuando quieras probar el soporte de entorno remoto de Codex con el backend de sandbox de OpenClaw. Esta ruta de vista previa requiere el servidor de aplicaciones Codex 0.132.0 o posterior.
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            experimental: {
              sandboxExecServer: true,
            },
          },
        },
      },
    },
  },
}
Cuando la bandera está activada y la sesión actual de OpenClaw está en sandbox, OpenClaw inicia un servidor de exec de local loopback respaldado por el sandbox activo, lo registra con el servidor de aplicaciones Codex e inicia el hilo y el turno de Codex con ese entorno propiedad de OpenClaw. Si el servidor de aplicaciones no puede registrar el entorno, la ejecución falla de forma cerrada en lugar de volver silenciosamente a la ejecución en el host. Esta ruta de vista previa es solo local. Un servidor de aplicaciones WebSocket remoto no puede alcanzar el servidor de exec loopback salvo que se ejecute en el mismo host, por lo que OpenClaw rechaza esa combinación.

Aislamiento de autenticación y entorno

En el home predeterminado por agente, la autenticación se selecciona en este orden:
  1. Un perfil explícito de autenticación Codex de OpenClaw para el agente.
  2. La cuenta existente del servidor de aplicaciones en el home de Codex de ese agente.
  3. Solo para lanzamientos locales de servidor de aplicaciones por stdio, CODEX_API_KEY, luego OPENAI_API_KEY, cuando no hay ninguna cuenta de servidor de aplicaciones presente y la autenticación OpenAI aún es necesaria.
Cuando OpenClaw detecta un perfil de autenticación Codex de estilo suscripción ChatGPT (tipo de credencial OAuth o token), elimina CODEX_API_KEY y OPENAI_API_KEY del proceso hijo de Codex generado. Eso mantiene las claves API a nivel de Gateway disponibles para embeddings o modelos OpenAI directos sin hacer que los turnos nativos del servidor de aplicaciones Codex se facturen por la API por accidente. Los perfiles explícitos de clave API de Codex y el fallback local de clave env por stdio usan login del servidor de aplicaciones en lugar del env heredado del proceso hijo. Las conexiones WebSocket de servidor de aplicaciones no reciben fallback de clave API env del Gateway; usa un perfil de autenticación explícito o la propia cuenta del servidor de aplicaciones remoto. Los lanzamientos de servidor de aplicaciones por stdio heredan por defecto el entorno del proceso de OpenClaw. OpenClaw posee el puente de cuenta del servidor de aplicaciones Codex y configura CODEX_HOME en un directorio por agente bajo el estado de OpenClaw de ese agente. Eso mantiene la configuración, las cuentas, la caché/datos de plugins y el estado de hilos de Codex acotados al agente de OpenClaw, en lugar de filtrarse desde el home personal ~/.codex del operador. Configura appServer.homeScope: "user" para compartir el estado nativo de Codex con Codex Desktop y la CLI. Este modo solo para stdio local usa $CODEX_HOME cuando está configurado y ~/.codex en caso contrario, incluida la autenticación, configuración, plugins e hilos nativos. OpenClaw omite su puente de perfil de autenticación para el servidor de aplicaciones. Los turnos de propietario verificados pueden usar codex_threads para listar (con un filtro opcional search), leer, bifurcar, renombrar, archivar y desarchivar esos hilos. Bifurca un hilo antes de continuarlo en OpenClaw; los procesos independientes de Codex no coordinan escritores concurrentes para el mismo hilo. OpenClaw no reescribe HOME para lanzamientos locales normales de servidor de aplicaciones. Los subprocesos ejecutados por Codex, como openclaw, gh, git, CLI de nube y comandos shell, ven el home normal del proceso y pueden encontrar configuración y tokens del home de usuario. Codex también puede descubrir $HOME/.agents/skills y $HOME/.agents/plugins/marketplace.json; ese descubrimiento de .agents se comparte intencionalmente con el home del operador y está separado del estado aislado de ~/.codex. En el alcance predeterminado del agente, los plugins de OpenClaw y las instantáneas de Skills de OpenClaw siguen fluyendo por el propio registro de plugins y cargador de Skills de OpenClaw; los recursos personales de Codex ~/.codex no. Si tienes Skills o plugins útiles de la CLI de Codex de un home de Codex que deban formar parte de un agente aislado de OpenClaw, haz su inventario explícitamente:
openclaw migrate codex --dry-run
openclaw migrate apply codex --yes
Si un despliegue necesita aislamiento adicional del entorno, añade esas variables a appServer.clearEnv:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            clearEnv: ["CODEX_API_KEY", "OPENAI_API_KEY"],
          },
        },
      },
    },
  },
}
appServer.clearEnv solo afecta al proceso hijo del servidor de aplicaciones Codex generado. OpenClaw elimina CODEX_HOME y HOME de esta lista durante la normalización del lanzamiento local: CODEX_HOME sigue apuntando al alcance de agente o usuario seleccionado, y HOME sigue heredado para que los subprocesos puedan usar el estado normal del home de usuario.

Herramientas dinámicas

Las herramientas dinámicas de Codex usan por defecto carga searchable, expuesta bajo el namespace openclaw con deferLoading: true. OpenClaw no expone herramientas dinámicas que duplican operaciones nativas de workspace de Codex o la propia superficie de búsqueda de herramientas de Codex:
  • read
  • write
  • edit
  • apply_patch
  • exec
  • process
  • update_plan
  • tool_call
  • tool_describe
  • tool_search
  • tool_search_code
La mayoría de las herramientas restantes de integración de OpenClaw, como mensajería, medios, Cron, navegador, nodos, Gateway, heartbeat_respond y web_search, están disponibles mediante la búsqueda de herramientas de Codex bajo ese namespace. Esto reduce el contexto inicial del modelo. Un pequeño conjunto de herramientas sigue siendo invocable directamente sin importar codexDynamicToolsLoading, porque la búsqueda de herramientas de Codex puede no estar disponible o resolver un universo solo de conectores: agents_list, sessions_spawn y sessions_yield. Las instrucciones de desarrollador aún orientan a los subagentes normales de Codex hacia spawn_agent nativo para trabajo de subagentes nativo de Codex, mientras que sessions_spawn sigue disponible para delegación explícita de OpenClaw o ACP. Las respuestas de origen solo con herramientas de mensaje también siguen directas, ya que eso es un contrato de control de turnos. Configura codexDynamicToolsLoading: "direct" solo al conectar con un servidor de aplicaciones Codex personalizado que no pueda buscar herramientas dinámicas diferidas o al depurar el payload completo de herramientas.

Tiempos de espera

Las llamadas a herramientas dinámicas propiedad de OpenClaw están acotadas de forma independiente de appServer.requestTimeoutMs. Cada solicitud item/tool/call de Codex usa el primer timeout disponible en este orden:
  • Un argumento positivo timeoutMs por llamada.
  • Para image_generate, agents.defaults.imageGenerationModel.timeoutMs.
  • Para image_generate sin un timeout configurado, el valor predeterminado de generación de imágenes de 120 segundos.
  • Para la herramienta image de comprensión de medios, tools.media.image.timeoutSeconds convertido a milisegundos, o el valor predeterminado de medios de 60 segundos. Para comprensión de imágenes, esto se aplica a la solicitud en sí y no se reduce por trabajo de preparación anterior.
  • Para la herramienta message, un valor predeterminado fijo de 120 segundos.
  • El valor predeterminado de herramientas dinámicas de 90 segundos.
Este watchdog es el presupuesto externo dinámico de item/tool/call. Los timeouts de solicitud específicos del proveedor se ejecutan dentro de esa llamada y mantienen su propia semántica de timeout. Los presupuestos de herramientas dinámicas están limitados a 600000 ms. Al agotarse el tiempo, OpenClaw aborta la señal de la herramienta cuando es compatible y devuelve una respuesta fallida de herramienta dinámica a Codex para que el turno pueda continuar en lugar de dejar la sesión en processing. Después de que Codex acepta un turno, y después de que OpenClaw responde a una solicitud de app-server con alcance de turno, el arnés espera que Codex avance en el turno actual y finalmente termine el turno nativo con turn/completed. Si el app-server queda en silencio durante appServer.turnCompletionIdleTimeoutMs, OpenClaw interrumpe el turno de Codex en modo de mejor esfuerzo, registra un tiempo de espera de diagnóstico y libera el carril de sesión de OpenClaw para que los mensajes de chat de seguimiento no queden en cola detrás de un turno nativo obsoleto. La mayoría de las notificaciones no terminales para el mismo turno desarman ese watchdog corto porque Codex ha demostrado que el turno sigue vivo. Las entregas de herramientas usan un presupuesto de inactividad posterior a la herramienta más largo: después de que OpenClaw devuelve una respuesta item/tool/call, después de que elementos de herramienta nativos como commandExecution se completan, después de completaciones custom_tool_call_output sin procesar, y después del progreso de asistente sin procesar posterior a la herramienta, completaciones de razonamiento sin procesar o progreso de razonamiento. La guarda usa appServer.postToolRawAssistantCompletionIdleTimeoutMs cuando está configurado y de lo contrario usa cinco minutos de forma predeterminada. Ese mismo presupuesto posterior a la herramienta también extiende el watchdog de progreso para la ventana de síntesis silenciosa antes de que Codex emita el siguiente evento del turno actual. Las completaciones de razonamiento, las completaciones agentMessage de comentario y el progreso de razonamiento o de asistente sin procesar previo a la herramienta pueden ir seguidos por una respuesta final automática, por lo que usan la guarda de respuesta posterior al progreso en lugar de liberar el carril de sesión inmediatamente. Solo los elementos agentMessage completados finales/no de comentario y las completaciones de asistente sin procesar previas a la herramienta arman la liberación de salida del asistente: si Codex luego queda en silencio sin turn/completed, OpenClaw interrumpe el turno nativo en modo de mejor esfuerzo y libera el carril de sesión. Los fallos del app-server stdio seguros para repetición, incluidos los tiempos de espera de finalización de turno sin evidencia de asistente, herramienta, elemento activo o efecto secundario, se reintentan una vez en un nuevo intento de app-server. Los tiempos de espera no seguros aun así retiran el cliente app-server bloqueado y liberan el carril de sesión de OpenClaw. También limpian el enlace obsoleto del hilo nativo en lugar de repetirse automáticamente. Los tiempos de espera de vigilancia de completación muestran texto de tiempo de espera específico de Codex: los casos seguros para repetición dicen que la respuesta puede estar incompleta, mientras que los casos no seguros indican al usuario que verifique el estado actual antes de reintentar. Los diagnósticos públicos de tiempo de espera incluyen campos estructurales como el último método de notificación del app-server, el id/tipo/rol del elemento de respuesta del asistente sin procesar, los recuentos de solicitudes/elementos activos y el estado de vigilancia armada. Cuando la última notificación es un elemento de respuesta de asistente sin procesar, también incluyen una vista previa acotada del texto del asistente. No incluyen contenido sin procesar de prompts ni de herramientas.

Descubrimiento de modelos

De forma predeterminada, el Plugin de Codex solicita al app-server los modelos disponibles. La disponibilidad de modelos pertenece al app-server de Codex, por lo que la lista puede cambiar cuando OpenClaw actualiza la versión empaquetada de @openai/codex o cuando un despliegue apunta appServer.command a un binario de Codex diferente. La disponibilidad también puede tener alcance de cuenta. Usa /codex models en un Gateway en ejecución para ver el catálogo en vivo de ese arnés y cuenta. Si el descubrimiento falla o agota el tiempo de espera, OpenClaw usa un catálogo de respaldo empaquetado:
ID de modeloNombre para mostrarEsfuerzos de razonamiento
gpt-5.5gpt-5.5low, medium, high, xhigh
gpt-5.4-miniGPT-5.4-Minilow, medium, high, xhigh
El arnés empaquetado actual es @openai/codex 0.142.5. Un sondeo model/list contra ese app-server empaquetado devolvió estas filas públicas del selector más allá del catálogo de respaldo:
ID de modeloModalidades de entradaEsfuerzos de razonamiento
gpt-5.5text, imagelow, medium, high, xhigh
gpt-5.4text, imagelow, medium, high, xhigh
gpt-5.4-minitext, imagelow, medium, high, xhigh
gpt-5.3-codex-sparktextlow, medium, high, xhigh
Las filas del selector en vivo tienen alcance de cuenta y pueden cambiar con la cuenta, el catálogo de Codex o la versión empaquetada; ejecuta /codex models para obtener la lista actual en lugar de depender de cualquier tabla puntual. Los modelos ocultos también pueden aparecer en el catálogo del app-server para flujos internos o especializados sin ser opciones normales del selector de modelos.
Ajusta el descubrimiento en plugins.entries.codex.config.discovery:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          discovery: {
            enabled: true,
            timeoutMs: 2500,
          },
        },
      },
    },
  },
}
Desactiva el descubrimiento cuando quieras que el inicio evite sondear Codex y use solo el catálogo de respaldo:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          discovery: {
            enabled: false,
          },
        },
      },
    },
  },
}

Archivos de arranque del espacio de trabajo

Codex gestiona AGENTS.md por sí mismo mediante el descubrimiento nativo de documentación de proyecto. OpenClaw no escribe archivos sintéticos de documentación de proyecto de Codex ni depende de nombres de archivo de respaldo de Codex para archivos de persona, porque los respaldos de Codex solo aplican cuando falta AGENTS.md. Para la paridad del espacio de trabajo de OpenClaw, el arnés de Codex reenvía los otros archivos de arranque como instrucciones de desarrollador, pero no de forma idéntica:
  • TOOLS.md se reenvía como instrucciones de desarrollador de Codex heredadas, por lo que los subagentes nativos de Codex creados durante el turno también lo ven.
  • SOUL.md, IDENTITY.md y USER.md se reenvían como instrucciones de colaboración con alcance de turno. Los subagentes nativos de Codex no las heredan, lo que evita que los turnos de subagente adopten la persona y el perfil de usuario del agente padre.
  • La lista compacta cargada de Skills de OpenClaw también se reenvía como instrucciones de desarrollador de colaboración con alcance de turno, por lo que los subagentes nativos de Codex tampoco la heredan.
  • El contenido de HEARTBEAT.md no se inyecta; los turnos de Heartbeat reciben un puntero en modo colaboración para leer el archivo cuando existe y no está vacío.
  • El contenido de MEMORY.md del espacio de trabajo de agente configurado no se pega en la entrada del turno nativo de Codex cuando hay herramientas de memoria disponibles para ese espacio de trabajo; cuando existe, el arnés agrega un pequeño puntero de memoria de espacio de trabajo a las instrucciones de desarrollador de colaboración con alcance de turno y Codex debería usar memory_search o memory_get cuando la memoria duradera sea relevante. Si las herramientas están desactivadas, la búsqueda de memoria no está disponible o el espacio de trabajo activo difiere del espacio de trabajo de memoria del agente, MEMORY.md usa en su lugar la ruta normal acotada de contexto de turno.
  • BOOTSTRAP.md, cuando está presente, se reenvía como contexto de referencia de entrada de turno de OpenClaw.

Sobrescrituras de entorno

Las sobrescrituras de entorno siguen disponibles para pruebas locales:
  • OPENCLAW_CODEX_APP_SERVER_BIN
  • OPENCLAW_CODEX_APP_SERVER_ARGS
  • OPENCLAW_CODEX_APP_SERVER_MODE=yolo|guardian
  • OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY
  • OPENCLAW_CODEX_APP_SERVER_SANDBOX
OPENCLAW_CODEX_APP_SERVER_BIN omite el binario gestionado cuando appServer.command no está definido. OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1 se eliminó. Usa plugins.entries.codex.config.appServer.mode: "guardian" en su lugar, o OPENCLAW_CODEX_APP_SERVER_MODE=guardian para pruebas locales puntuales. Se prefiere la configuración para despliegues repetibles porque mantiene el comportamiento del Plugin en el mismo archivo revisado que el resto de la configuración del arnés de Codex.

Relacionado