[cli-tools-test] compile --actionlint/--zizmor gives misleading "Docker images downloading" error when Docker is unavailable

[github-actions]

Problem Description

When running compile with --actionlint or --zizmor (or the MCP compile tool with actionlint: true / zizmor: true) in an environment where the Docker daemon is not running, the tool returns a persistent misleading error instead of a clear diagnosis.

Observed Error

Docker images are being downloaded. Please wait and retry the compile command.

Started downloading: actionlint

Retry in 15-30 seconds.
```

This message loops indefinitely — retrying after 15s, 30s, 60s, and beyond always returns the same message. The root cause is that Docker is not available (`Cannot connect to the Docker daemon at unix:///var/run/docker.sock`), so images can never be downloaded.

### Steps to Reproduce

1. Use the `compile` MCP tool with `actionlint: true` on any workflow in an environment without Docker running
2. Observe the error message
3. Retry after 60+ seconds — same message repeats

### Expected Behavior

The tool should detect that Docker is unavailable and return a clear, actionable error:

```
Error: Docker is not available (cannot connect to Docker daemon).
actionlint and zizmor require Docker. Please install and start Docker, 
or omit the --actionlint/--zizmor flags.

Actual Behavior

Returns "Docker images are being downloaded. Please wait and retry." indefinitely — the user has no indication that Docker itself is missing versus images just being slow to pull.

Environment

• Repository: github/gh-aw
• Run ID: §23029320370
• Date: 2026-03-12
• Docker check: Cannot connect to the Docker daemon at unix:///var/run/docker.sock

Impact

• Severity: Medium
• Frequency: Always (when Docker is not running)
• Workaround: Omit actionlint/zizmor flags; compile without static analysis

---

Additional Findings from Daily Testing Session

The following secondary issues were also observed during today's exploratory test:

compiled_file field returned for failed compilations

When a workflow fails to compile (e.g., mcp-inspector.md, security-alert-burndown.campaign.g.md), the compile result still includes a compiled_file path pointing to the existing lock file from a prior successful compile. This can mislead users into thinking the file was updated.

Reproduce: Compile mcp-inspector.md — it fails due to npm not found, yet compiled_file is populated with the previous .lock.yml path.

Suggestion: Omit compiled_file from the response (or set it to null) when valid: false.

Copilot-engine audit reports turns: 0

Auditing a Copilot-engine workflow run (e.g., Terminal Stylist, run §23026731124, 7.5 min duration) shows turns: 0 in metrics and generates the key finding: "Completed in 0 turns with no errors" — this is misleading for a 7.5-minute run.

Expected: Either show actual turns or omit the turns metric when it's not available for the Copilot engine.

mcp_tool_usage.tool_calls is always null

In both logs and audit results, mcp_tool_usage.tool_calls is consistently null across all tested runs (Copilot, Claude, Codex engines). This field appears to be unimplemented/empty in all cases.

References:

• §23029320370
• §23026994242
• §23026731124

Generated by Daily CLI Tools Exploratory Tester · ◷

• expires on Mar 19, 2026, 11:57 PM UTC