fix: handle missing docker-compose.yml during cleanup gracefully

[Claude]

stopContainers() fails with "no configuration file provided: not found" when the work directory or docker-compose.yml is missing during cleanup, causing GitHub Actions workflows to exit with errors.

Changes

• Added defensive checks in stopContainers() to verify workDir and docker-compose.yml exist before running docker compose down -v
• Implemented fallback mechanism to stop containers by name (awf-agent, awf-squid) using docker rm -f when compose file is unavailable
• Each container cleanup uses independent try-catch to prevent cascading failures

Implementation

// Check if compose file exists before using docker compose
const composeFile = path.join(workDir, 'docker-compose.yml');
if (fs.existsSync(workDir) && fs.existsSync(composeFile)) {
  // Normal path: use docker compose down
  await execa('docker', ['compose', 'down', '-v'], { cwd: workDir });
} else {
  // Fallback: stop containers by name
  for (const name of ['awf-agent', 'awf-squid']) {
    const { stdout } = await execa('docker', ['ps', '-aq', '-f', `name=^${name}$`]);
    if (stdout.trim()) {
      await execa('docker', ['rm', '-f', name]);
    }
  }
}

This ensures cleanup succeeds regardless of workDir state, preventing workflow failures when the environment is in an unexpected state.

[github-actions]

Chroot tests passed! Smoke Chroot - All security and functionality tests succeeded.

[github-actions]

📰 VERDICT: Smoke Copilot has concluded. All systems operational. This is a developing story. 🎤

[github-actions]

💫 TO BE CONTINUED... Smoke Claude failed! Our hero faces unexpected challenges...

[github-actions]

C++ Build Test Results

Project	CMake	Build	Status
fmt	✅	✅	PASS
json	✅	✅	PASS

Overall: PASS ✅

All C++ projects built successfully.

AI generated by Build Test C++

[github-actions]

Build Test: Deno - BLOCKED

❌ Unable to complete Deno tests due to AWF credential hiding incompatibility

Error Details

Deno tests fail with the following error:

error: Error loading .npmrc at /home/runner/.npmrc.

Caused by:
    Is a directory (os error 21)

Root Cause

AWF's credential hiding mechanism mounts /home/runner/.npmrc as /dev/null (which appears as a directory), but Deno expects .npmrc to either:

• Be a regular file
• Not exist

This causes Deno to fail during initialization before any tests can run.

Test Status

Project	Tests	Status
oak	N/A	BLOCKED
std	N/A	BLOCKED

Overall: BLOCKED

Recommended Solutions

1. Update AWF to use a different credential hiding method that doesn't break Deno (e.g., mount an empty file instead of /dev/null)
2. Add --allow-npmrc flag to temporarily disable .npmrc hiding for Deno compatibility
3. Run Deno tests outside the AWF firewall

Note: Label build-test-deno NOT added due to test failure.

AI generated by Build Test Deno

[github-actions]

Node.js Build Test Results ✅

All Node.js projects tested successfully!

Project	Install	Tests	Status
clsx	✅	PASS	PASS
execa	✅	PASS	PASS
p-limit	✅	PASS	PASS

Overall: PASS

All projects installed dependencies and ran tests successfully.

AI generated by Build Test Node.js

[github-actions]

Smoke Test Results (Run 21935968806)

Last 2 merged PRs:

• feat: add release highlights generator agentic workflow #197: feat: add release highlights generator agentic workflow
• feat: hide /tmp/gh-aw/mcp-logs/ from agent containers #706: feat: hide /tmp/gh-aw/mcp-logs/ from agent containers

✅ GitHub MCP: Retrieved PR data
✅ Playwright: Title verified ("GitHub")
✅ File Write: Created test file
✅ Bash Tool: File verified

Status: PASS

cc @Mossaka @lpcox @Copilot

AI generated by Smoke Copilot

[github-actions]

Build Test: Bun - Results

Project	Install	Tests	Status
elysia	✅	1/1	PASS
hono	✅	1/1	PASS

