Copilot workflow compatibility regressions with pinned CLI versions and Cloud Hypervisor metadata writes #69161

Summary

Workflows compiled with gh-aw v0.92.x can fail before or after successful Copilot inference in two related compatibility gaps:

1. The v0.92 Copilot harness injects --session-id for model verification, but compilation still permits an explicitly pinned Copilot CLI version that does not support that option.
2. After successful model verification, the harness updates /tmp/gh-aw/aw_info.json, but Cloud Hypervisor workflows with a narrowed filesystem policy may leave that existing file read-only.

These surfaced in github/gh-aw-firewall PR #10037 after upgrading generated workflows to gh-aw v0.92.0. Recompiling with v0.92.1 does not appear to address either contract.

Problem 1: unsupported pinned Copilot CLI

A workflow with:

engine:
  id: copilot
  version: 1.0.34

compiles successfully with gh-aw v0.92.0. At runtime, copilot_harness.cjs adds an exact session selector and every launch exits immediately:

error: unknown option '--session-id'
Try 'copilot --help' for more information.

The harness retries four times, but no model request is made. Token-usage verification then fails downstream because token-usage.jsonl is empty.

Observed run: https://github.com/github/gh-aw-firewall/actions/runs/38821512596/job/116719084572

Removing the explicit 1.0.34 pin lets the v0.92 compiler/runtime select Copilot CLI 1.0.96 and resolves this failure.

Expected behavior

Compilation should reject an explicit Copilot CLI version that lacks features required by the generated harness, or generated runtime logic should remain compatible with the accepted version range.

The compatibility floor should specifically account for --session-id, rather than accepting the broader current min-agent range.

Problem 2: aw_info.json is read-only under Cloud Hypervisor

After removing the stale CLI pin, Copilot inference succeeds under Cloud Hypervisor, but the harness refuses to report success because it cannot persist the verified model selection:

[copilot-harness] Copilot model verification failed: Cannot record Copilot model selection: EROFS: read-only file system, open '/tmp/gh-aw/aw_info.json'. Refusing to report an unverified run as successful.

Observed run: https://github.com/github/gh-aw-firewall/actions/runs/38826354461/job/116734743554

The workflow already allowed writes to selected /tmp/gh-aw subdirectories. Adding the exact file below resolves the failure:

sandbox:
  agent:
    config:
      filesystem:
        allow-write:
          - /tmp/gh-aw/aw_info.json

The generated directory-preparation command must also avoid passing this existing file path to mkdir -p.

Expected behavior

For Copilot workflows using Cloud Hypervisor, compilation should automatically include the runtime metadata file in the writable contract when model verification will update it. Generated directory preparation should distinguish writable files from directories.

Affected workflows

The failure was reproduced in smoke-cloud-hypervisor. Static inspection found the same missing contract in additional Copilot Cloud Hypervisor workflows, including build-test and Playwright smoke variants.

Docker-backed Copilot workflows do not reproduce the EROFS failure because /tmp/gh-aw is mounted read-write. Claude and Codex Cloud Hypervisor workflows do not use this Copilot model-verification write path.

Suggested acceptance criteria

• Compilation rejects or upgrades an explicitly pinned Copilot CLI version that lacks required harness flags such as --session-id.
• The compatibility matrix expresses the feature-specific Copilot CLI minimum required by the generated harness.
• Copilot + Cloud Hypervisor generated workflows make /tmp/gh-aw/aw_info.json writable when model verification is enabled.
• File allow-write entries are excluded from generated mkdir -p directory preparation.
• Regression tests cover Docker and Cloud Hypervisor Copilot workflows, explicit old CLI pins, unpinned compatible CLI resolution, and postprocessing/idempotency.