codex-master

The Hive (nombres heredados: codex-master, codex-master-mcp y Masterjet) es el plano de control MCP local para una flota de Codex Agentinnen dormida/escalable. El Fleet Registry es la autoridad para las series activas; la especificación de pool heredada se mantiene solo por compatibilidad.

Las fuentes Wiki locales versionadas comienzan en docs/wiki/Home.md. Siguen siendo canónicas en este repositorio; no se implica publicación en GitHub Wiki. Contrato de Fleet-Overview, G-Serie y Goddess-Reporting: docs/operations/goddess-reporting.md.

Ciclo de vida del operador H4 del monitor de recursos

codex-master-resource-monitor.service ejecuta el punto de entrada sin argumentos %h/.local/bin/codex-master-resource-monitor. Recibe solo el almacén de estado Hive compuesto centralmente y publica generaciones completas de un Hz bajo su subárbol fijo resources. El ciclo de vida H4 es independiente de la instalación principal.

Por defecto, codex-master-resource-monitor.service se entrega pero no se instala ni está activo. Ningún instalador, herramienta MCP o prueba estándar habilita o inicia esta unidad implícitamente; solo estos explícitos comandos de operador lo hacen:

./bin/codex-master-mcp install-resource-monitor --force
./bin/codex-master-mcp resource-monitor-status

El instalador valida tanto las unidades de repositorio regulares acotadas como ambas unidades objetivo antes de la mutación. Un bloqueo de proceso cooperativo (install_lock()/flock) abarca la validación de origen, el staging, la transacción, la recarga del daemon, la activación y el rollback. Serializa los procesos de instalación cooperativos; la manipulación del mismo UID/root o del espacio de nombres User-Systemd fuera de este límite no es una amenaza de mutex adversarial cubierta por H4. Las lecturas de origen usan FDs sin seguimiento con comprobaciones de identidad/tipo/tamaño/modo/mtime antes y después de lecturas acotadas. La cadena de directorios objetivo se crea de forma segura solo para el sufijo faltante, luego se fija mediante FD más (dev, ino); los ancestros inseguros, los enlaces simbólicos o los directorios existentes con escritura de grupo/mundo fallan de forma cerrada. Los ancestros sticky compartidos están permitidos; el ~/.config/systemd/user final debe ser propiedad del usuario y no tener escritura de grupo/mundo.

Ambas unidades se preparan y validan antes de la primera mutación. Las unidades existentes se mueven relativamente al FD a copias de seguridad únicas inspeccionadas. Las unidades preparadas se instalan con link sin reemplazo; EEXIST preserva el objetivo extranjero. Los registros por unidad documentan identidades originales/preparadas, durabilidad, movimientos, restauraciones y limpieza. El rollback elimina solo la identidad instalada registrada, restaura las copias de seguridad sin sobrescritura, preserva archivos/copias de seguridad extranjeros e informa recuperación manual cuando sea necesario. No se infieren bytes ni modos durante el rollback.

Después de que ambas mutaciones de unidad sean duraderas, el instalador reabre la ruta objetivo original sin seguimiento y revalida el (dev, ino) fijado, la identidad de bloqueo canónica mantenida y ambas identidades de unidad instaladas registradas antes de la recarga del daemon y nuevamente antes de enable --now. Cualquier discrepancia impide la siguiente operación externa, incluida la recarga/estimación de estado del rollback; el rollback de archivos usa solo el FD fijado. El reenlace del padre significa que no hay recarga primaria y el rollback a través del FD original. La recarga del daemon se ejecuta antes de enable/start, y solo codex-master-resource-monitor.service se habilita/inicia; el slice nunca se habilita/inicia por separado.

Esto no es un reemplazo atómico de pares. Cada operación es atómica por archivo/nombre, pero un bloqueo entre los dos renames puede dejar un par mixto. El registro del proceso está en memoria y se pierde en un bloqueo. La recuperación usa entonces solo evidencia del sistema de archivos, estado de unidad/systemd, resource-monitor-status e inspección/recuperación manual. El estado detecta estado mixto o extranjero y el operador debe recuperar manualmente. El rollback intenta independientemente ambas unidades, limpieza de temp/copias de seguridad, recarga del daemon, restauración de UnitFileState y restauración de ActiveState. El estado desconocido no causa ninguna suposición. El not-found inicial es válido solo con LoadState=not-found inactivo; de lo contrario, UnitFileState debe ser disabled, enabled o enabled-runtime, y ActiveState debe ser active/inactive. La restauración de estado usa banderas exactas persistentes vs de tiempo de ejecución y nunca omite la recuperación de ActiveState después de un fallo de UnitFileState. Los errores públicos contienen solo códigos/códigos de retorno, nunca rutas ni salida sin procesar.

La presencia del manifiesto no es confianza de hook. Los informes de cobertura nativa V2 faltantes, malformados, no canónicos o obsoletos devuelven manual_hook_trust_or_new_session_required; solo una nueva sesión regular de Codex después de la confianza explícita del usuario /hooks crea cobertura V2 fresca. Ningún comando automatiza la confianza ni edita el estado nativo sintético.

Un codex-master.slice inactivo sin hijos se espera solo con un FragmentPath real y una unidad materializada. Un FragmentPath faltante o sintético es un bloqueador, no un estado instalado. El estado listo requiere fragmentos reales para ambas unidades, un hijo monitor activo y una instantánea válida reciente. La generación en vivo se ofrece solo cuando resource-monitor-status está verde. El comportamiento principal de install no cambia. ProtectHome=tmpfs y PrivatePIDs=yes ocultan datos de Home y procesos no relacionados. BindReadOnlyPaths expone solo el diseño del monitor instalado, los catálogos fijos y el estado Hive central; D8 mantiene el acceso de escritura limitado a resources y al bloqueo existente.

• /home/teladi/.codex-agents/a1 hasta /home/teladi/.codex-agents/a100

• /home/teladi/.codex-agents/b1 hasta /home/teladi/.codex-agents/b100

• /home/teladi/.codex-agents/c1 hasta /home/teladi/.codex-agents/c100

Los selectores heredados a y b se asignan a a1 y b1; both se asigna a a1,b1. Los selectores de serie a-series, b-series, c-series y all están disponibles para estado, habilidades, capacidades, estado de arrendamiento, inicio/parada y llamadas de watchdog. Los selectores no distinguen entre mayúsculas y minúsculas, por lo que A1, a1, A-Series y a-series se resuelven de manera idéntica. Los selectores numéricos de un solo Agentin usan la política de selector actual. La política predeterminada es alternar A/B: 1=a1, 2=b1, 3=a2, 4=b2, y así sucesivamente. Cámbiela con:

./bin/codex-master-mcp selector-policy --series a,b,c
./bin/codex-master-mcp selector-preview --series a,b,c --limit 6

La política se almacena en el estado MCP privado y también se puede anular para un proceso con CODEX_MASTER_AGENT_SELECTOR_SERIES=a,b,c. Las Teamleiterinnen pueden generar fremde Bienen directamente a través del Masterjet con agent_start, agent_claim y las herramientas estructuradas agent_assign*. Los arrendamientos, las comprobaciones de autenticación y los ámbitos de escritura son el límite de coordinación; no son una razón para evitar usar fremde Bienen disponibles. Los hogares autenticados originales se conservan como a1 y b1. Los hogares adicionales son intencionalmente delgados y dormidos por defecto; tienen su propio CODEX_HOME, wrapper, configuración, nombre de sesión tmux, arrendamiento y metadatos, mientras que los archivos grandes de caché de habilidades/plugins/modelos de solo lectura pueden estar enlazados simbólicamente desde una plantilla de serie. Los hogares de la serie C no están autenticados intencionalmente hasta que otra cuenta esté disponible.

El wrapper inicia instancias a través de sus archivos de lanzador codex por hogar. Antes de que la resolución central proporcione una tupla efectiva, su valor predeterminado base es gpt-5.6-luna con razonamiento medio:

--model gpt-5.6-luna -c 'model="gpt-5.6-luna"' -c 'model_reasoning_effort="medium"' --yolo -s danger-full-access --search

Utiliza tmux como backend de PTY. La salida completa del terminal se escribe únicamente en archivos de estado locales bajo ~/.local/state/codex-master-mcp/raw/. Los nuevos registros sin procesar se limitan a 5 MiB por archivo, y los directorios de registros sin procesar gestionados mantienen como máximo 20 archivos por defecto. Los archivos de registro sin procesar preparados se crean con semántica exclusiva sin seguimiento. El escritor directo de registros sin procesar también requiere que los directorios de estado gestionados y sus cadenas de directorios padre sean directorios reales, no enlaces simbólicos, y los directorios de registros sin procesar heredados se ignoran cuando son enlaces simbólicos. Los ejecutores de Agentin deben ser archivos ejecutables regulares, no enlaces simbólicos. Las lecturas de registros de asignación requieren archivos regulares, están limitadas y usan errores genéricos. Los errores de archivos y directorios de estado privados son genéricos y evitan devolver rutas de estado locales. Las comprobaciones de presencia de metadatos de Agentin no siguen enlaces simbólicos, las lecturas de metadatos rechazan archivos enlazados simbólicamente y de tamaño excesivo, y los errores de lectura de metadatos usan marcadores genéricos en lugar de rutas de archivo locales. Las lecturas de registros de cola segura ignoran los destinos de registros sin procesar no regulares. Los errores de control de tmux se redactan y limitan antes de devolverse o lanzarse. Las respuestas de herramientas MCP no devuelven salida sin procesar por defecto y exponen la presencia de registros sin procesar sin devolver rutas locales de registros sin procesar. El texto se pega en la TUI de Codex a través de tmux y se envía con Enter simple. Las indicaciones multilínea usan marcadores de pegado entre corchetes para que la indicación completa permanezca como una entrada de composición antes del envío.

