feat: increase logging in copilot driver for silent startup failures

[Copilot]

Summary

Investigated failure at https://github.com/github/gh-aw/actions/runs/24158694003/job/70504330302#step:22

Root cause of the failure: The Copilot CLI (pid=147) started inside the sandbox container but exited after just 1 second with exit code 1 and zero bytes of output (stdout=0B stderr=0B). The driver correctly did not retry since there was nothing to resume, but the lack of output made it impossible to diagnose the root cause (no indication of whether it was a missing binary, permission issue, auth failure, or silent crash).

Changes

All changes are in actions/setup/js/copilot_driver.cjs:

1. Pre-flight check (checkCommandAccessible): Before spawning, verify the command exists (F_OK) and is executable (X_OK), logging the result. This will surface binary not found or permission denied issues immediately rather than leaving them as a silent exit-code-1.

2. Better error event logging: Cast err to NodeJS.ErrnoException to extract err.code and err.syscall. These fields (e.g. code=ENOENT syscall=spawn) are critical for diagnosing spawn failures.

3. Actionable "no output" message: When the process exits with no output, the log now includes a list of possible causes: binary not found, permission denied, auth failure, or silent startup crash.

4. Node.js version + platform at startup: Adds nodeVersion=v22.x.x platform=linux to the starting log line for environment diagnostics.

What the new logs would look like in a "binary not found" scenario

[copilot-driver] 2026-... starting: command=/usr/local/bin/copilot ... nodeVersion=v22.14.0 platform=linux
[copilot-driver] 2026-... pre-flight: command not found: /usr/local/bin/copilot (F_OK check failed — binary does not exist at this path)
[copilot-driver] 2026-... attempt 1: spawning: /usr/local/bin/copilot ...
[copilot-driver] 2026-... attempt 1: failed to start process '/usr/local/bin/copilot': spawn ENOENT (code=ENOENT syscall=spawn)
[copilot-driver] 2026-... attempt 1: process closed exitCode=1 duration=0s stdout=0B stderr=0B hasOutput=false
[copilot-driver] 2026-... attempt 1 failed: exitCode=1 isCAPIError400=false hasOutput=false retriesRemaining=3
[copilot-driver] 2026-... attempt 1: no output produced — not retrying (possible causes: binary not found, permission denied, auth failure, or silent startup crash)

[Copilot]

Pull request overview

This PR improves diagnostics in the Copilot CLI driver to make “silent” startup failures (exit code 1 with no stdout/stderr) easier to debug in CI/sandbox environments.

Changes:

• Add a pre-flight accessibility/executability check for the Copilot command and log the result.
• Improve spawn failure logging by including err.code and err.syscall.
• Enrich startup and no-output logs with Node version/platform and actionable “possible causes” text.

Show a summary per file

File	Description
actions/setup/js/copilot_driver.cjs	Adds pre-flight command checks and expands driver logs for startup/spawn/no-output diagnostics.
actions/setup/js/copilot_driver.test.cjs	Adds small unit-style assertions for new log message fields/content.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (2)

actions/setup/js/copilot_driver.cjs:90

• The pre-flight log messages in the catch blocks hard-code a single cause (“binary does not exist” / “permission denied”), but fs.access can fail for other reasons (e.g., EACCES on the F_OK check due to directory permissions, ENOTDIR, etc.). Capturing the thrown error and logging err.code/err.message would avoid misleading diagnostics.

  try {
    await fs.promises.access(command, fs.constants.F_OK);
  } catch {
    log(`pre-flight: command not found: ${command} (F_OK check failed — binary does not exist at this path)`);
    return false;
  }
  try {
    await fs.promises.access(command, fs.constants.X_OK);
    log(`pre-flight: command is accessible and executable: ${command}`);
    return true;
  } catch {
    log(`pre-flight: command exists but is not executable: ${command} (X_OK check failed — permission denied)`);
    return false;

actions/setup/js/copilot_driver.cjs:203

• checkCommandAccessible() returns a boolean but the result is ignored (await checkCommandAccessible(command);). Either use the return value to change control flow (e.g., exit early when the command path is definitely unusable) or make the helper void to avoid implying it affects execution.

  log(`starting: command=${command} maxRetries=${MAX_RETRIES} initialDelayMs=${INITIAL_DELAY_MS}` + ` backoffMultiplier=${BACKOFF_MULTIPLIER} maxDelayMs=${MAX_DELAY_MS}` + ` nodeVersion=${process.version} platform=${process.platform}`);

  await checkCommandAccessible(command);

• Files reviewed: 2/2 changed files
• Comments generated: 1

[Copilot]

checkCommandAccessible() is called with command exactly as passed to the driver. When command is a PATH-resolved binary like copilot (the usage example suggests this), fs.access('copilot', ...) checks only the current working directory and will incorrectly log “command not found”. Consider skipping the fs-based checks unless command includes a path separator / is absolute, or resolve the executable via PATH (e.g., which/command -v) before calling fs.access.

This issue also appears in the following locations of the same file:

• line 78
• line 200