Supervisión de Codex

Objetivo

La supervisión de Codex permite que un operador de OpenClaw descubra sesiones nativas de Codex y, cuando sea seguro, cree una rama local mediante la interfaz normal de Chat de OpenClaw. Codex App Server continúa siendo el propietario del hilo y del bucle del modelo. OpenClaw proporciona el catálogo de la flota, la interfaz de operador autenticada, la vinculación de sesiones y la entrega por canales.

La función pertenece al Plugin oficial codex. No hay un Plugin Supervisor independiente ni una segunda implementación del protocolo de Codex.

Límite del producto

El catálogo se registra siempre que el Plugin de Codex está activo. Habilite las herramientas de supervisión orientadas a agentes con:

plugins.entries.codex.config.supervision.enabled = true

El producto inicial activo es intencionadamente más limitado que el plan de flota a largo plazo:

• Enumerar únicamente los hilos de Codex no archivados.
• Agrupar las filas locales y de nodos emparejados que hayan aceptado participar según la identidad estable del host.
• Crear una rama de Chat normal y bloqueada al modelo a partir de un hilo almacenado o inactivo local al Gateway, iniciar su hilo completo del entorno de Codex en el primer turno o abrir el Chat creado para una rama anterior.
• Archivar un hilo almacenado o inactivo local al Gateway solo después de una confirmación explícita de que no hay otro ejecutor.
• Mostrar las fuentes locales activas sin controles para crear ramas nuevas ni archivar, pero permitir que se abra un Chat supervisado existente.
• Mostrar las filas más recientes de cada host en la barra lateral principal, mantener el catálogo completo en la página de sesiones y proporcionar lecturas de transcripciones limitadas y paginadas mediante cursor para las filas locales y de nodos emparejados.
• Aislar por host los fallos del catálogo.

El catálogo es la colección de elementos no archivados. Una fila de esta colección puede seguir teniendo un estado de turno inactivo, activo, notLoaded o de error.

La supervisión orientada a agentes sigue siendo opcional. La incorporación guiada intenta instalarla y habilitarla después de detectar correctamente una instalación nativa de Codex y de que el backend de inferencia seleccionado supere su comprobación en vivo, independientemente del backend principal que seleccione el usuario. La supervisión solo se activa cuando la configuración oportunista del Plugin se completa correctamente. Un Plugin deshabilitado explícitamente, un bloqueo por políticas o supervision.enabled: false siguen teniendo autoridad sobre las herramientas de supervisión, pero no deshabilitan el catálogo de sesiones del operador.

Propiedad

El Plugin codex es propietario de todo el comportamiento de Codex App Server:

• descubrimiento de endpoints y ciclo de vida de la conexión
• inicialización del protocolo y comprobaciones de versión
• listado, lectura, reanudación, archivado y gestión de eventos de hilos
• puentes de aprobación y entrada del usuario
• vinculaciones de hilos nativos con sesiones de OpenClaw
• aplicación del modelo y del entorno exclusivos de Codex después de la continuación

La interfaz de control y el Gateway consumen ese servicio propiedad del Plugin. No leen directamente los archivos de despliegue de Codex ni implementan otro cliente de App Server.

La topología local predeterminada es:

Codex Desktop -> App Server privado mediante stdio -> directorio de inicio de Codex del usuario                                                     ^Plugin de Codex de OpenClaw -> conexión de App Server de supervisión  (de forma predeterminada, stdio administrado del directorio de inicio del usuario; se respetan los ajustes explícitos de appServer)  -> catálogo pasivo de fuentes y lectura  -> fijación de instantánea -> rama canónica de origen appServer  -> inyección del historial visible y cada turno posterior del Chat supervisado Sesiones ordinarias de Codex de OpenClaw -> stdio administrado del directorio de inicio del agente de forma predeterminada  -> hilos ordinarios del entorno completo -> Chat de OpenClaw y entrega por canales

Habilitar la supervisión no cambia el entorno ordinario de Codex: sigue estando limitado al agente de forma predeterminada. La conexión de supervisión independiente utiliza de forma predeterminada stdio administrado del directorio de inicio del usuario, por lo que sus operaciones de catálogo e instantáneas ven los hilos nativos almacenados. Se respetan los ajustes explícitos de conexión de appServer. Cuando homeScope no está definido, la conexión de supervisión lo resuelve como "user" para stdio o Unix y como "agent" para WebSocket. Establezca appServer.homeScope: "user" explícitamente solo cuando el entorno ordinario también deba compartir el directorio de inicio nativo de Codex. Un Chat adoptado desde el grupo de Codex de la barra lateral es la excepción: su vinculación privada de supervisión mantiene las lecturas de la fuente, la creación de la rama canónica y los turnos posteriores en la conexión de supervisión. El estado en vivo y la propiedad siguen siendo locales al proceso; un hilo desconocido para el proceso de supervisión de OpenClaw es notLoaded aunque Codex Desktop lo esté ejecutando activamente.