Antes de pegar, send, assign-* y report-request esperan brevemente un marcador identificable de indicación de entrada de la TUI de Codex en la cola del panel visible actual. Si el Agentin todavía está en advertencias de inicio, solo muestra texto de inicio, o no se ve ninguna indicación de entrada, la mutación falla de forma cerrada con agent_input_not_ready reintentable, paste_attempted: false y raw_output: not_returned en lugar de perder la indicación en la pantalla de inicio. Los metadatos existentes bajo el antiguo directorio de estado codex-agent-mcp todavía se leen como respaldo de migración. Los subprocesos externos de tmux, git y codex mcp están limitados por tiempo de espera para que las llamadas MCP fallen de forma cerrada en lugar de colgarse indefinidamente. Las comprobaciones de registro MCP comparan el campo command: exacto de codex mcp get, no una subcadena amplia en la salida del comando. Las operaciones del ciclo de vida de Agentin que mutan o envían a sesiones de tmux se serializan por Agentin con archivos de bloqueo privados sin seguimiento, de modo que diferentes Agentinnen pueden seguir ejecutándose de forma independiente mientras que los inicios/paradas/envíos concurrentes para el mismo Agentin no pueden intercalarse. Si tmux new-session falla antes de que este proceso cree una sesión, la limpieza elimina solo el registro sin procesar preparado y no mata una sesión existente que pueda pertenecer a otro proceso MCP. Las herramientas de mutación también usan un arrendamiento por Agentin, por lo que dos instancias de Codex-CLI no pueden asignar o enviar silenciosamente al mismo Agentin al mismo tiempo. Los conflictos de arrendamiento devuelven metadatos de reintento estructurados (error_code, retryable, retry_after_seconds y los segundos restantes del arrendamiento) sin exponer la identidad del cliente. agent_claim reintenta para siempre por defecto cuando una fremde Biene está ocupada; los valores finitos de wait_seconds siguen disponibles pero no están limitados a 600 segundos. Use --no-wait para un único intento de reclamación inmediato. El intervalo de sondeo predeterminado es de 30 segundos y el intervalo máximo de sondeo es de 900 segundos.

Las reclamaciones explícitas también recuperan un arrendamiento retenido por un agente externo cuando el Agentin ya no se está ejecutando, ningún proceso está usando ese hogar de Agentin y la evidencia local de inactividad tiene al menos 120 segundos de antigüedad. Esta recuperación de huérfanos detenidos se puede deshabilitar con --no-recover-stopped; no se aplica a mutaciones implícitas de envío/reporte/interrupción y nunca anula un Agentin externo en ejecución. Las invocaciones CLI de corta duración derivan un propietario estable y oculto de CODEX_THREAD_ID cuando Codex lo proporciona, de modo que la misma Schwesterinstanz puede reclamar, asignar, solicitar informes y liberar a través de llamadas CLI separadas. CODEX_MASTER_MCP_INSTANCE_ID sigue siendo una anulación explícita para sesiones controladas. La identidad derivada nunca se devuelve en respuestas públicas. agent_start usa solo un arrendamiento nuevo transitorio y lo libera después de un inicio exitoso, de modo que los comandos CLI locales de corta duración no bloquean el siguiente comando del operador. Use agent_claim explícitamente cuando una instancia de Codex-CLI conectada deba mantener un Agentin reservado después del inicio. Los selectores de inicio/parada mutantes que resuelven a más de 6 Agentinnen fallan de forma cerrada a menos que se pase allow_broad_selector=true. Esto evita que operaciones accidentales de all/serie inicien o detengan grandes partes del grupo. Las mutaciones de trabajo requieren un auth.json regular por Agentin por defecto: agent_start, agent_claim, agent_send, agent_interrupt, agent_assign, agent_assign_readonly, agent_assign_live_data, agent_assign_write y agent_report_request fallan de forma cerrada cuando la autenticación falta, está enlazada simbólicamente, no es un archivo regular, no es legible o es demasiado grande. El estado/habilidades/capacidades/arrendamiento/grupo/parada/liberación siguen disponibles para diagnóstico y limpieza. Use --allow-unauthenticated solo para flujos explícitos de inicio de sesión/bootstrap. Para la autenticación de ChatGPT, el estado también verifica la expiración del token de acceso JWT cuando está presente. Un token de acceso expirado se informa como access_token_expired y bloquea nuevas mutaciones hasta que ese Agentin inicie sesión nuevamente. Copiar un token de actualización rotatorio de ChatGPT en múltiples Agentinnen no es compatible; cada Agentin necesita su propio inicio de sesión.

agent_status clasifica el texto de panel/registro limitado sin devolverlo, de modo que los llamadores pueden distinguir límites probables diarios, semanales, de token, de cuota o de tasa de los estados ordinarios de "sin respuesta aún". La clasificación mantiene los límites del modelo Agentinnen predeterminado separados de los límites del modelo de escritura de Spark e informa solo metadatos más evidence: not_returned. Los metadatos de límite separan el modelo de sesión en ejecución, el modelo de asignación más reciente y el modelo inferido para el límite detectado. También clasifica un contexto de inicio/placeholder conocido de la TUI de Codex sin devolver el texto del panel, de modo que los llamadores pueden saber cuándo un Agentin no recibió la asignación como entrada productiva. Las respuestas públicas de status, skills, capabilities, app-bridge-status, plugin-status, namespace-status, release-status, watchdog-status, timeout-policy y doctor no devuelven rutas locales del hogar, ejecutor, repositorio, manifiesto o directorio de trabajo de Agentin; devuelven metadatos de estado/categoría como path_state, home_kind y cwd_state en su lugar. Las comprobaciones de alcance públicas, el estado del árbol de trabajo, los extractos de comandos y las lecturas de auditoría de asignación redactan rutas locales absolutas también; las indicaciones de asignación aún reciben las rutas explícitas que la Teamleiterin asignó. agent_wait permite a los llamadores esperar actividad, salida de proceso o un límite clasificado sin recibir automáticamente la salida de Agentin. Su valor predeterminado es 120 segundos y está limitado a 10 minutos por llamada. Su intervalo de sondeo predeterminado es de 30 segundos y está limitado a 900 segundos. Las asignaciones son asíncronas. agent_wait y agent_report_request exponen el assignment_id relevante en el nivel superior. Llame a agent_assignment_report con ese ID para recibir un extracto de terminal pequeño, sin ANSI y redactado. Este es el límite de salida explícito; los metadatos de asignación y los resultados de espera permanecen escasos en datos. fleet_watchdog comprueba Agentinnen inactivos sin leer la salida sin procesar. Su umbral de inactividad predeterminado es de 60 segundos y pide al Agentin un informe conciso antes de cualquier escalada. La ventana de gracia del informe predeterminada es de 15 segundos, de modo que la siguiente pasada del temporizador systemd solo puede escalar después de que el Agentin haya tenido un intervalo para informar. El supervisor systemd instalado usa --action stop, por lo que los Agentinnen no utilizados se vuelven a dormir en lugar de dejarse activos. Por defecto, el watchdog solo muta Agentinnen arrendados por el servidor actual; el supervisor systemd usa --manage-unclaimed --quiet para manejar arrendamientos no reclamados o expirados mientras omite arrendamientos activos mantenidos por otros clientes y evita ruido JSON exitoso en el diario del usuario. Cada ejecución del watchdog de flota crea una instantánea de flota inmutable en memoria para los hogares de procesos gestionados y las sesiones de tmux. La evaluación de Agentin reutiliza esa instantánea; las llamadas independientes de agent_status conservan el respaldo de consulta en vivo heredado. Las rutas de liberación de arrendamiento revalidan la identidad de sesión/proceso en vivo inmediatamente antes de la liberación. Una observación de tmux no disponible se informa como desconocida y omite las acciones del watchdog; nunca se interpreta como una sesión detenida. usage-watchdog consume el estado de instantánea de codex-usage, escribe un marcador de bloqueo local de codex-usage y detiene los Agentinnen en ejecución cuyas cuentas tienen un restablecimiento verificado futuro. Un restablecimiento verificado ya en el pasado limpia el bloqueo; un restablecimiento desconocido permanece en modo de fallo cerrado. Los flujos de agent_start, reclamación, envío y solicitud de informe se niegan a usar un Agentin bloqueado hasta que el watchdog lo libere nuevamente.

Related MCP server: claude-code-mcp

Cuentas de flota, series y trabajos headless de Gemini

El registro de flota es la fuente de verdad para cada serie respaldada por proveedor y para la materialización nativa A/B/C. El proyecto se denomina canónicamente The Hive; los nombres heredados anteriores siguen siendo alias válidos. Use primero las vistas de cuenta/serie de solo lectura, luego sincronice las credenciales localmente a través del flujo CLI solo de stdin:

python3 -m codex_master.server fleet account list
python3 -m codex_master.server fleet series list
python3 -m codex_master.server fleet provider-models --provider ollama_local
python3 -m codex_master.server fleet account sync-env --first-key 1 --last-key 30

