[WIP] Fix copilot-harness post-step set_output ENOENT error

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>[aw-failures] Fix copilot-harness post-step set_output ENOENT (missing _runner_file_commands path)</issue_title>
<issue_description>### Problem

Every completed copilot agentic run in the github/gh-aw repository over the last 6 hours has been marked as failed despite the copilot agent itself exiting cleanly. Root cause is a single post-step bug in the copilot-harness: after the agent process exits with code 0, the harness attempts to write a GitHub Actions step output to $RUNNER_TEMP/_runner_file_commands/set_output_<uuid> and that path does not exist on disk, causing the harness to crash with ENOENT and exit 1.

Scope (6h window): 28 out of 28 completed copilot runs failed with this signature. ~17 distinct workflows affected. See parent #34281.

Reproducer signature

In agent-stdio.log for every failed run, the final 3 lines are:

[copilot-harness] attempt 1: process exit event exitCode=0
[copilot-harness] attempt 1: process closed exitCode=0 duration=<X> stdout=<N>B stderr=<M>B hasOutput=true
[copilot-harness] unexpected error: ENOENT: no such file or directory, open '/home/runner/work/_temp/_runner_file_commands/set_output_<uuid>'

The UUID is unique per run, confirming the file path is computed per-step from $GITHUB_OUTPUT (or equivalent runner file-commands API).

Confirmed in 3 sampled runs across schedule/push/PR triggers:

• §26340856986 — Daily Safe Output Integrator
• §26340664864 — Auto-Triage Issues
• §26340530704 — Smoke CI

Probable Root Cause

The copilot-harness wrapper writes a setOutput-style file-command after the agent process exits. One of the following is likely:

1. The harness is computing the file path from a runner env var (e.g. RUNNER_FILE_COMMANDS_PATH or GITHUB_OUTPUT) that points to a per-step file, but it is invoked from a context where the path either has already been consumed/cleaned up, or was never created (e.g. the harness step runs setOutput from a child process container that doesn't have the host-side runner temp directory bind-mounted, so the file looks present on the host but not inside the container).
2. The harness is running the setOutput write after the runner has finished the step and cleared _runner_file_commands.
3. The harness is hard-coding a stale UUID/filename across attempts when only the first attempt's set_output_<uuid> file is still valid.

The stderr line landing 4 ms after process closed (Daily Safe Output Integrator: 18:58:23.935 → 18:58:23.939) suggests the post-process callback is at fault, not the runner state itself.

Proposed Remediation

1. Locate the post-step output write in the copilot-harness (likely in pkg/workflow/harness or actions/setup JS sources).
2. Either:
   • Defensively guard the write: if fs.openSync(setOutputPath, ...) throws ENOENT, log a warning and continue with the existing exit code from the agent (do not override a successful agent exit with 1).
   • Or write to the runner file-commands path via the official @actions/core setOutput API rather than opening the path directly, which handles its own error semantics.
3. Ensure step-output writes happen while the step is still live (before any teardown), and that the harness inherits GITHUB_OUTPUT / runner file-command env vars correctly from the host runner step into any sub-container.
4. Add an integration test that simulates the post-step path being absent and verifies the harness still surfaces the agent's true exit code.

Success Criteria / Verification

• A new copilot run on a representative workflow (e.g. Smoke CI) completes with conclusion: success end-to-end, with process exit event exitCode=0 and no trailing harness ENOENT.
• Re-run the failure-investigator workflow on a 6h window post-fix: zero ENOENT: ... set_output_ matches across copilot runs.
• Per-workflow [aw] <Workflow> failed stub issues created by report-failure-as-issue stop accumulating for copilot workflows.

Affected Open Issues (will likely auto-close on fix)

#34275, #34273, #34271, #34269, #34267, #34264, #34262, #34260, #34259, #34257 — per-workflow stubs all exhibit the same harness signature.

Parent: #34281
Related to #34281

Generated by 🔍 [aw] Failure Investigator (6h) · ● 17.2M · ◷

• expires on May 30, 2026, 7:22 PM UTC

Comments on the Issue (you are @copilot in this section)