Codex tiene un daemon local canónico experimental con un contrato de arranque independiente administrado por el instalador. Esta función no debe arrancar, reclamar ni asumir implícitamente ese daemon.

Flujo del catálogo

El método genérico del Gateway sessions.catalog.list delega en el proveedor de catálogo codex, que siempre solicita archived: false y los tipos de fuente interactivos cli y vscode. Combina:

1. Los resultados de thread/list locales al Gateway procedentes del App Server de supervisión, que utiliza de forma predeterminada stdio administrado del directorio de inicio del usuario.
2. Los resultados de codex.appServer.threads.list.v1 de cada nodo conectado que haya aceptado participar.

La selección de transcripciones utiliza thread/turns/list con itemsView: "full" localmente o el comando con versión codex.appServer.thread.turns.list.v1 en el nodo seleccionado. Cada respuesta contiene como máximo 20 turnos persistidos, además de cursores opacos hacia delante y hacia atrás. La interfaz de control solicita las páginas de la más reciente a la más antigua, representa cada página en orden cronológico y antepone las páginas anteriores. Nunca recurre a una lectura thread/read sin límites. OpenClaw también rechaza cualquier página de elementos serializada que supere 20 MiB antes de que pueda atravesar el transporte del nodo o del Gateway.

La implementación nativa de nodos emparejados de macOS solo admite un valor no definido/predeterminado o un valor explícito appServer.transport: "stdio" con un ámbito de supervisión no definido/predeterminado o un valor explícito appServer.homeScope: "user". Transmite command, args y clearEnv normalizado configurados al proceso secundario. Con "unix", "websocket" o un valor explícito homeScope: "agent", no anuncia ni la capacidad del catálogo ni el comando; la invocación directa también se cierra de forma segura. Nunca debe exponer el directorio de inicio de Codex del usuario para una configuración limitada al agente ni sustituir un endpoint explícito por stdio local.

La proyección del catálogo normaliza identificadores, título, cwd, estado, indicadores de espera activa, marcas de tiempo, fuente, proveedor del modelo, versión de Codex y rama de Git. No devuelve vistas previas de transcripciones, turnos, rutas de despliegue, rutas del directorio de inicio de Codex, remotos de Git, SHA de commits, endpoints sin procesar ni errores sin procesar de App Server. Las respuestas de transcripciones solo contienen la página de elementos de App Server solicitada explícitamente y sus cursores opacos.

Los fallos de los hosts permanecen aislados en el resultado de cada host. Un nodo sin conexión o un App Server local no disponible no elimina de la página los hosts en buen estado. La conectividad es una propiedad del host, no un estado del hilo: el resultado de un host fallido no contiene filas de sesiones recientes ni proyecta offline sobre los hilos nativos.

El descubrimiento del catálogo es pasivo. Listar o leer metadatos no debe llamar a thread/resume, suscribir al cliente de OpenClaw a solicitudes de hilos en vivo ni responder a una aprobación.

La búsqueda se realiza solo por título y no distingue entre mayúsculas y minúsculas. Para cada página del catálogo devuelta, el Gateway y el Mac emparejado examinan un número limitado de páginas nativas sin pasar la consulta a App Server, ya que la búsqueda nativa también puede encontrar coincidencias en vistas previas de transcripciones. El cursor nativo devuelto permite que los llamadores continúen el examen.

Límite de la CLI del operador

El Plugin registra tres comandos de shell respaldados por el Gateway:

openclaw codex sessions [--search <text>] [--host <id>] [--limit <count>] [--cursor <cursor>] [--json] [gateway-options]openclaw codex continue <thread-id> [--json] [gateway-options]openclaw codex archive <thread-id> --confirm-no-other-runner [--json] [gateway-options]