Los secretos pueden ingresarse transitoriamente en el centro de control o en el flujo de stdin, pero nunca se muestran, persisten en el estado de la interfaz de usuario, ni se devuelven por la interfaz de usuario o la salida MCP normal. Se almacenan solo en sidecars privados y nunca forman parte del registro, las asignaciones o el historial del shell. Las puertas de cuenta requieren un secreto configurado y una verificación de admisión exitosa. Las sondas de Gemini obsoletas o desconocidas se verifican una vez en el momento de la invocación, de modo que un proyecto vecino no haga que este proyecto esté obsoleto. Las observaciones de RPM/TPM/RPD de Gemini están limitadas al proyecto; el nivel de facturación y los límites de gasto pueden seguir siendo compartidos por la cuenta de facturación. Las exportaciones de AI Studio suministradas confirman el Nivel 1 para the-hive-1 y the-hive-2, y el Nivel 0 para the-hive-3, the-hive-4, the-hive-6 y the-hive-10. Esta es evidencia limitada al proyecto; el grupo de cuentas local no se usa para inferir el nivel de un proyecto. Los límites exactos de RPM/TPM/RPD siguen siendo específicos del modelo y del proyecto; los valores conocidos se importan solo para proyectos con una tabla de límite de tasa en las instantáneas suministradas y los valores desconocidos nunca se adivinan localmente. El guardián de gasto documentado del Nivel 1 es de $10 por 10 minutos móviles y su límite de cuenta de facturación es de $250 por mes. La calculadora de uso local informa RPM/TPM/RPD observados y ahora usa las instantáneas de AI Studio suministradas para pares proyecto/modelo conocidos. Mantiene los límites específicos del modelo y devuelve model_required o limits_unknown_dashboard_required cuando no existe una instantánea aplicable. La utilización de gasto sigue siendo billing_export_required porque una clave de API por sí sola no expone el gasto de facturación.

Instantáneas de límite de tasa importadas:

La fuente de la instantánea es el Tier 0 (kostenlos).mhtml y Tier 1 (Billing).html suministrados; actualícela cuando AI Studio cambie los límites del proyecto activo.

fleet_gemini_bootstrap_plan sigue siendo solo un ayudante de plan seco de compatibilidad sin secretos. No crea las series D/E/F retiradas; la activación en tiempo de ejecución proviene de entradas The_Hive_N pobladas en el archivo de token privado. Las claves 1–10 pertenecen a una cuenta de facturación con un proyecto por clave; las claves 11–20 y 21–30 están reservadas para las siguientes dos cuentas y se activan solo cuando existen sus valores. El instalador opcional usa solo el canal de paquetes estable oficial:

NPM_CONFIG_PREFIX="$HOME/.local" ./scripts/install-gemini-cli
"$HOME/.local/bin/gemini" --version

El instalador rechaza un prefijo NPM del sistema no escribible en lugar de escalar privilegios; establezca un NPM_CONFIG_PREFIX explícito propiedad del usuario como se indicó anteriormente.

Los trabajos de Gemini usan un HOME/GEMINI_CLI_HOME privado del agente, entrada de tarea solo por stdin, salida estándar/error stream-json acotada, cancelación por grupo de procesos y aprobación específica por rol (plan para Exploriererinnen, auto_edit para Arbeitsbienen). La CLI se pone explícitamente en modo headless con un --prompt vacío; la tarea real permanece solo por stdin. No usan yolo, -p - ni marcadores de Codex TUI. La respuesta de la asignación está acotada y analizada. Los prompts, credenciales, eventos de herramientas y salida cruda permanecen fuera de los metadatos persistentes; la salida del proceso permanece acotada.

Las asignaciones headless productivas aceptan hasta 7200 segundos (120 minutos) por llamada; el valor predeterminado sigue siendo 600 segundos.

Para las series de Gemini cuyo modelo de registro es auto, Masterjet fija la CLI headless a gemini-3.1-flash-lite, el valor predeterminado de bajo costo/alto RPM para auditorías estructuradas de Bauplan. Un modelo más pesado se usa solo cuando está explícitamente configurado para esa serie.

Cada sonda de API de Gemini o trabajo headless también toma una reserva de solicitud persistente por proyecto. Las reservas permiten solo una solicitud activa, imponen un espaciado mínimo de 60 segundos entre procesos y reinicios, y aplican un enfriamiento exponencial después de un 429 verificado (comenzando en 15 minutos, con un máximo de 24 horas). El estado privado se almacena en fleet/rate-limits.json; el estado malformado falla cerrado y se pone en cuarentena en lugar de permitir otra solicitud.

El modelo de vista fleet_control sin GTK y el controlador control_center aplican los mismos límites y comprobaciones de generación que el servidor; la página opcional de GTK3 se carga de forma diferida para que las importaciones headless permanezcan sin pantalla. El adaptador de Cinnamon usa el esquema de instantánea v3, con un máximo de 26 series y 25 filas visibles por página de serie; las filas limitadas son solo de estado. Las credenciales reales del proveedor, las sondas de cuenta, la admisión de recursos de Ollama y la aceptación de la sesión de escritorio siguen siendo puertas locales explícitas. Las series de Ollama permanecen simple_only y rechazan tareas complejas o que cambian el repositorio. Su límite de recursos separado de dos agentes y las puertas de presión del host configurados se aplican; el límite global de diez Bees sigue siendo un límite superior adicional.

Tools

• agent_start: iniciar Agentinnen seleccionadas; los selectores all/serie requieren allow_broad_selector=true cuando resuelven a más de 6 Agentinnen

• agent_status: estado estructurado, estado de respuesta y clasificación de límites sin salida cruda

• agent_lease_status: estado de arrendamiento con datos dispersos para Agentinnen seleccionadas

• Los selectores amplios de solo lectura en agent_status, agent_lease_status, agent_skills, agent_skill_match y agent_capabilities se paginan con agents_limit/agents_offset; el tamaño de página predeterminado es de 30 Agentinnen y las respuestas incluyen total_count más metadatos truncated.

• agent_claim: reclamar o renovar una Agentin, reintentando para siempre por defecto cuando está ocupada; las reclamaciones explícitas pueden recuperar arrendamientos huérfanos detenidos después de la gracia

• agent_release: liberar la reclamación de Agentin de este cliente MCP; forzar solo después de verificar el estado

• agent_wait: esperar metadatos de actividad/detención/límite sin salida cruda, con un valor predeterminado de 120 segundos y un máximo de 10 minutos por llamada

• fleet_watchdog: solicitar un informe de Agentinnen inactivas, esperar una ventana de gracia y luego opcionalmente interrumpir, detener o liberar sin salida cruda

• usage_watchdog: sincronizar los bloques de límite de uso de codex con el estado local de Agentin, deteniendo a las Agentinnen en ejecución bloqueadas y limpiando el marcador de bloqueo local una vez que el watchdog de uso de codex las libera

• agent_send: enviar texto a una Agentin en ejecución

• agent_interrupt: enviar Ctrl-C a una Agentin en ejecución

• agent_stop: detener Agentinnen seleccionadas; los selectores all/serie requieren allow_broad_selector=true cuando resuelven a más de 6 Agentinnen

• agent_safe_tail: extracto explícito acotado, sin ANSI y redactado; rechaza arrendamientos activos mantenidos por otros clientes antes de leer el panel o la salida de registro; la fuente de registro solo lee archivos de registro crudo regulares

• agent_skills: inventario de habilidades con datos dispersos sin contenido de archivos

• agent_skill_match: comprobar si una o todas las Agentinnen tienen una habilidad nombrada

• agent_capabilities: capacidades resumidas de modelo, habilidad y política con una página de plugin acotada

• agent_scope_check: verificar que las rutas de escritura permanezcan dentro del alcance de la asignación

• agent_assign: asignación estructurada y consciente de habilidades con límites explícitos

• agent_assign_readonly: atajo para asignaciones de solo lectura de Exploriererin

• agent_assign_live_data: atajo para asignaciones de solo lectura de Web-/Live-Daten que requieren fuentes actuales o un informe explícito de herramientas/límites de acceso

• agent_assign_write: atajo para asignaciones de escritura de Arbeitsbiene

• agent_assignments: registro de auditoría de asignaciones con datos dispersos

• agent_last_assignment_status: últimos metadatos de asignación para una Agentin

• agent_report_request: pedir a una Agentin un informe conciso

• agent_assignment_report: leer un extracto acotado y redactado para una asignación conocida

• agent_selector_policy: mostrar o establecer la política de selector ordinal, por ejemplo a,b o a,b,c

• agent_selector_preview: previsualizar el mapeo de selector numérico sin mutar el estado

• agent_selection_preview: previsualizar candidatos reales de la flota a través del Kern de Selección/Admisión de solo lectura; Shadow planifica pero nunca ejecuta. Enforced permanece cerrado hasta que se proporcionen callbacks autoritativos de Hive y un ejecutor específico de operación; ServerAdmissionRuntime proporciona el límite de fallo cerrado pero no ejecuta operaciones

El módulo local codex_master.admission ahora proporciona ese límite de reserva como un contrato en proceso de fallo cerrado: los registros inmutables vinculan la versión de trabajo, los resúmenes de concesión/alcance, la expectativa de arrendamiento y el recurso seleccionado; los cambios de estado usan un CAS de revisión, los TTL de reserva están limitados a 30–120 segundos, y public() elimina claves de cuenta, rutas de alcance y otros enlaces privados. La superposición de alcance, las capacidades de agente/cuenta/modelo de cuenta y la superposición de lectura/lectura versus escritura se verifican atómicamente. FileAdmissionStore agrega un bloqueo privado más reemplazo atómico de estado para la recuperación de procesos nuevos; el estado malformado, sobredimensionado o con enlaces simbólicos falla cerrado. No realiza ninguna mutación de proveedor, ciclo de vida, arrendamiento o red y aún no está conectado a la ejecución de Enforced.