Overall: PASS ✅

All Bun projects built and tested successfully.

AI generated by Build Test Bun

[github-actions]

🔴 Rust Build Test - FAILED

Error: Rust toolchain not available in workflow environment.

Project	Build	Tests	Status
fd	❌	N/A	FAILED
zoxide	❌	N/A	FAILED

Overall: FAIL

Error Details

The workflow environment does not have the Rust toolchain installed. cargo command not found.

Required Fix: The workflow needs to install Rust before running tests:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source $HOME/.cargo/env

Or use the actions-rs/toolchain GitHub Action in the workflow setup.

AI generated by Build Test Rust

[github-actions]

Go Build Test Results

Project	Download	Tests	Status
color	✅	1/1	PASS
env	✅	1/1	PASS
uuid	✅	1/1	PASS

Overall: PASS

All Go projects built and tested successfully.

AI generated by Build Test Go

[github-actions]

.NET Build Test Results

Project	Restore	Build	Run	Status
hello-world	✅	✅	✅	PASS
json-parse	✅	✅	✅	PASS

Overall: PASS ✅

All .NET projects successfully restored, built, and ran with expected output.

AI generated by Build Test .NET

[github-actions]

Chroot Version Comparison Test Results

Runtime	Host Version	Chroot Version	Match?
Python	3.12.12	3.12.3	❌ NO
Node.js	v24.13.0	v20.20.0	❌ NO
Go	go1.22.12	go1.22.12	✅ YES

Overall Result: ❌ Tests Failed

Chroot mode successfully binds host runtimes, but version mismatches indicate the container is using its own bundled versions instead of host binaries. Only Go matched between host and chroot environments.

AI generated by Smoke Chroot

[github-actions]

Security Review: Network Cleanup Gap in Fallback Path

Issue: Network Resource Leak in Fallback Cleanup

The fallback cleanup mechanism added in this PR has a network cleanup gap that could create security vulnerabilities.

Problem

When docker-compose.yml is missing, the code falls back to removing containers by name:

File: src/docker-manager.ts:1318-1333

// Stop and remove containers by name
const containerNames = ['awf-agent', 'awf-squid'];
for (const name of containerNames) {
  try {
    // Check if container exists
    const { stdout } = await execa('docker', ['ps', '-aq', '-f', `name=^${name}$`]);
    if (stdout.trim()) {
      logger.debug(`Stopping container: ${name}`);
      await execa('docker', ['rm', '-f', name], { stdio: 'inherit' });
    }
  } catch (err) {
    logger.debug(`Could not stop container ${name}:`, err);
  }
}

However, the network is not removed in this fallback path.

Security Impact

1. Network Persistence: The awf-net Docker network (172.30.0.0/24) remains active after fallback cleanup
2. Stale Firewall Rules: The network bridge interface persists, potentially leaving host-level iptables rules active
3. Inconsistent Security State: Future runs may inherit stale network configuration with residual firewall rules, creating gaps in egress filtering

Comparison with Normal Path

Normal cleanup (src/docker-manager.ts:1307-1311):

await execa('docker', ['compose', 'down', '-v'], {
  cwd: workDir,
  stdio: 'inherit',
});

docker compose down -v removes:

• ✅ Containers
• ✅ Volumes
• ✅ Networks defined in the compose file

Fallback cleanup:

• ✅ Containers
• ❌ Networks NOT removed

Recommendation

Add network cleanup to the fallback path to maintain security parity:

} else {
  // Fallback: compose file missing, stop containers by name
  logger.debug('Compose file not found, stopping containers by name');

  // Stop and remove containers by name
  const containerNames = ['awf-agent', 'awf-squid'];
  for (const name of containerNames) {
    try {
      const { stdout } = await execa('docker', ['ps', '-aq', '-f', `name=^${name}$`]);
      if (stdout.trim()) {
        logger.debug(`Stopping container: ${name}`);
        await execa('docker', ['rm', '-f', name], { stdio: 'inherit' });
      }
    } catch (err) {
      logger.debug(`Could not stop container ${name}:`, err);
    }
  }
  
  // Also remove the network to match docker compose down behavior
  try {
    await execa('docker', ['network', 'rm', 'awf-net'], { reject: false });
    logger.debug('Removed awf-net network');
  } catch (err) {
    logger.debug('Could not remove network:', err);
  }

  logger.success('Containers stopped successfully');
}