[gateway-options] corresponde a --url <url>, --token <token>, --timeout <ms> y la opción heredada --expect-final. El listado de sesiones tiene un tiempo de espera predeterminado de 75,000 ms; la continuación y el archivado tienen un valor predeterminado de 30,000 ms; --expect-final no tiene ningún efecto adicional en estas RPC unarias. La búsqueda de sesiones se realiza solo por título y no distingue entre mayúsculas y minúsculas; cada respuesta examina una cadena limitada de páginas nativas y --cursor continúa con resultados más antiguos. El límite predeterminado es de 50 por host, acepta valores de 1 a 100 y un cursor requiere un único destino --host estable. Ningún comando acepta una opción para elementos archivados o para incluirlos. Solo sessions puede dirigirse a hosts emparejados; continue y archive siempre envían hostId: "gateway:local", y el archivado requiere la opción de confirmación explícita.

El espacio de nombres del shell no es el espacio de nombres de ejecución de /codex dentro del Chat. En particular, /codex sessions --host <node> enumera los archivos de sesión de la CLI de Codex en un nodo, /codex threads enumera los hilos de App Server de la conexión de la conversación actual y /codex resume o /codex bind modifica la vinculación de esa conversación. Esos comandos no sustituyen a sessions.catalog.continue y no existe ningún comando de ejecución /codex continue ni /codex archive.

Continuación local

Para una fila almacenada o inactiva local al Gateway, la interfaz llama a sessions.catalog.continue con catalogId: "codex", además de los identificadores del host y del hilo. El Plugin:

1. Reutiliza el Chat supervisado existente cuando la fuente ya tiene uno.
2. De lo contrario, proyecta el historial limitado del usuario y del asistente hasta el último turno terminal persistido de la fuente (completado, interrumpido o fallido) en un nuevo Chat de OpenClaw y registra una rama pendiente del entorno.
3. Almacena la política pendiente de bloqueo exclusiva para modelos de Codex, no una selección concreta de modelo o proveedor, junto con el ámbito privado de la conexión de supervisión, y devuelve la sessionKey de OpenClaw.

La proyección del historial selecciona la parte final más reciente de los mensajes visibles del usuario y del asistente, con límites estrictos de 200 mensajes, 512 KiB de texto UTF-8 en total y 64 KiB por mensaje. Sustituye las entradas de imagen e imagen local por [Image attachment], nunca copia cargas útiles ni rutas de imágenes y omite el razonamiento, las llamadas a herramientas y los resultados de herramientas.

La interfaz navega al Chat normal con esa clave de sesión. Todavía no existe ningún hilo canónico del entorno. En el primer turno normal del Chat, el entorno instala los gestores reales de aprobación, obtención de información, eventos y entrega de Codex y, después:

1. Utiliza la conexión de supervisión para llamar a thread/fork nativo sin anular el modelo ni el proveedor y fijar la instantánea persistida de la fuente. El estado actual de ConfigManager de Codex selecciona el modelo y el proveedor, y la respuesta de la bifurcación informa de la pareja real. Si el modelo difiere del último modelo registrado en la fuente, Codex emite su advertencia normal de diferencia de modelo.
2. En esa misma conexión, inicia el hilo canónico del entorno completo de Codex con threadSource: "appServer", el cwd, la política, la configuración y el entorno de OpenClaw, la superficie completa de herramientas del entorno de OpenClaw y exactamente el modelo y el proveedor devueltos por la bifurcación para este inicio inicial.
3. Inyecta mediante esa conexión el historial limitado visible del usuario y del asistente, confirma la vinculación canónica sin descartar su ámbito de supervisión, ejecuta el turno y archiva la bifurcación temporal.

Antes del primer turno, el Chat es una rama pendiente bloqueada con una copia visible del historial; después, cada turno del modelo se ejecuta mediante el hilo canónico del entorno de Codex en la conexión de supervisión. La rama no es un clon completo de un despliegue nativo: el razonamiento, las llamadas a herramientas y los resultados de herramientas de la fuente se omiten deliberadamente. Si falla la fijación de la instantánea o la creación del hilo canónico, la rama pendiente permite volver a intentarlo. Una condición de carrera en la vinculación, la supervisión deshabilitada o una conexión de supervisión no disponible o incompatible provoca un cierre seguro antes de ejecutar el turno, en lugar de recurrir al entorno ordinario del directorio de inicio del agente.

Esto garantiza una selección propiedad de Codex, no la conservación del modelo histórico de la fuente. La pareja devuelta por la bifurcación se utiliza para iniciar el hilo canónico y Codex persiste el modelo y el proveedor nativos de ese hilo. Las reanudaciones posteriores omiten las anulaciones de modelo y proveedor de OpenClaw, por lo que Codex restaura la pareja persistida. Si un control nativo independiente de Codex cambia el hilo canónico, OpenClaw acepta esa selección nativa persistida. El modelo externo de OpenClaw y la cadena de reserva nunca la sustituyen.