codex_master.selection_service.SelectionService es la siguiente capa de orquestación local. Delega la vista previa al mismo planificador determinista, revalida antes de una llamada de runtime inyectada, reintenta como máximo tres veces con retroceso de 50/100/200 ms, compensa los intentos fallidos y reconcilia la evidencia de fallos sin volver a ejecutar. codex_master.admission_runtime.ServerAdmissionRuntime ahora proporciona el límite de servidor de fallo cerrado: los callbacks de autoridad, repositorio y alcance canónico deben provenir de registros autoritativos de Hive; las comprobaciones existentes de cuenta de Fleet, modelo, Uso, arrendamiento, identidad de proceso, autenticación y configuración de runner se adjuntan en un orden fijo. Los enlaces de Hive faltantes, admisiones obsoletas, evidencia de puerta malformada o errores de callback deniegan el runtime, y la revalidación exitosa es de un solo uso por revisión de admisión. El adaptador en sí nunca reclama, inicia, asigna o llama a un proveedor. Su almacén privado entre procesos tiene su raíz en el par admission-state.json/bloqueo local del estado cuando una ruta de ejecución automática solicita explícitamente current_admission_store(); la ejecución productiva de Enforced permanece cerrada hasta que se proporcionen los callbacks autoritativos de Hive y un ejecutor específico de operación.

El estado del applet expone banderas acotadas fleet_snapshot_degraded y watchdog_snapshot_degraded cuando sus fuentes de solo lectura no están disponibles. Una ventana de Usage-v2 agotada cuyo restablecimiento verificado ya pasó ya no bloquea la cuenta; los restablecimientos futuros o desconocidos permanecen con fallo cerrado.

Plano de control de Hive

El paquete codex_master.hive ahora contiene los cimientos acotados del plano de control: configuración pública estricta, estado privado, principales y enlaces de ejecución, comprobaciones de repositorio/autoridad, mensajes tipados y máquinas de estado de despacho, decisiones de solo anexión, memoria consciente de procedencia, una cola de trabajo DP y un único límite de admisión. El paquete codex_master.selection es un límite de compatibilidad alrededor del planificador determinista existente y agrega contratos tipados de política de modelo, clasificación de tareas, fuente, estado de equidad y ancla pasiva sin introducir un segundo selector.

El estado de Hive, la validación, la migración y los diagnósticos de Selection se exponen como herramientas MCP de solo lectura. La evidencia faltante autoritativa de Work-/Grant-/Repository-/Scope- y Lease permanece con fallo cerrado; ninguna herramienta de diagnóstico de Hive reclama, inicia, asigna o invoca un proveedor.

Los detalles operativos están documentados en docs/account-aware-selection.md, docs/operations/hive-operations.md, docs/operations/selection-operations.md, docs/security/hive-security.md, docs/security/selection-privacy.md y docs/migration/hive-selection-migration.md. Los ejemplos de configuración públicos y sin secretos viven en examples/: clases de agente, modo Hive y política de modelo.

• worktree_create_for_agent: crear un worktree de git aislado para una Agentin

• worktree_status: estado de git acotado y metadatos de worktree

• integration_status: estado del repositorio, estadísticas de diff y metadatos de asignación recientes

• commit_ready_check: comprobaciones de preparación fijas para integración/commit

• master_app_bridge_status: estado del manifiesto de App Bridge y del ID de conector

• master_plugin_status: empaquetado de plugins, deriva de caché de plugins, App Bridge y estado de registro de MCP

• master_namespace_status: diagnosticar el registro de codex-master-mcp, el inicio, la deriva de caché de plugins y la visibilidad de tools/list para nuevos clientes

• master_release_status: diagnosticar la deriva de versiones entre la versión del paquete, la versión del manifiesto del plugin, las etiquetas locales y los lanzamientos de GitHub

• master_watchdog_status: diagnosticar la salud de Fleetwatchdog de systemd, el endurecimiento de unidades instaladas y el estado agregado de puntuación de seguridad

• master_timeout_policy: informar sobre el tiempo de espera efectivo y la política de sondeo para el inicio de MCP, el reintento de reclamación de Agentin, la espera de Agentin, las asignaciones headless productivas, la supervisión del watchdog y la fuente de identidad de arrendamiento oculta de la CLI

• master_applet_status: instantánea de solo lectura acotada para 1–6 Agentinnen concretas; utilizada por el applet de Cinnamon y disponible como applet-status en la CLI

• agent_pool_validate: validar una especificación de pool de Agentinnen legible por máquina

• agent_pool_install: instalar o actualizar los homes de Agentinnen inactivas desde una especificación

• agent_pool_status: inspeccionar los recuentos de instalación de pool con datos dispersos

• agent_pool_copy_auth: copiar explícitamente un auth.json de origen a muchas Agentinnen instaladas, con ejecución en seco por defecto

• agent_pool_destroy_pool: eliminación protegida de los homes de Agentinnen instaladas

• agent_doctor: diagnósticos estructurados sin salida cruda

• agent_selection_options: oferta de primera ronda filtrada por cuenta y autoridad que contiene solo combinaciones válidas de clase/ciclo de vida/modelo/razonamiento

• fleet_account_list, fleet_gemini_bootstrap_plan, fleet_series_list, fleet_account_upsert, fleet_account_set_secret, fleet_account_disable, fleet_account_probe, fleet_account_delete, fleet_provider_models, fleet_series_plan, fleet_series_apply, fleet_series_disable y fleet_series_delete: gestión acotada de cuentas/proveedores/series de Fleet; la entrada de secretos es solo por stdin y las mutaciones usan CAS de generación

/mcp debería mostrar codex-master-mcp únicamente en la instancia de Teamleiterin/Codex principal. Las Agentinnen gestionadas no reciben intencionadamente las herramientas MCP de Masterjet; se controlan desde fuera y solo pueden usar Subagentinnen nativas cuando una asignación lo permite explícitamente. tool_search no es autoritativo para el espacio de nombres MCP stdio local; usa /mcp en el cliente Codex afectado o namespace-status desde este repositorio. plugin-status y namespace-status también informan si la versión del manifiesto del plugin del repositorio está instalada en la caché de plugins local, sin devolver rutas de caché. Para namespace-status, ok de nivel superior significa que el servidor MCP, la caché de plugins local, la configuración activa del cliente Codex y el contexto activo de CODEX_HOME están listos. mcp_server_ready, plugin_cache_ready, client_config_ready y active_home_ready permanecen separados para aislar el arranque del servidor de un estado obsoleto de cliente/plugin, una configuración no coincidente o un home de Agentin gestionado. running_process_summary.namespace_visibility informa solo categorías agregadas de homes de cliente para que las sesiones Codex hermanas puedan identificar cuándo los homes personalizados necesitan su propia configuración MCP o cuándo se espera que los homes de Agentinnen gestionadas no expongan las herramientas MCP de Master.

CLI local

Resolvedor central de clases/ciclo de vida/modelo

Antes del primer inicio o asignación de una serie, el modelo solicitante consulta agent_selection_options para una Agentin objetivo concreta. La respuesta contiene solo clases, ciclos de vida, modelos, niveles de razonamiento y sus combinaciones válidas actualmente permitidas. La oferta es consultiva y no reserva nada. Su generation puede proporcionarse como known_generation en llamadas posteriores; options_changed informa cambios debidos a la cuenta o al catálogo. En la primera oferta para una Teamleiterin debe aparecer visiblemente exactamente un tuple legal: class=teamleiterin, lifecycle=persistent, model=gpt-5.6-terra, reasoning=xhigh. Para la política, xhigh es a la vez mínimo y máximo. No se pueden ofrecer otros tuples de Teamleiterin.

agent_start, agent_assign y los atajos de asignación pasan sus campos opcionales class, lifecycle, model, reasoning_effort y complexity al mismo resolvedor. Después no se aplica ninguna segunda política de selección. Los ciclos de vida públicos son ephemeral, binding y persistent; invocation sigue permitido como alias de entrada y se devuelve como ephemeral.

Las indicaciones explícitas compatibles se conservan. El perfil de clase, el ciclo de vida, las capacidades del modelo, la disponibilidad relacionada con la cuenta y el mínimo y máximo de razonamiento son límites estrictos. Si falta la clase, se elige una clase no directiva delegable adecuada; las clases directivas nunca se promocionan automáticamente. Si falta el ciclo de vida, se aplica el perfil de clase. Valores predeterminados para Arbeiterinnen:

• trabajo de escritura simple más ephemeral: gpt-5.3-codex-spark/low

• solo lectura o trabajo de escritura no simple más ephemeral: gpt-5.6-luna/medium

• binding: gpt-5.6-luna/high

• persistent: gpt-5.6-luna/xhigh; xhigh es aquí a la vez el mínimo

Si Spark no está disponible para la cuenta o la comprobación de tareas lo descarta, el valor predeterminado vuelve a Luna. Spark es solo el valor predeterminado para un trabajo de escritura simple sin solicitud de modelo. Un modelo desconocido o no disponible solicitado explícitamente para una Arbeiterin vuelve de forma segura a gpt-5.6-luna, nunca a Spark; un esfuerzo explícito compatible se conserva o se ajusta al modelo de reemplazo y a los límites de clase/ciclo de vida. Las indicaciones ajenas a la clase o demasiado débiles también se reemplazan dentro de los límites estrictos; Gottbiene y Koenigin permanecen vinculadas a Sol. selection.fallback, el valor solicitado y efectivo, así como reason_codes estables, proporcionan el mensaje claro de error/retroceso. El modelo solicitante puede entonces abortar o volver a solicitar con otra combinación ofrecida. Las promociones válidas Spark -> Luna -> Terra -> Sol siguen siendo posibles dentro de los límites de clase y esfuerzo. ultra nunca está permitido.

Teamleiterin es fijamente persistente y usa exactamente gpt-5.6-terra con xhigh; xhigh es para ella a la vez mínimo y máximo. Un modelo o esfuerzo requerido que no esté disponible es un error estricto sin retroceso. required_model_unavailable:gpt-5.6-terra o required_model_effort_unavailable:gpt-5.6-terra:xhigh. Esto se aplica especialmente a la Teamleiterin: el inicio y la asignación comparten el resolvedor central y nunca pueden recurrir a Sol, Luna, Spark u otro esfuerzo.