Severity

Medium - While not an immediate exploit vector, inconsistent cleanup could leave the firewall in an undefined state. The security boundary relies on proper teardown of all Docker resources and iptables rules. Network persistence breaks this assumption.

---

Note: The existing code intentionally keeps the network across runs for performance (see comment in src/cli.ts:1006), but this is only safe when cleanupHostIptables() is called. The fallback path doesn't guarantee consistent iptables cleanup if the network persists without the compose file.

AI generated by Security Guard

[github-actions]

Java Build Test Results ✅

All Java projects compiled and tested successfully through the AWF firewall.

Project	Compile	Tests	Status
gson	✅	1/1	PASS
caffeine	✅	1/1	PASS

Overall: PASS

All compilation and test execution completed successfully with Maven proxy configuration.

AI generated by Build Test Java

[Copilot]

Pull request overview

This PR adds defensive error handling to stopContainers() to prevent failures when docker-compose.yml is missing during cleanup. The changes implement a fallback mechanism that stops containers by name using docker rm -f when the compose file is unavailable.

Changes:

• Added existence checks for workDir and docker-compose.yml before attempting docker compose down
• Implemented fallback to stop containers by name (awf-agent, awf-squid) when compose file is missing
• Added individual try-catch blocks for each container to prevent cascading failures

Comments suppressed due to low confidence (1)

src/docker-manager.ts:1314

• The comment "Normal path: use docker compose down" is misleading. Due to the security fix at line 1149 that deletes docker-compose.yml immediately after containers start, this path will rarely execute during normal operation. The "fallback" path (lines 1314-1332) is actually the normal execution path.

Consider updating comments to reflect this reality:

• Line 1307: "Compose file exists (e.g., startup failed before deletion): use docker compose down"
• Line 1314: "Normal path: compose file was deleted for security, stop containers by name"

      // Normal path: use docker compose down
      await execa('docker', ['compose', 'down', '-v'], {
        cwd: workDir,
        stdio: 'inherit',
      });
      logger.success('Containers stopped successfully');
    } else {
      // Fallback: compose file missing, stop containers by name

---

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

[Copilot]

The logic assumes the fallback path (stopping containers by name) is for error scenarios, but due to the security fix at line 1149 that deletes docker-compose.yml immediately after containers start, the compose file will NOT exist during normal cleanup. This makes the fallback path the primary execution path, not a true fallback.

Consider either:

1. Removing the compose file check and always using docker rm to stop containers by name (simpler, more predictable)
2. Keeping the compose file but restricting its permissions instead of deleting it
3. Adding a comment explaining that this is the expected normal path, not just a fallback

The current implementation works correctly but the code structure and comments are misleading about which path is the normal case versus the exceptional case.

This issue also appears on line 1307 of the same file.

[Copilot]

The error handling in the fallback path swallows all errors with individual try-catch blocks (lines 1320-1329). This means if both containers fail to stop (e.g., Docker daemon is down), the function will still log "Containers stopped successfully" and return without error.

Consider tracking whether at least one container operation succeeded, or accumulating errors and throwing if no containers could be stopped. For example:

let stoppedAny = false;
const errors: Error[] = [];
for (const name of containerNames) {
  try {
    // ... existing logic ...
    stoppedAny = true;
  } catch (err) {
    errors.push(err);
    logger.debug(`Could not stop container ${name}:`, err);
  }
}
if (!stoppedAny && errors.length > 0) {
  throw new Error(`Failed to stop any containers: ${errors.map(e => e.message).join(', ')}`);
}

This ensures the outer error handler and calling code are aware when cleanup truly fails.