Los cambios de modelo y las operaciones de eliminación, restablecimiento o creación de sesión fallan de forma segura en el Chat supervisado con modelo bloqueado. Las operaciones mutantes /codex model <model>, /codex bind, /codex resume (incluido --bind here del Node) y /codex detach o /codex unbind también fallan de forma segura porque sustituyen o eliminan la vinculación. La consulta /codex model y /codex fast, /codex permissions y /codex threads siguen disponibles. La herramienta de agente codex_threads no puede adjuntar una bifurcación nueva ni archivar el hilo nativo vinculado. La lectura de listas y solo metadatos sigue disponible; los campos de transcripción requieren supervision.allowRawTranscripts, mientras que cambiar el nombre, desarchivar, crear una bifurcación desvinculada y archivar un hilo no relacionado requieren supervision.allowWriteControls. Ninguna opción puede sustituir la vinculación bloqueada. De lo contrario, eliminar o restablecer la entrada de OpenClaw descartaría la vinculación nativa y crearía o permitiría un hilo genérico detrás de una sesión con apariencia de Codex. Por ello, el mantenimiento de retención conserva las entradas con modelo bloqueado incluso cuando superan los límites habituales de antigüedad, cantidad o presupuesto de disco. Deshabilitar o desinstalar el plugin propietario también conserva el bloqueo y el marcador de propiedad del plugin. El Chat permanece no disponible y falla de forma segura hasta que se vuelve a habilitar el mismo plugin; la limpieza nunca lo convierte en una sesión de modelo ordinaria.

Esta acción nunca reanuda ni modifica el origen. La bifurcación temporal fija una instantánea; no es el hilo de continuación persistente. Iniciar un hilo distinto del entorno canónico en el primer turno evita que OpenClaw se convierta en un escritor de origen competidor solo porque el estado local del proceso no detectó un turno propiedad de Desktop. El reflejo del historial visible y la instantánea fijada pueden omitir trabajo que aún no haya finalizado en un origen activo. El origen original de la CLI o VS Code sigue siendo apto para los catálogos nativo y de OpenClaw. La rama canónica sigue siendo un hilo nativo de Codex en el almacén de supervisión, pero los clientes nativos pueden filtrar su tipo de origen appServer, por lo que la visibilidad en Codex Desktop no es un contrato.

Comportamiento del archivado

Para una fila almacenada o inactiva local del Gateway, sessions.catalog.archive con catalogId: "codex" requiere confirmNoOtherRunner: true explícito, vuelve a leer el estado local actual del proceso, continúa solo si es idle o notLoaded, llama a thread/archive nativo y devuelve éxito solo después de que Codex acepte la operación. A continuación, la fila deja el catálogo de elementos no archivados.

Un estado activo o de error de la lectura nueva rechaza el archivado. También lo hace una rama supervisada en inicialización o pendiente procedente del origen: el primer turno del Chat debe materializar su rama canónica antes de poder archivar el origen. Un propietario de vinculación activo y conocido de OpenClaw para el destino exacto o cualquier descendiente generado y no archivado también rechaza el archivado. OpenClaw pagina la relación experimental thread/list ancestorThreadId de Codex y falla de forma segura ante errores de solicitud o respuesta, ciclos de cursores o hilos y el agotamiento del límite de seguridad. El archivado nativo puede detener el trabajo cargado del elemento principal y sus descendientes, por lo que el archivado no es un atajo para interrumpir. Las llamadas de lectura, enumeración de descendientes y archivado no son atómicas. Un cliente independiente aún puede poseer o iniciar trabajo en una fila que localmente parece inactiva o notLoaded. La confirmación de que no hay otro ejecutor cubre a los clientes desconocidos y esa condición de carrera hasta que Codex disponga de archivado condicional o un arrendamiento entre procesos. El archivado de nodos emparejados está prohibido.

No hay una vista de elementos archivados en el catálogo de Codex. Un hilo restaurado mediante thread/unarchive en otra superficie de Codex autorizada por el propietario vuelve a ser apto para el catálogo de elementos no archivados.

Seguridad de los hilos activos

