[awf] Docker Manager: Copilot CLI events.jsonl not captured in artifact (session-state written inside container)

[lpcox]

Problem

When the Copilot CLI runs inside the AWF sandbox (Docker container), the session-state events.jsonl file is written to $HOME/.copilot/session-state/ inside the container. The compiled workflow's "Copy Copilot session state files to logs" step reads from the host's $HOME/.copilot/session-state, which is empty because the CLI ran in the container.

As a result, the agent_outputs artifact contains only process-*.log — no events.jsonl — making conversation-level debugging and benchmarking impossible for AWF-wrapped Copilot CLI runs.

Context

• Original issue: Feature request: Upload Copilot CLI session-state events.jsonl as a workflow artifact gh-aw#19648
• AWF version: v0.20.2 (issue filed), likely still relevant
• Copilot CLI: 0.0.415+

Root Cause

Looking at src/docker-manager.ts lines 898–899 and 962–966, AWF does mount the session-state directory:

// Line 898-899
`\$\{sessionStatePath}:\$\{effectiveHome}/.copilot/session-state:rw`,
// Line 962-966
agentVolumes.push(`\$\{sessionStatePath}:/host\$\{effectiveHome}/.copilot/session-state:rw`);

The sessionStatePath defaults to \$\{workDir}/agent-session-state (line 463). The session-state data is accessible in \$\{workDir}/agent-session-state/ after the run, and performCleanup() moves it to /tmp/awf-agent-session-state-<timestamp> (lines 2674–2681).

The gap is in the compiled workflow's artifact upload step: it copies from $HOME/.copilot/session-state on the host (which is empty), not from the AWF-managed path. This is a gap in postprocess-smoke-workflows.ts or the compiled workflow template.

Proposed Solution

1. scripts/ci/postprocess-smoke-workflows.ts: When post-processing smoke/build-test lock files, find the "Copy Copilot session state files to logs" step and rewrite the copy source path from $HOME/.copilot/session-state to \$\{AWF_SESSION_STATE_DIR:-/tmp/awf-agent-session-state-*} — or emit an explicit AWF-managed path.

2. src/cli.ts / src/docker-manager.ts: Export the session-state path as an environment variable (e.g., AWF_SESSION_STATE_DIR) after the run completes, so downstream steps can reference it reliably without glob patterns.

3. src/docker-manager.ts performCleanup(): When preserving session-state (lines 2674–2681), write the final path to a well-known file (e.g., \$\{workDir}/.awf-session-state-path) so the workflow step can read it with cat.

4. Compiled workflow template: Update the session-state copy step to use the AWF-managed path. This requires changes to the gh-aw compiler workflow template for engine.id: copilot.

Generated by Firewall Issue Dispatcher · ● 1.6M · ◷

[github-actions]

👋 Hello! I noticed this issue might be related to existing issues:

• agent-container: add volume mount for ~/.copilot/session-state so events.jsonl is accessible for artifact upload #1466 — agent-container: add volume mount for ~/.copilot/session-state so events.jsonl is accessible for artifact upload — describes the identical end symptom (events.jsonl missing from artifacts because session-state is written inside the container) and proposes the same agent-session-state volume mount solution. Closed as completed.
• fix: events.jsonl not captured — chroot bind mount bypasses AWF workDir volume #1592 — fix: events.jsonl not captured — chroot bind mount bypasses AWF workDir volume — a follow-up that found the chroot bind mount at ~/.copilot shadowed the workDir volume, preventing events.jsonl from reaching the host. Also closed as completed.

Both issues targeted the src/docker-manager.ts volume mount layer. If those fixes landed but the problem persists, this new issue may represent the remaining gap on the compiled workflow / artifact-copy step side — which is a distinct sub-problem worth tracking separately.

If either of these fully addresses your concern, please consider closing this as a duplicate. Otherwise, clarifying how the current behavior differs from what those fixes were expected to solve would help narrow the scope!

This is an automated message from the issue duplication detector.

Generated by Issue Duplication Detector for issue #1932 · ● 292.7K · ◷