Las clases directivas son fijamente persistentes y se presentan con su nombre en el primer contacto real con el usuario: Gottbiene usa gpt-5.6-sol/max, Koenigin usa gpt-5.6-sol/xhigh, y Teamleiterin usa exactamente gpt-5.6-terra/xhigh. Para Koenigin, Teamleiterin y todas las clases de Arbeiterin, xhigh es el límite superior absoluto; solo Gottbiene puede usar max.

El flujo operativo canónico está en Selection Operations. Los catálogos versionados codex-agent-classes.json y codex-model-policy.json siguen siendo autoritativos; el README y la skill no definen una segunda política de selección.

Ofertas de spawn conscientes de recursos

agent_spawn_offers es un aviso MCP de solo lectura para una posible capacidad local. Ejemplo de un tools/call de MCP:

{"name":"agent_spawn_offers","arguments":{"required_slots":1}}

Mismo comando CLI desde este worktree:

PYTHONPATH=src python -m codex_master.server spawn-offers --required-slots 1
./bin/codex-master-mcp spawn-offers --required-slots 1

PYTHONPATH=src es necesario para las llamadas de Python de este worktree: una instalación editable local puede apuntar a otro estado del código fuente.

Una oferta es consultiva, tiene una validez de 5 segundos y no reserva nada (reservation: "none"). start vuelve a comprobar los slots totales libres antes de un nuevo inicio de tmux bajo el lock de admisión. Sin un número total fiable, las ofertas permanecen vacías; la respuesta con datos escasos contiene solo códigos de motivo, sin contenido de /proc, salida de tmux, rutas locales ni textos de entorno. Se puede reintentar con un aviso de espera de 15 segundos.

Límites temporales para un nuevo inicio:

• Los límites de presión de recursos permanecen configurados y activos con sus valores anteriores: CPU, carga, I/O-wait y RAM pueden bloquear el spawn con fail-closed.

• El límite de dos de Ollama configurado se mantiene y se aplica antes del límite global de diez.

• como máximo 10 Bienen en total; las sesiones Masterjet en ejecución, así como las Subagentinnen nativas activas y no confirmadas, cuentan juntas.

• a partir de 10 Bienen, cualquier Biene adicional es rechazada estrictamente.

• required_slots está entre 1 y 10.

Las respuestas de admisión denegadas contienen, además de reason_codes estables, una tabla estructurada errors. Cada entrada proporciona code, title, explanation, rule y action; no se incluyen métricas brutas ni datos de estado local.

CODEX_MASTER_SPAWN_PRIORITY es la única configuración de entorno de spawn. Es una lista de prioridades separada por comas (por defecto mcp_host), solo se lee como datos, se deduplica y nunca se ejecuta como comando de shell ni destino de red. Su texto no se refleja en las respuestas. Actualmente solo el valor de ruta local exacto mcp_host puede generar una oferta. developer_vm y sandbox no se ofrecen, incluso si aparecen en esta lista; no hay ejecución remota en esta versión.

Una oferta no genera lease, ni archivo meta, ni entrada de auditoría de asignación. Los gates de autenticación, alcance, enrutamiento, modelo, uso y admisión existentes siguen siendo efectivos en el inicio real o en las asignaciones. Un estado limpio de tmux sin servidores ni sesiones cuenta como cero Agentinnen en ejecución. Los errores de medición, los errores de /proc y todos los demás errores de tmux fallan con fail-closed; sus errores públicos permanecen limitados y redactados.

Las Subagentinnen nativas informan de inicios y paradas al Masterjet. Las entradas activas y no confirmadas cuentan por tanto en cada decisión de slot posterior. La política de prompts de asignación exige la comprobación total fresca antes de cada spawn adicional. Un modelo que evite esta ruta MCP no puede ser interceptado técnicamente por el Masterjet sin un hook de pre-spawn propio de Codex. developer_vm solo puede volverse ofertable cuando se cumplen todos los siguientes requisitos:

• sonda real de reachability/health contra la VM real

• transporte autenticado y verificación/fijación de host-key

• leases/reservas distribuidas entre hosts

• ejecución remota acotada (timeouts y salida acotada)

• pruebas de integración de extremo a extremo contra el destino real

Hasta entonces, un backend de VM queda completamente omitido.

cd /home/teladi/codex-master
python3 -m codex_master.server install          # create ~/.local/bin/codex-master-mcp + codex mcp add
python3 -m codex_master.server doctor          # smoke check (codex, tmux, state path, JSON result)
python3 -m codex_master.server uninstall       # remove mcp registration and local symlink
python3 scripts/codex-master-cinnamon-applet install --dry-run
python3 scripts/codex-master-cinnamon-applet install --no-reload
python3 scripts/codex-master-cinnamon-applet verify

python3 -m codex_master.server start both --cwd /home/teladi/codex-master
python3 -m codex_master.server status
python3 -m codex_master.server selector-policy
python3 -m codex_master.server selector-policy --series a,b,c
python3 -m codex_master.server selector-preview --limit 6
python3 -m codex_master.server selection-preview --series d --task-kind simple --admission-mode shadow --sp1a --limit 8
python3 -m codex_master.server lease-status all --agents-limit 30
python3 -m codex_master.server claim b --forever --poll-interval-seconds 30
python3 -m codex_master.server claim b --no-wait
python3 -m codex_master.server claim b --no-recover-stopped
python3 -m codex_master.server wait a --timeout-seconds 120 --poll-interval-seconds 30
python3 -m codex_master.server watchdog active --idle-seconds 60 --poll-interval-seconds 15 --report-grace-seconds 15 --action stop --manage-unclaimed --quiet
python3 -m codex_master.server capabilities all --agents-limit 30
python3 -m codex_master.server skills all --agents-limit 30
python3 -m codex_master.server skills a --include-names --limit 20 --names-offset 20 --plugins-offset 20 --plugins-limit 20
python3 -m codex_master.server skill-match all codex-security:security-scan --agents-limit 30
python3 -m codex_master.server scope-check --scope src/codex_master --write-path src/codex_master/server.py
python3 -m codex_master.server assign-readonly a --skill codex-security:security-scan --scope src/codex_master/server.py --task "Pruefe nur lesend und berichte knapp."
python3 -m codex_master.server assign-live-data a --task "Wie ist das Wetter gerade in Berlin?" --live-data-topic "Wetter Berlin heute"
python3 -m codex_master.server assign-write b --scope .github/workflows --write-path .github/workflows/ci.yml --task "Haerte nur die CI-Datei."
python3 -m codex_master.server assignments all --limit 20
python3 -m codex_master.server last-assignment a
python3 -m codex_master.server assignment-report a ASSIGNMENT_ID --source pane --lines 40 --chars 4000
python3 -m codex_master.server integration-status
python3 -m codex_master.server commit-ready-check
python3 -m codex_master.server app-bridge-status
python3 -m codex_master.server plugin-status
python3 -m codex_master.server namespace-status
python3 -m codex_master.server release-status
python3 -m codex_master.server watchdog-status
python3 -m codex_master.server timeout-policy
python3 -m codex_master.server fleet-recovery-status
python3 -m codex_master.server fleet-recovery-retry
python3 -m codex_master.server pool validate --spec codex-agent-pool.json
python3 -m codex_master.server pool install --spec codex-agent-pool.json --target-dir "$HOME/.codex-agents" --codex-bin /usr/local/bin/codex
python3 -m codex_master.server pool status --spec codex-agent-pool.json
python3 -m codex_master.server pool copy_auth --spec codex-agent-pool.json --from-agent a1 --to a-series
python3 -m codex_master.server pool destroy_pool --spec codex-agent-pool.json --yes
python3 -m codex_master.server send a "Kurzer Auftrag"
python3 -m codex_master.server release b
python3 -m codex_master.server tail a --source pane --lines 20 --chars 2000
python3 -m codex_master.server stop both

Especificación del pool de Agentinnen

El repositorio contiene un codex-agent-pool.json genérico y legible por máquina, además de schemas/codex-agent-pool.schema.json. El pool nativo instalado actual usa cinco homes A, tres homes B y tres homes C. a1 y b1 siguen siendo los homes de origen autenticados; b92 es un home activo conservado por separado y se muestra en el inventario de flota fusionado. Las series Gemini se gestionan a través del registro Fleet y no forman parte de esta especificación de pool nativo. Las lecturas de la especificación del pool aceptan solo archivos JSON UTF-8 regulares, rechazan archivos de especificación con symlink o sobredimensionados y mantienen las rutas de especificación fuera de las respuestas de error públicas. La validación del pool devuelve solo recuentos y marcadores de estado para series, alias y Agentinnen autenticadas; los nombres concretos no se repiten. La instalación del pool también mantiene los wrappers codex generados y los archivos config.toml como archivos regulares por Agentin, reemplazando las entradas con symlink sin tocar sus destinos, valida los directorios de ejecución como directorios reales y escribe un marcador regular de pool instalado. El estado del pool informa ok solo cuando el marcador, todos los homes esperados, wrappers, configuraciones y los enlaces de activos compartidos requeridos están presentes y son válidos. Los diagnósticos de activos compartidos son solo recuentos; los destinos de enlaces locales y las rutas del pool no se devuelven. El estado del pool también devuelve recuentos de series sin repetir nombres de series concretos.

La especificación es solo el mapa. El material de autenticación real sigue siendo el auth.json por home, por ejemplo ~/.codex-agents/a1/auth.json. La instalación normal nunca copia material de autenticación.

Se admiten dos rutas de instalación:

./bin/codex-master-mcp pool install --spec codex-agent-pool.json --target-dir "$HOME/.codex-agents"
./scripts/install-agent-pool --spec codex-agent-pool.json --target-dir "$HOME/.codex-agents"

