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

クローズ
  • 何か問題がありますか？
#11,149 コメント 0 件 リアクション 1 件 担当者 2 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@lpcox がすでに取り組んでいます。

2026年11月5日 から。

  • #11155 @copilot-swe-agent による — マージされずにクローズ
  • #11160 @copilot-swe-agent による — マージ済み

評価

この issue はまだ評価されていません。

説明

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.

主要言語
TypeScript
スター
157
フォーク
80
平均マージ
4時間 47分
マージ済み PR（30日）
414

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

github/gh-aw-firewall のほかの issue

github/gh-aw-firewall の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。