Fix shared enclave regression configuration and retain pre-broker failure diagnostics

Cerrado
  • ¿Algo no está bien?
#11,149 0 comentarios 1 reacción 2 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@lpcox ya está trabajando en esto.

Desde el 5/11/2026.

  • #11155 de @copilot-swe-agent — cerrado sin fusionar
  • #11160 de @copilot-swe-agent — fusionado

Evaluación

Este issue todavía no se ha evaluado.

Descripción

Failure and scope

All six enclave cases fail before broker readiness in Daily Agent Runtime Regression run 41982264274, source bab29c708a316ea52a9df4c7356b5d1acf71faed:

Agent Docker job Cloud Hypervisor job
Copilot 127109770531 127109770598
Claude 127109770662 127109770664
Codex 127109770668 127109770680

Each emits phase=pre-broker, reason=exit, category=unknown, exitCode=1, with the startup record missing. The subsequent protected collector also fails: failedCheck=run-evidence category=absent-evidence. Each uploaded artifact contains only collection-status.txt; no enclave invocation or inference success is established.

Confirmed configuration defects and evidence gap

The shared configuration builder always sets container.containerRuntime: 'docker'. At this same revision the canonical schema accepts only gvisor, sbx, cloud-hypervisor, and nvx as explicit primary runtime values; ordinary Docker is selected by omission. Generating the configuration and comparing it with that enum confirms the mismatch for every case.

For Cloud Hypervisor, simply removing the invalid field is insufficient: the builder also selects a Cloud Hypervisor enclave while keeping a Docker primary, contrary to the documented matching-backend contract. The harness must use a supported, internally consistent topology.

The precise fatal stderr is unavailable in published evidence. The harness writes private AWF stdout/stderr under a temporary directory, but only emits a coarse startup classification. Its final diagnostic call also omits the startup-error-file argument. Do not equate missing invocation artifacts with a successful startup, or claim the configuration fixes exhaust all possible later failures.

Single-PR scope and acceptance criteria

  • Generate valid configurations for all six selections and validate them against the canonical schema in tests.
  • Use supported primary/enclave backend pairings; do not bypass the mixed-backend rejection or weaken isolation.
  • Preserve bounded, allowlisted pre-broker diagnostics through the protected collector, including startup failures before an invocation journal exists. Keep raw logs, credentials, capabilities, and prompts private.
  • Preserve the original startup failure separately from any secondary collection failure.
  • Exercise the generated Python probe, including its credential-placeholder predicate, in deterministic tests so latent probe errors are caught before live inference.
  • Each case reaches broker/gateway readiness and completes one approved enclave invocation with the existing isolation, result-schema, audit, and cleanup assertions intact.

These six failures share one configuration/launch/collection path and should be addressed together, not as six provider-specific bugs. Related broader work: #10335 and #10341. No source modifications or live reruns were performed during triage.

Lenguaje dominante
TypeScript
Estrellas
157
Forks
80
Merge medio
4 h 47 min
PR fusionados (30 d)
414

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/gh-aw-firewall

Todos los issues de github/gh-aw-firewall

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.