Usa --codex-bin cuando el binario de Codex CLI no sea /usr/local/bin/codex. La instalación normal nunca copia material de autenticación. Para la propagación masiva de autenticación, ejecuta pool copy_auth primero sin --yes para inspeccionar los recuentos, y luego repite con --yes cuando sea intencional. copy_auth copia solo auth.json, omite a la Agentin de origen si forma parte del selector de destino, requiere que el home de la Agentin de origen sea un directorio real y nunca devuelve contenido de autenticación, el id de la Agentin de origen ni el selector de destino solicitado.

No utilices enlaces simbólicos ni enlaces duros para auth.json en el modelo de pool normal. Los archivos de autenticación son pequeños; las copias mantienen a cada Agentin aislado. Los enlaces simbólicos cruzan el límite de confianza de no-seguir, y los enlaces duros comparten un mismo inodo entre múltiples Agentinnen.

Consulta docs/agent-pool.md para el conjunto completo de comandos y docs/auth-copy.md para el modelo de seguridad de auth-copy.

El instalador de Cinnamon copia el applet al directorio Xlet por usuario con un intercambio atómico, un árbol de reversión validado, un bloqueo de operación privado y verificación acotada de origen/destino. install --dry-run no realiza ninguna mutación del sistema de archivos ni de D-Bus; --no-reload es útil para pruebas de humo en CI y en hogares temporales. verify además comprueba el Xlet de Cinnamon en ejecución cuando hay una sesión de escritorio disponible.

Applet de Cinnamon: Flottenmanagement

codex-master@H234598 es el applet de estado de solo lectura P3/P3a. Su título visible en el panel es siempre Flottenmanagement. Solicita explícitamente el esquema de estado de applet v4; los esquemas v1 a v3 permanecen sin cambios para los llamadores más antiguos.

Cada actualización de esquema v4 utiliza un inventario acotado de sesiones de tmux. Cada Agentin de codex-master en ejecución conocido se descubre automáticamente y se muestra, hasta el límite fijo de seis filas. Las sesiones de tmux externas se ignoran. tracked-agents ya no define la flota visible: solo fija a los Agentinnen dormidos en filas que dejan libres los Agentinnen activos. Por lo tanto, su valor predeterminado a1,b1 no limita el descubrimiento automático. Más de seis Agentinnen gestionados activos producen un marcador de desbordamiento acotado en lugar de un menú sin límite.

Los Subagentinnen nativos de Codex no se mezclan con los Agentinnen de tmux gestionados. Los hooks oficiales SessionStart, SubagentStart, SubagentStop y SessionEnd mantienen un registro privado y acotado. El applet muestra ese registro solo en el submenú separado Native Bienen (N), usando seis filas secundarias fijas y no reactivas. Las filas nativas son solo de estado y no contienen ninguna acción ni token de contexto.

El applet inicia como máximo un proceso hijo acotado codex-master-mcp applet-status y nunca lee la instantánea de recursos ni inicia un monitor de recursos. El esquema v4 agrega solo el estado de puerta de recursos acotado, el cuello de botella, la tendencia, la confianza, las sugerencias de perfil y la generación de instantáneas. Las generaciones de recursos inválidas o en regresión se muestran como no disponibles. El applet nunca invoca un shell.

El modelo de estado mantiene tres preocupaciones separadas:

• activity_state: running, sleeping, mixed o unknown;

• backend_state: ok, degraded o unavailable;

• control_state: ready, blocked, mixed o unknown.

Un Agentin dormido es normal y por sí mismo no degrada la salud del backend. Las actualizaciones fallidas conservan la última instantánea válida y la marcan como obsoleta. Las respuestas contienen solo campos de estado fijos y conteos; no se devuelven indicaciones, registros, IDs de proceso, rutas, propietarios de arrendamiento, IDs de arrendamiento ni salida sin procesar.

resource-status --format compact|json|markdown es una CLI de operador local, no una herramienta MCP. Representa solo la proyección validada ResourceOperatorStatus; las etiquetas de sensores, los IDs de ámbito de cgroup, las rutas, los PIDs, el historial sin procesar, stdout, stderr, las credenciales y la evidencia absoluta de memoria disponible nunca se devuelven.

Los cuatro ajustes del applet son:

• tracked-agents: separados por comas a1 a c100; de 1 a 6 IDs concretos para fijar como filas dormidas cuando el descubrimiento activo automático deja capacidad, normalizados en mayúsculas/minúsculas y deduplicados; valor predeterminado a1,b1;

• refresh-on-open: actualizar al abrir el menú; activado por defecto;

• background-refresh: actualización periódica opcional; desactivada por defecto;

• refresh-interval-seconds: de 15 a 3600 segundos; valor predeterminado 60.

Los valores malformados de agente, conmutador o intervalo muestran un error de configuración, recurren a valores predeterminados seguros, desactivan el trabajo en segundo plano y nunca llegan al argv del proceso. Los intervalos de actualización finitos fuera del rango permitido se limitan a 15–3600 segundos. El menú contiene una actualización manual, administración del applet, un resumen, como máximo seis filas gestionadas y el submenú Native-Bienen separado y acotado.

Solo la Koenigin puede reiniciar o recargar Masterjet, instalarlo o sincronizar la caché de plugins. Otros roles pueden inspeccionar y verificar el estado y recomendar estas acciones a la Koenigin, pero no deben ejecutarlas.

Instala el MCP/plugin y el applet con los instaladores propiedad del repositorio:

./bin/codex-master-mcp install
./scripts/codex-master-cinnamon-applet install --dry-run
./scripts/codex-master-cinnamon-applet install
./scripts/codex-master-cinnamon-applet verify

La referencia completa de la CLI es la página de manual del repositorio codex-master-mcp(1). Genera una salida comprimida determinista sin instalarla, o renderiza la fuente directamente:

./scripts/codex-master-manpage build --output-dir /tmp/codex-master-man
groff -man -Tutf8 man/man1/codex-master-mcp.1

codex-master-mcp install sincroniza el plugin, incluidos los archivos regulares hooks/hooks.json, hooks/native_spawn_admission.py y hooks/native_bee_event.py, en la caché personal de plugins. No altera ni debe alterar el estado de confianza de los hooks de Codex. En la sesión actual de Codex padre, abre /hooks, inspecciona las cinco definiciones de codex-master y confíalas explícitamente: un hook de admisión PreToolUse bloqueante más cuatro hooks de ciclo de vida. Luego inicia una sesión completamente nueva de Codex padre en el repositorio. La reconexión de MCP, el estado o el inicio de agentes no reemplazan esa nueva sesión. Hasta que ese paso manual tenga éxito, no afirmes que la admisión de spawn nativo o la cobertura del ciclo de vida de Native-Bienen está activa.

Revierte el árbol del applet activo con:

./scripts/codex-master-cinnamon-applet rollback

install organiza y hashea los archivos fuente regulares sin enlaces duros, rechaza rutas de origen/destino con enlaces simbólicos, recarga solo este UUID a través de ReloadXlet de Cinnamon, y restaura y recarga el árbol anterior si la implementación falla. verify requiere archivos instalados byte-idénticos y un UUID en ejecución de GetRunningXletUUIDs applet. rollback requiere árboles instalados y de reversión validados, pero no una fuente de repositorio intacta. Falla de forma cerrada cuando falta un árbol requerido o es inesperado. Install, verify y rollback se serializan mediante un bloqueo privado por UUID. --no-reload está disponible para pruebas controladas de instalación/reversión sin conexión. Ningún comando usa Eval ni reinicia Cinnamon globalmente.

Diagnósticos útiles:

./bin/codex-master-mcp resource-status --format compact
./bin/codex-master-mcp resource-status --format json
./bin/codex-master-mcp resource-status --format markdown
./bin/codex-master-mcp applet-status --schema-version 4
gdbus call --session --dest org.Cinnamon --object-path /org/Cinnamon \
  --method org.Cinnamon.GetRunningXletUUIDs applet
journalctl --user -b | grep -F codex-master@H234598

Un estado de applet unavailable u obsoleto significa que la actualización de solo lectura acotada falló. Verifica primero los archivos instalados y la CLI; no interpretes la actividad ordinaria de sleeping como una falla del backend.

Contrato de instalación (CLI)

install

• crea ~/.local/bin/codex-master-mcp como enlace simbólico a bin/codex-master-mcp

• verifica que el wrapper del repositorio pueda responder a una sonda de initialize de MCP antes de registrarlo con Codex

• verifica que la ruta del comando instalado también responda a la misma sonda antes del registro

• registra el comando mediante codex mcp add codex-master-mcp -- <link>

• asegura que la configuración activa de MCP de Codex tenga startup_timeout_sec = 120

• sincroniza la caché personal de plugins de codex-master desde una lista de permitidos en tiempo de ejecución (.codex-plugin, .app.json, .mcp.json, bin, docs, examples, schemas, scripts, skills, src, systemd, README, codex-agent-pool.json y metadatos de paquete) mientras excluye .git, pruebas, bytecode, cachés de pruebas, archivos ocultos, archivos de intercambio del editor y restos de copias de seguridad/parches

• rechaza archivos fuente de plugins con enlaces duros y conserva solo la versión actual más la más reciente válida en caché, sin podar entradas de caché inválidas o con enlaces simbólicos

• copia los archivos fuente regulares de la caché de plugins a través de descriptores de archivo sin seguimiento y verifica la identidad del origen después de abrirlo, de modo que un intercambio de origen no pueda redirigir el contenido de la caché

• crea directorios temporales de caché de plugins con sufijo nonce y nunca elimina un directorio temporal preexistente que esta sincronización no haya creado

• se niega a registrar el MCP maestro desde un CODEX_HOME de Agentinnen gestionados