Codex serializa las modificaciones de un hilo entre los clientes de un App Server, pero no expone un arrendamiento exclusivo entre procesos para el ejecutor o el propietario de las aprobaciones. Los App Servers de stdio independientes pueden añadir contenido al mismo despliegue, mientras cada uno ve solo su propio estado en memoria. Las solicitudes de aprobación también pueden llegar a todos los suscriptores de un servidor, y la primera respuesta válida completa la solicitud.

Por lo tanto:

• los clientes pasivos del catálogo no se suscriben a las aprobaciones ni las deniegan automáticamente
• las filas que se indican actualmente como activas no exponen ni una rama nueva ni la opción Archive
• un origen sin asignar se convierte en una rama de historial visible cuyo hilo canónico del entorno nunca reanuda el origen
• notLoaded se muestra como actividad desconocida y solo se puede archivar tras una confirmación informada de que no hay otro ejecutor
• el archivado local requiere esa confirmación junto con una lectura nueva idle o notLoaded, al tiempo que reconoce la condición de carrera del protocolo entre la lectura y el archivado

La interrupción y la transferencia entre varios clientes son decisiones futuras del producto. No están implícitas por mostrar una fila activa.

Límite de nodos emparejados

La invocación de Node actualmente solo admite solicitud y respuesta. Puede devolver de forma segura metadatos acotados del catálogo y páginas de turnos de transcripción, pero no puede transportar el flujo de eventos de larga duración, las solicitudes de aprobación, las llamadas a herramientas, la cancelación ni los incrementos del asistente necesarios para una ejecución del entorno de Codex.

Por tanto, el contrato del Node admite listas y páginas de turnos de transcripción. Las filas remotas siguen siendo legibles, pero Continue y Archive no están disponibles, independientemente del estado de inactividad. Una continuación remota real requiere un ejecutor en el Node y un puente de transmisión que conserve las mismas invariantes de aprobación y vinculación que el entorno local.

Permisos

Cada equipo concede su aceptación localmente. Habilitar el Gateway no autoriza a otro Node a leer sus metadatos de Codex. La capacidad del Node debe superar el emparejamiento normal y la aprobación de la política de comandos.

El listado de la flota y la visualización de transcripciones usan el ámbito operator.write del Gateway porque invocan nodos emparejados. La continuación y el archivado locales son acciones autenticadas del operador y siguen sujetos a comprobaciones del host y del estado.

El acceso autónomo de agentes y el acceso independiente mediante MCP son ámbitos separados. Los contratos de herramientas incluidos codex_endpoint_probe, codex_sessions_list, codex_session_read, codex_session_send y codex_session_interrupt siguen siendo propiedad del plugin codex. Con la supervisión habilitada, las lecturas de transcripciones sin procesar de codex_threads y los campos de listas derivados de transcripciones también requieren supervision.allowRawTranscripts; cada bifurcación, cambio de nombre, archivado o desarchivado mediante codex_threads requiere supervision.allowWriteControls. Ambas políticas están deshabilitadas de forma predeterminada.

Compatibilidad

openclaw doctor --fix migra la configuración incluida de plugins.entries.codex-supervisor, incluidos los extremos y las políticas de transcripción/escritura, además de las referencias de permisión/denegación de plugins, a plugins.entries.codex.config.supervision. Los valores canónicos explícitos de destino prevalecen en caso de conflicto. El código en tiempo de ejecución usa únicamente la forma canónica del plugin codex después de la migración.

El plugin oficial conserva exactamente cinco herramientas de compatibilidad de Supervisor: codex_endpoint_probe, codex_sessions_list, codex_session_read, codex_session_send y codex_session_interrupt. De forma predeterminada, la lista de sesiones solo incluye las cargadas; no hay ningún parámetro loaded_only. include_stored: true añade filas no archivadas de la base de datos de estado, limitadas por extremo mediante max_stored_sessions (valor predeterminado 200, intervalo aceptado de 1 a 1,000); las filas cargadas no están limitadas por esa configuración. Los campos derivados de transcripciones y las lecturas siguen sujetos a allowRawTranscripts; el envío y la interrupción siguen sujetos a allowWriteControls.

El envío de compatibilidad nunca inicia ni reanuda un hilo inactivo. mode: "start" se rechaza siempre; "auto" y "steer" solo dirigen un turno activo legible. La interrupción también requiere un turno activo legible. La continuación inactiva se dirige al catálogo nativo de Codex para que el entorno completo sea propietario de las aprobaciones, las herramientas y la vinculación. El adaptador MCP heredado independiente resuelve estas mismas herramientas desde el plugin oficial y es la única ruta que respeta las variables de entorno de políticas heredadas que se conservan.