• requiere que la cadena de directorios padre de la ruta de instalación sean directorios reales, no enlaces simbólicos

• crea o reemplaza el enlace simbólico de instalación mediante un enlace simbólico temporal atómico en el mismo directorio y un rename vinculado al descriptor de directorio

• trata los enlaces simbólicos de instalación rotos, en bucle o ilegibles como no coincidentes en lugar de fallar al resolverlos

• devuelve JSON sin salida de agente, ruta de instalación, ruta objetivo del wrapper del repositorio ni rutas de caché de plugins

• acepta --no-plugin-cache solo para instalaciones de diagnóstico explícitas que deben dejar intacta la caché personal de plugins

uninstall

• anula el registro de codex mcp remove codex-master-mcp

• elimina ~/.local/bin/codex-master-mcp

• requiere que la cadena de directorios padre de la ruta de instalación sean directorios reales al eliminar

• elimina el enlace simbólico de instalación a través del descriptor de directorio padre verificado, de modo que un intercambio del padre después de la validación no pueda redirigir el unlink

• deja los enlaces simbólicos de instalación rotos, en bucle o ilegibles en su lugar a menos que resuelvan al wrapper del repositorio

• devuelve JSON y ningún material secreto sin procesar

doctor

• comprueba la disponibilidad de las herramientas requeridas (codex, tmux) y del directorio de estado de MCP

• informa un objeto checks estructurado

• verifica el comando MCP instalado con una sonda initialize de datos escasos

• informa si el registro MCP activo de Codex tiene startup_timeout_sec >= 120

• informa si el CODEX_HOME activo parece el hogar principal predeterminado, un hogar de Agentinnen gestionados o un hogar personalizado sin devolver la ruta

• oculta las rutas del wrapper local, de instalación, del hogar de Agentin y del runner de Agentin detrás de campos de estado/categoría mientras conserva la existencia y las comprobaciones de salud

• informa los conteos y tamaños de retención de registros sin procesar sin devolver las rutas de directorio de registros sin procesar gestionados

• advierte, sin devolver rutas de archivos, cuando el MCP instalado apunta a este repositorio mientras el árbol de trabajo tiene cambios rastreados o no rastreados

• informa los enlaces simbólicos de instalación rotos, en bucle o ilegibles como una comprobación installed_symlink fallida con un marcador de objetivo ilegible

• trata a los Agentinnen detenidos como estado de sesión informativo, no como una comprobación de salud fallida

• redacta formas de secretos conocidas en la salida

watchdog

• clasifica el estado inactivo solo a partir de metadatos estructurados de status y metadatos de registros sin procesar; no llama a tail ni devuelve salida de Agentin

• por defecto usa idle_seconds=60, poll_interval_seconds=15, report_grace_seconds=15 y action=interrupt

• siempre pide al Agentin un informe conciso antes de interrupt, stop o release

• almacena solo un marcador de metadatos con hora de solicitud, ID de asignación, acción planificada y contadores de registros sin procesar; no se almacenan texto de indicación, respuestas ni registros sin procesar en el marcador

• omite los arrendamientos activos mantenidos por otros clientes; --manage-unclaimed puede supervisar solo arrendamientos no reclamados o expirados además del propio arrendamiento de este servidor

• admite --quiet para ejecuciones de systemd; los pases exitosos del watchdog no producen salida JSON, mientras que los fallos aún usan la ruta de error normal de la CLI

• se instala como una capa superior opcional de systemd --user a través de systemd/user/codex-master-watchdog.service y systemd/user/codex-master-watchdog.timer

• el servicio de usuario se ejecuta con directivas de endurecimiento conservadoras: CapabilityBoundingSet vacío, keyring privado/tmp/dispositivos, un bind de solo lectura del directorio de sockets de tmux del usuario, protecciones de kernel y reloj, jerarquía del sistema de solo lectura, acceso de escritura explícito solo a los directorios de estado gestionado y de runtime del usuario, sin sockets IP, sin namespaces, NoNewPrivileges, MemoryDenyWriteExecute, arquitectura de syscall nativa y UMask=0077; intencionalmente mantiene el acceso de lectura normal al hogar del usuario porque el watchdog necesita la configuración de Codex, IPC de tmux y archivos de estado gestionados

• codex-usage almacena sus instantáneas actuales bajo ~/.local/share/codex-usage/current/<account>.json por defecto; el lector acepta el diseño más antiguo de snapshots/ solo cuando el archivo actual está ausente y falla de forma cerrada cuando un archivo actual existente está malformado. usage_watchdog normaliza las ventanas actuales de 5 horas/semanales en datos Usage-v2 sin secretos, escribe el marcador de bloqueo local de codex-usage y rechaza nuevos flujos de agent_start/claim mientras una ventana de reinicio futura permanezca activa; los reinicios verificados pasados limpian el bloqueo y los reinicios desconocidos permanecen con fallo cerrado

watchdog-status

• informa si el temporizador de systemd está activo y si la última ejecución del servicio tuvo éxito, sin devolver la salida cruda de systemctl

• comprueba que el servicio y el temporizador de watchdog instalados coinciden con las copias del repositorio y que el servicio aún contiene las directivas de endurecimiento y las banderas de watchdog requeridas

• analiza solo la puntuación y el nivel de exposición agregados de systemd-analyze security; la salida cruda del analizador y las rutas locales de unidades no se devuelven

goddess report run procesa todos los buckets de informes UTC elegibles en orden cronológico, rellena hasta 24 horas y reintenta los buckets que no se finalizaron. Para la operación por horas, habilite el temporizador de usuario opcional endurecido:

systemctl --user daemon-reload
systemctl --user enable --now codex-master-goddess-report.timer

timeout-policy

• informa que agent_claim reintenta para siempre de forma predeterminada para fremde Bienen ocupadas, mientras que las esperas de reclamo finitas aún se aceptan sin un límite de 600 segundos

• informa que el sondeo de reclamos tiene un valor predeterminado de 30 segundos y un máximo de 900 segundos

• informa los valores predeterminados de recuperación de arrendamientos extranjeros detenidos para reclamos explícitos: solo Agentinnen detenidas, sin proceso de hogar administrado y suficiente evidencia de inactividad

• mantiene agent_wait separado como una espera de actividad acotada: 120 segundos predeterminados, máximo 600 segundos

• informa asignaciones headless productivas con un valor predeterminado de 600 segundos y un máximo de 7200 segundos (120 minutos)

• informa la puerta de preparación de lectura de entrada de TUI send/assign-*/report-request: valor predeterminado de 15 segundos, sondeo de 0,5 segundos, se requiere un aviso de entrada visible, falla cerrada sin pegar mediante agent_input_not_ready reintentable

• informa si la identidad actual del propietario de CLI/MCP es estable entre invocaciones sin devolver la identidad en sí

skills

• escanea cada hogar de Agentin en busca de archivos SKILL.md en skills/, plugins/cache/, y .tmp/plugins/

• ignora las raíces de habilidades con enlaces simbólicos y los archivos SKILL.md con enlaces simbólicos en lugar de seguirlos

• devuelve recuentos, raíces, nombres de habilidades del sistema y páginas acotadas de complementos/nombres

• informa plugin_count, plugins_offset, plugins_limit y plugins_truncated en lugar de volcar cada nombre de complemento cuando hay muchos instalados

• admite la enumeración deliberada a través de plugins_offset/plugins_limit y, con include_names, names_offset/limit

• no devuelve contenido de archivos de habilidades ni salida de terminal de Agentin

capabilities

• devuelve la política del modelo, el recuento total de habilidades, los nombres de las habilidades del sistema y una primera página de complementos acotada

• informa plugin_count, plugin_page_count, plugins_limit y plugins_truncated en lugar de volcar cada nombre de complemento cuando hay muchos instalados

Puente de aplicación

El complemento incluye .app.json y lo declara a través de .codex-plugin/plugin.json:

{
  "apps": {
    "codex-master": {
      "id": "connector_26697a678b7ec999dc005131eb5c087c"
    }
  }
}

Esta es la identidad local del puente de aplicación para el complemento codex-master. Mantiene la superficie de herramientas MCP existente con pocos datos y permite que Codex asocie el complemento con un ID de conector estable. El ID no es intencionalmente un secreto.

Para un conector de ChatGPT Developer Mode, ChatGPT aún tiene que crear o actualizar el conector contra un endpoint público HTTPS /mcp accesible. El MCP Masterjet actual se ejecuta como un MCP stdio local para Codex, por lo que .app.json organiza la identidad del puente del lado del complemento; no publica el repositorio en un Marketplace ni convierte el comando stdio local en un conector HTTP alojado por sí mismo.

Compruebe el estado del puente sin rutas locales:

python3 -m codex_master.server app-bridge-status

Habilidades de dirección

Las habilidades no se invocan como funciones MCP separadas. Son paquetes de instrucciones que un Agente de Codex utiliza cuando la tarea nombra la habilidad o coincide claramente con su dominio.

python3 -m codex_master.server skills all --agents-limit 30
python3 -m codex_master.server send a "Nutze codex-security:security-scan. Pruefe src/codex_master/server.py nur lesend und berichte knapp."
python3 -m codex_master.server send b "Nutze github:gh-fix-ci. Pruefe die CI-Konfiguration nur lesend und berichte knapp."
python3 -m codex_master.server tail a --source pane --lines 20 --chars 2000

Para una delegación más segura, prefiera assign-readonly, assign-live-data y assign-write sobre send de forma libre:

python3 -m codex_master.server assign-readonly a \
  --skill codex-security:security-scan \
  --scope src/codex_master/server.py \
  --task "Pruefe nur lesend und berichte knapp."

python3 -m codex_master.server assign-live-data a \
  --task "Wie ist das Wetter gerade in Berlin?" \
  --live-data-topic "Wetter Berlin heute"

python3 -m codex_master.server assign-write b \
  --skill github:gh-fix-ci \
  --scope .github/workflows \
  --write-path .github/workflows/ci.yml \
  --task "Haerte nur die CI-Datei und berichte Root Cause, Aenderung, Tests, Risiken."

assign valida las habilidades nombradas mediante el inventario, rechaza rutas de escritura para Exploriererinnen y requiere rutas de escritura explícitas para Arbeitsbienen. Envía el mensaje generado a través de tmux pero no devuelve el mensaje ni la respuesta del Agente.

Use assign-live-data para clima, noticias, precios, horarios o cualquier otra tarea de datos actuales. Es de solo lectura, usa las mismas protecciones de autenticación y arrendamiento que otras asignaciones e inyecta un requisito explícito de usar fuentes de búsqueda actuales o informar un límite de herramientas/acceso en lugar de adivinar. El tema concreto de datos en vivo se envía solo al mensaje del Agente; las respuestas públicas y los registros de auditoría de asignaciones mantienen el tema y el contenido de la respuesta fuera de los datos devueltos.

assign-write también controla las rutas de escritura a través de agent_scope_check; una ruta de escritura fuera del ámbito declarado se rechaza antes de que se envíe algo a un Agente. La creación de árboles de trabajo rechaza objetivos existentes, incluidos enlaces simbólicos rotos, y requiere que cada directorio principal en la ruta de destino sea un directorio real. La creación y el estado del árbol de trabajo están limitados al repositorio: los escapes relativos y los objetivos absolutos fuera del repositorio se rechazan antes de ejecutar git, y las respuestas de creación devuelven como máximo una ruta relativa al repositorio, nunca una ruta local absoluta. El estado del árbol de trabajo también rechaza enlaces simbólicos y objetivos que no son directorios antes de ejecutar git status. Las entradas de asignación y envío están limitadas antes de la interacción con tmux: los envíos libres y los mensajes de inicio están limitados a 12,000 caracteres, las tareas de asignación a 4,000 caracteres, los nombres a 80 caracteres, las referencias de habilidades a 300 caracteres, los campos similares a rutas a 1,000 caracteres y las listas de asignación a 50 elementos. Los argumentos booleanos y enteros de MCP se verifican de tipo; los valores convertidos a cadena se rechazan en lugar de ser forzados. Los marcos MCP entrantes están limitados a 1 MiB antes del análisis JSON. Los textos de error de herramientas y RPC se limpian de ANSI, se redactan y se limitan en longitud antes de devolverse. tools/call valida nombres de herramientas, parámetros y argumentos con forma de objeto, nombres de argumentos desconocidos, campos obligatorios, tipos de valores, enumeraciones y límites declarados antes del despacho. Los comandos de herramientas CLI locales pasan por la misma validación de esquema, con argumentos opcionales omitidos eliminados antes de la validación. Las cargas útiles multilínea de send y assign-* se envuelven con marcadores de pegado entre corchetes antes de pegar en tmux para que la TUI de Codex trate la plantilla como un solo mensaje en lugar de líneas enviadas por separado.

Antes de mutar a un Agente, start, assign-*, send, report-request, interrupt y stop verifican o renuevan un arrendamiento por Agente. Un segundo cliente MCP recibe un error estructurado reintentable en lugar de escribir en la misma sesión de tmux. Los arrendamientos de start recién creados se liberan nuevamente después de un lanzamiento exitoso; esto mantiene la CLI local utilizable en invocaciones separadas mientras se serializa la operación de inicio en sí. Los reclamos existentes mantenidos por el mismo cliente conectado se conservan. Use claim cuando una instancia de Codex-CLI deba esperar a un Agente ocupado; reintenta para siempre de forma predeterminada con intervalos de sondeo acotados. Use claim --no-wait para un intento único inmediato, o claim --wait-seconds ... para un límite finito explícito. Un claim explícito recupera un arrendamiento extranjero detenido solo después del período de gracia de detención, 120 segundos predeterminados, cuando el Agente no se está ejecutando y ningún proceso está usando ese hogar de Agente administrado. Use claim --no-recover-stopped cuando un operador quiera un comportamiento estricto solo de TTL. El estado del arrendamiento son metadatos únicamente y no devuelve la identidad del cliente, el texto del mensaje, la salida del Agente ni la ruta de estado local.

Los registros sin procesar son artefactos de depuración locales, no datos normales de API. La tubería de tmux escribe a través de un escritor local acotado, doctor informa la política de registros sin procesar configurada, y tail --source log rechaza rutas de metadatos fuera del estado de registros sin procesar administrado. Los registros sin procesar administrados deben ser archivos regulares; los enlaces simbólicos no se siguen y se eliminan de los directorios de registros sin procesar. El escritor oculto de registros sin procesar rechaza valores --max-bytes fuera de la política activa de registros sin procesar antes de tocar el estado o las rutas. Use tail solo cuando se necesite un extracto explícito, limitado, sin ANSI y redactado. Los inicios fallidos eliminan su archivo de registro sin procesar preparado antes de devolver un error.

La política del modelo se resuelve una vez a través del solucionador central de clase/ciclo de vida/modelo/esfuerzo documentado anteriormente. Las respuestas de inicio y asignación exponen la selección efectiva, el estado de respaldo y los códigos de motivo; los metadatos de auditoría de asignaciones registran el modelo efectivo sin almacenar mensajes ni respuestas.

Las Agentinnen pueden iniciar sus propias Subagentinnen nativas solo cuando la asignación usa --allow-subagents. Sin esa bandera, la asignación generada prohíbe explícitamente la delegación anidada. Incluso con la bandera, las Agentinnen anidadas permanecen dentro del ámbito asignado y las rutas de escritura; no usan codex-master-mcp y no hacen commit, push ni release.

No inicie un Agente administrado manualmente con el mismo CODEX_HOME mientras el Masterjet sea responsable de ella. start se niega a lanzar un Agente cuando su hogar ya está en uso por un proceso de Codex externo, y doctor informa tales conflictos de hogar antes de que se conviertan en contención de tmux o bloqueo. start también se niega a una sesión de Masterjet ya en ejecución si un segundo proceso externo está usando el mismo hogar. install se niega a registrar codex-master-mcp desde un hogar de Agentinnen administrado para que las herramientas de Masterjet permanezcan en la instancia de Teamleiterin/principal.

Las asignaciones se agregan a ~/.local/state/codex-master-mcp/assignments.jsonl solo como metadatos: id de asignación, Agente, rol, modelo seleccionado, estado de coincidencia de habilidades, ámbito, rutas de escritura, recuentos y banderas. El texto del mensaje y las respuestas del Agente no se almacenan ni se devuelven, y las respuestas de consulta de asignaciones no devuelven la ruta del archivo de auditoría local. El archivo de auditoría se conserva como un libro mayor JSONL local acotado: se mantienen los 500 registros de metadatos válidos más recientes, las líneas heredadas no válidas se eliminan durante la poda, y el archivo se reescribe con permisos 0600. El estado privado anexa rechaza rutas de enlaces simbólicos, los metadatos del Agente se escriben atómicamente y los archivos temporales de reemplazo con sufijo nonce se crean con semántica exclusiva sin seguimiento. Los directorios de estado administrados y sus cadenas principales deben ser directorios reales, no enlaces simbólicos ni archivos regulares. Las llamadas a procesos externos están limitadas por tiempo de espera y devuelven fallas de tiempo de espera estructuradas en lugar de bloquear el servidor MCP indefinidamente. agent_doctor también informa el contexto activo de CODEX_HOME sin devolver la ruta, y verifica que codex-master-mcp tenga un startup_timeout_sec de al menos 120 segundos en la configuración MCP activa de Codex.

Use tail solo cuando se necesite un extracto explícito y limitado. Las operaciones normales de estado y envío no devuelven la salida del Agente. tail se niega a leer la salida del panel o del registro mientras el Agente seleccionado tenga un arrendamiento activo mantenido por otro cliente MCP; reclame al Agente primero o espere a que expire el arrendamiento.

Complemento

Este repositorio también es un complemento local de Codex:

• .codex-plugin/plugin.json: metadatos del complemento e información de la interfaz de usuario de Codex

• .mcp.json: inicia codex-master-mcp desde este repositorio sin instalación de paquete y declara startup_timeout_sec = 120

• skills/codex-master-fleet/SKILL.md: habilidad de Teamleiterin para el Masterjet

El complemento está destinado a la instancia principal/Teamleiterin de Codex. Las Agentinnen administradas deben mantener su habilidad de trabajadora separada y no deben recibir herramientas MCP de Masterjet.

Una entrada de Marketplace es opcional. El repositorio contiene los artefactos del complemento, y el registro existente de codex-master-mcp puede ejecutar el servidor MCP directamente. Agregue una entrada de Marketplace personal/local solo si desea que la interfaz de usuario de complementos de Codex lo descubra e instale como complemento.

Comprobaciones

git diff --check
PYTHONPATH=src python3 -m compileall -q src tests
PYTHONPATH=src python3 -m unittest discover -s tests -v
./bin/codex-master-mcp tools

./bin/codex-master-mcp commit-ready-check ejecuta la puerta de lanzamiento local para git diff --check, compileall y las pruebas unitarias.

GitHub Actions usa .github/workflows/ci.yml para ejecutar las mismas puertas de fuente y pruebas unitarias, más la validación de manifiestos de complemento/App/MCP, comprobaciones de espacios en blanco confirmados para el rango de confirmaciones enviadas o de solicitudes de extracción, una comprobación de humo del envoltorio CLI, comprobaciones de fijación de SHA completo para acciones de flujo de trabajo externas y un humo temporal del instalador de grupo de agentes para validate, install, status y destroy_pool.