La interfaz de usuario del catálogo de julio, el método del Gateway, la capacidad del Node y el registro en la CLI no se habían publicado con el identificador anterior del plugin. Pasan directamente a ser propiedad de codex sin una segunda fachada de tiempo de ejecución.

Trabajo futuro

• ejecutor de transmisión en el Node y puente de eventos para la continuación remota
• arrendamientos explícitos del ejecutor y del propietario de aprobaciones para la transferencia simultánea entre clientes
• archivado remoto una vez que exista un arrendamiento de propiedad del ejecutor o una protección equivalente
• interrupción y observación más completa de sesiones activas
• transferencia auditada entre Codex Desktop, la CLI y OpenClaw

La exploración de elementos archivados no forma parte de la barra lateral de supervisión planificada. Las superficies nativas de Codex siguen siendo la ruta de recuperación de los hilos archivados.

Pruebas de aceptación

• Al habilitar la supervisión, se enumeran las sesiones locales no archivadas.
• Las sesiones archivadas nunca aparecen en la respuesta del catálogo ni en la interfaz de usuario.
• Los hosts en buen estado siguen visibles cuando otro host falla; un host no disponible no devuelve filas nuevas en lugar de inventar un estado de sesión sin conexión.
• Una fila local almacenada o inactiva crea un reflejo de Chat con un bloqueo de modelo/entorno exclusivo de Codex; el primer turno fija una instantánea temporal e inicia el hilo canónico del entorno completo, y repetir Continue abre el Chat existente.
• El primer turno omite las sustituciones del modelo/proveedor en la bifurcación de la instantánea y fija el inicio canónico al par exacto devuelto por Codex, incluso cuando Codex advierte que su modelo actual difiere del último modelo registrado del origen.
• Las vinculaciones supervisadas pendientes y confirmadas usan la conexión de supervisión para acceder al origen, crear la rama canónica y ejecutar cada turno posterior; las sesiones ordinarias de Codex siguen limitadas al agente.
• Las reanudaciones posteriores omiten las sustituciones de modelo/proveedor de OpenClaw, conservan la selección persistente canónica de Codex, aceptan cambios nativos independientes en ese hilo y nunca sustituyen el modelo externo de OpenClaw ni la cadena de reserva.
• Deshabilitar la supervisión o perder el ciclo de vida de la vinculación/conexión falla de forma segura en lugar de trasladar el Chat al entorno ordinario del directorio principal del agente.
• Un Chat supervisado con modelo bloqueado no se puede eliminar mientras protege la vinculación nativa.
• El Chat refleja como máximo 200 mensajes de usuario y del asistente, 512 KiB en total y 64 KiB por mensaje. Las imágenes se convierten en marcadores de posición; no se clonan el razonamiento del origen, las llamadas a herramientas, los resultados de herramientas, las cargas de imágenes ni las rutas locales.
• El flujo de la rama nunca reanuda el hilo de origen.
• El origen original sigue siendo apto para ambos catálogos. La rama nativa canónica usa el tipo de origen appServer y no se garantiza que aparezca en Codex Desktop.
• Los orígenes locales activos no pueden crear una rama ni archivarse; un Chat supervisado existente aún se puede abrir.
• Las filas con actividad desconocida pueden crear una rama sin confirmación; el archivado requiere una confirmación explícita de que no hay otro ejecutor.
• Un origen con una rama supervisada en inicialización o pendiente no se puede archivar hasta que el primer turno del Chat materialice la rama canónica.
• Un propietario de vinculación activo y conocido para el destino exacto o cualquier descendiente generado y no archivado bloquea el archivado; los fallos de enumeración de descendientes fallan de forma segura y la confirmación explícita sigue siendo responsable de los clientes desconocidos y la condición de carrera entre el estado y el archivado.
• El archivado local confirmado de una fila almacenada o inactiva elimina la fila tras el éxito nativo.
• Las filas de nodos emparejados siguen visibles sin Continue ni Archive.
• El listado pasivo nunca se suscribe a las aprobaciones de hilos ni responde a ellas.
• La configuración heredada de Supervisor se migra a la forma canónica de configuración de Codex.
• La lista heredada solo incluye las sesiones cargadas de forma predeterminada, la enumeración de elementos almacenados respeta su límite por extremo y el envío de compatibilidad nunca inicia ni reanuda un hilo inactivo.