feat: mount host filesystem read-only with isolate.sh fallback by Copilot · Pull Request #439 · github/gh-aw-firewall

Copilot · 2026-01-27T09:05:37Z

Problem

Host filesystem mounted read-write (/:/host:rw) allows accidental or malicious writes during command execution. Need security hardening while preserving ability to execute host binaries not present in container.

Changes

Mount configuration

docker-manager.ts: Changed default mount from /:/host:rw → /:/host:ro
Updates tests to expect read-only mount

Command isolation wrapper

New isolate.sh script provides transparent host binary fallback:
1. Check container PATH → execute directly if found
2. Check /host mount → chroot to host if binary found there
3. Fall through to bash error handling if neither

Integration

Dockerfile: Install isolate.sh to /usr/local/bin/
entrypoint.sh: Wrap all user commands with isolate.sh automatically

Example behavior:

# Container has curl → uses container's curl
awf --allow-domains github.com 'curl https://api.github.com'

# Container lacks terraform → chroots to /host, uses host's terraform
awf --allow-domains example.com 'terraform version'

Security model

Read-only mount prevents filesystem writes
chroot provides process isolation for host binaries
Graceful fallback: no set -e, POSIX-compliant path tests
Transparent: no CLI changes, backward compatible
Maintains existing NET_ADMIN drop and non-root execution

Documentation

Updated AGENTS.md with architecture details and types.ts with new default mount mode.

Original prompt

This section details on the original issue you should resolve

<issue_title>[Security] Mount host filesystem as read-only with isolate.sh fallback</issue_title>
<issue_description>## Background

PR #394 proposed mounting the host filesystem as read-only for improved security, with an isolate.sh utility to run host binaries via chroot when not available in container PATH.

Proposed Changes

Read-only host mount: Change default mount from /:/host:rw to /:/host:ro in docker-manager.ts

isolate.sh script: Add to agent container at /usr/local/bin/isolate.sh

Falls back to chroot into /host when binary not found in container PATH

Handles both absolute paths and relative commands

Validates /host exists before chroot attempt

Automatic command wrapping: Modify entrypoint.sh to wrap all user commands with isolate.sh

Security Benefits

Prevents accidental or malicious writes to the host filesystem

Maintains ability to execute host binaries when needed

Issue created from PR #394 during backlog cleanup</issue_description>

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

Fixes [Security] Mount host filesystem as read-only with isolate.sh fallback #420

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

github-actions · 2026-01-30T20:38:20Z

🎬 THE END — Smoke Claude MISSION: ACCOMPLISHED! The hero saves the day! ✨

github-actions · 2026-01-30T20:38:21Z

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

github-actions · 2026-01-30T20:38:26Z

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

github-actions · 2026-01-30T20:38:55Z

✅ Coverage Check Passed

Overall Coverage

Metric	Base	PR	Delta
Lines	78.45%	78.45%	➡️ +0.00%
Statements	78.52%	78.52%	➡️ +0.00%
Functions	78.01%	78.01%	➡️ +0.00%
Branches	72.49%	72.49%	➡️ +0.00%

Coverage comparison generated by scripts/ci/compare-coverage.ts

github-actions · 2026-01-30T20:41:01Z

Smoke Test Results

✅ GitHub MCP: #437 fix: address code review feedback for isolate.sh, #435 docs: update AGENTS.md with read-only mount and isolate.sh documentation
✅ Playwright: Page title verified
✅ File Write: Test file created successfully
✅ Bash Tool: File read back successfully

Status: PASS

AI generated by Smoke Claude

github-actions · 2026-01-30T20:41:09Z

Smoke Test Results for Copilot Engine 🧪

Last 2 Merged PRs:

feat(cli): add --enable-chroot for transparent host binary execution #448: feat(cli): add --enable-chroot for transparent host binary execution
docs: add agent image tooling reference #426: docs: add agent image tooling reference

Test Results:
✅ GitHub MCP - Retrieved PR data
✅ Playwright - GitHub page title verified
✅ File Writing - Test file created at /tmp/gh-aw/agent/smoke-test-copilot-21529896867.txt
✅ Bash Tool - File content verified

Overall Status: PASS ✅

cc @Mossaka

AI generated by Smoke Copilot

github-actions · 2026-01-30T20:41:25Z

🔒 Security Review: Critical Issue Found

This PR aims to strengthen security by mounting the host filesystem as read-only, which is commendable. However, the implementation introduces a critical security vulnerability related to the chroot mechanism in isolate.sh.

❌ Critical: chroot Escape Risk with awfuser

File: containers/agent/isolate.sh (lines 50, 61)
File: containers/agent/entrypoint.sh (line 301)

Issue:

The isolate.sh script executes chroot /host as the non-root user awfuser after capabilities have been dropped. This creates a container escape vector because:

chroot is not a security boundary when run as non-root - A non-root chroot can be escaped using various techniques (relative path manipulation, file descriptor tricks, etc.)
Once inside the chroot, the process has access to the entire host filesystem (albeit read-only)
The process can access host network namespaces, IPC, and other resources not restricted by the read-only mount

Vulnerable Code:

# isolate.sh line 50
exec chroot /host "$COMMAND" "${@:2}"

# isolate.sh line 61
exec chroot /host "${BINDIR}/${COMMAND}" "${@:2}"

Why this is critical:

chroot executed as non-root does not provide process isolation as claimed in the PR description
Malicious code running in a chrooted environment can potentially escape and access the full host environment
The read-only mount prevents filesystem writes but does not prevent:
- Reading sensitive host files (SSH keys, credentials, /proc, /sys)
- Accessing host network configuration
- Exploiting host kernel vulnerabilities via syscalls

Recommended fixes:

Option 1 (Most Secure): Remove chroot entirely

Document that users should pre-install required binaries in the container
Or use container customization (multi-stage builds) to add needed tools
The read-only mount alone provides good protection without the chroot escape risk

Option 2 (Requires Rearchitecture): Use proper namespaces

Run chroot operations in a separate container with PID/network namespacing
Use tools like unshare or bwrap (bubblewrap) that provide actual isolation
This would require significant changes to the entrypoint flow

Option 3 (Band-aid): Restrict what can be executed via chroot

Maintain a whitelist of allowed host binaries (terraform, etc.)
Validate the command name against the whitelist before chrooting
This is less flexible but prevents arbitrary host binary execution

✅ Positive Security Changes

The following changes are security improvements:

Read-only host mount (/:/host:ro instead of /:/host:rw)
- Prevents accidental or malicious filesystem writes
- Good defense-in-depth measure
No weakening of existing controls
- NET_ADMIN capability drop still in place
- Seccomp profile unchanged
- iptables rules intact

Recommendation

Do not merge this PR until the chroot escape vulnerability is addressed. The most pragmatic approach is Option 1 (remove chroot entirely and document container customization), as it provides the security benefits of read-only mounts without introducing new attack vectors.

If host binary fallback is a hard requirement, consider Option 3 with a very restricted whitelist of specific binaries that have been audited for safety when run in a non-root chroot environment.

AI generated by Security Guard

github-actions · 2026-01-30T20:43:13Z

Chroot Mode Binary Version Test Results

Summary

The test reveals PATH configuration differences between the host setup step and the chroot environment, resulting in different binary versions being executed.

Version Comparison

Runtime	Host Version (Captured)	Chroot Version (Current)	Match?	Notes
Python	Python 3.12.3	Python 3.13.11	❌ FAIL	Different binary in PATH
Node	v20.20.0	v24.13.0	❌ FAIL	Different binary in PATH
Go	go version go1.24.12 linux/amd64	go version go1.24.12 linux/amd64	✅ PASS	Versions match

Analysis

Root Cause

The host has multiple versions of Python and Node installed:

Python versions available:

/usr/bin/python3 → Python 3.12.3 (system default)
/opt/hostedtoolcache/Python/3.13.11/x64/bin/python3 → Python 3.13.11
/opt/hostedtoolcache/Python/3.12.12/x64/bin/python3 → Python 3.12.12
/opt/hostedtoolcache/Python/3.11.14/x64/bin/python3 → Python 3.11.14
And more...

Node versions available:

/opt/hostedtoolcache/node/24.13.0/x64/bin/node → v24.13.0
/opt/hostedtoolcache/node/20.20.0/x64/bin/node → v20.20.0
/opt/hostedtoolcache/node/22.22.0/x64/bin/node → v22.22.0

PATH Difference

Host (setup step):

Likely used system Python /usr/bin/python3 → 3.12.3
Node PATH unknown (but resolved to v20.20.0)

Chroot (current PATH):

/opt/hostedtoolcache/Python/3.13.11/x64/bin:/opt/hostedtoolcache/node/24.13.0/x64/bin:...

The chroot PATH prioritizes hostedtoolcache versions, with newer versions first.

Why Go Matches

Go version 1.24.12 is both:

In /opt/hostedtoolcache/go/1.24.12/x64/bin/go (first in PATH)
The version that would be selected on the host

Test Result

❌ FAIL - Python and Node versions do not match host versions.

Recommendations

Fix PATH consistency: Ensure the chroot environment uses the same PATH configuration as the host setup step
Use absolute paths: Capture full binary paths in host-versions.env, not just version strings
Pin versions: Use actions/setup-python and actions/setup-node with specific versions to ensure consistency
Document behavior: If PATH differences are intentional, document that chroot uses hostedtoolcache-first resolution

AI generated by Smoke Chroot

Mossaka · 2026-01-30T20:52:29Z

@copilot-swe-agent review

Remove the isolate.sh script which used non-root chroot for host binary fallback. As identified in the security review, non-root chroot is not a security boundary and can be escaped. Changes: - Remove containers/agent/isolate.sh - Update entrypoint.sh to run commands directly without isolate.sh - Update Dockerfile to not copy isolate.sh - Update AGENTS.md documentation The read-only host mount (/:/host:ro) is preserved as it provides security benefits. Users who need host binary access should use the --enable-chroot flag which provides proper isolation. Addresses: Security Guard review comment

github-actions · 2026-01-30T20:55:35Z

🎬 THE END — Smoke Claude MISSION: ACCOMPLISHED! The hero saves the day! ✨

github-actions · 2026-01-30T20:55:36Z

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

github-actions · 2026-01-30T20:55:39Z

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

Copilot · 2026-01-30T20:55:55Z

@copilot-swe-agent review

Code Review Results

Found a critical functional issue that prevents the feature from working as designed:

❌ CRITICAL: `isolate.sh` cannot execute chroot as non-root user

Problem:

isolate.sh runs as awfuser (non-root) after the entrypoint does gosu awfuser /usr/local/bin/isolate.sh
The script attempts to call chroot /host at lines 50 and 61
chroot requires root privileges - it will fail with "Operation not permitted"

Proof:

$ chroot /tmp/test-dir /bin/ls
chroot: cannot change root directory to '/tmp/test-dir': Operation not permitted

Impact:

The host binary fallback mechanism never works
Any command not in container PATH will fail, even if it exists on host
Tests pass because they don't actually execute commands that trigger the chroot path

Root cause:
The implementation conflates two different approaches:

Chroot mode (existing): Entire command runs inside chroot /host, chroot called by root entrypoint before privilege drop
Non-chroot mode (this PR): Tries to selectively chroot for missing binaries, but chroot called after privilege drop

Recommendation:
Either:

Remove isolate.sh and revert to /:/host:ro mount only (simpler, still provides security benefit)
Or redesign to execute chroot at entrypoint level before privilege drop (complex, similar to existing chroot mode)

Option 1 is recommended for simplicity. The read-only mount alone provides the security benefit without the non-functional fallback mechanism.

github-actions · 2026-01-30T20:58:40Z

Smoke Test: Claude Engine - PASS

Last 2 merged PRs:

fix: switch security-guard workflow to claude engine
feat(cli): add --enable-chroot for transparent host binary execution

✅ GitHub MCP - retrieved PRs
✅ Playwright - verified page title "GitHub · Change is constant. GitHub keeps you ahead. · GitHub"
✅ File Writing - created /tmp/gh-aw/agent/smoke-test-claude-21530342401.txt
✅ Bash Tool - verified file content

AI generated by Smoke Claude

github-actions · 2026-01-30T20:59:59Z

Smoke Test: Verify Language Runtimes Match Host - CANNOT COMPLETE

Issue

The test cannot be completed as designed because:

Current Environment: Running inside AWF agent container (user: awfuser)
Docker-in-Docker Not Supported: AWF v0.9.1 removed Docker-in-Docker support (PR feat: remove Docker-in-Docker support #205)
Cannot Run Nested AWF: Cannot execute awf --enable-chroot from within an AWF container

Environment Analysis

Host Versions (from /tmp/host-versions.env):

Python: 3.12.3
Node: v20.20.0
Go: go1.24.12 linux/amd64

Current Container Versions (without chroot):

Python: 3.13.11
Node: v24.13.0
Go: go1.24.12 linux/amd64

Recommendations

To make this test work, restructure the workflow to:

Option 1: Run test directly on GitHub Actions runner host (not inside AWF)

- name: Test chroot mode
  run: |
    sudo node dist/cli.js --enable-chroot --allow-domains localhost -- python3 --version
    sudo node dist/cli.js --enable-chroot --allow-domains localhost -- node --version  
    sudo node dist/cli.js --enable-chroot --allow-domains localhost -- go version

Option 2: Check if current AWF instance has chroot enabled

Verify /host/usr, /host/bin, /host/sbin mounts exist
Run binaries via chroot and compare versions

Option 3: Have workflow setup step run awf --enable-chroot and capture output for comparison

Error Details

Attempted to run: node dist/cli.js --enable-chroot --allow-domains localhost -- python3 --version

Result: ERROR: Docker-in-Docker support was removed in AWF v0.9.1

AI generated by Smoke Chroot

Mossaka · 2026-02-03T19:31:58Z

@copilot please merge origin/main

…copilot/secure-host-filesystem-mount

Mossaka

Review: REQUEST_CHANGES

@copilot Please fix the following critical issues:

Critical Issue: Branch is Behind Main

Your branch is 4 commits behind main and would delete recent features if merged:

7c5d99f - Version bump to 0.13.4
3099a14 - GOROOT/bin PATH fix for chroot mode
5b1c63c - --skip-pull flag feature (#493)

If merged, this PR would:

Delete the skipPull option from types.ts
Revert version number
Remove the GOROOT/bin PATH fix
Remove 47 test cases from cli.test.ts

Required Fix

Rebase your branch on top of current main:
```
git fetch origin
git rebase origin/main
```
Remove stale comment in docker-manager.ts that references the removed isolate.sh:
```
// The isolate.sh script enables execution of host binaries via chroot when needed
```
This comment should be deleted since isolate.sh was correctly removed.
Re-run CI after rebasing to verify all tests pass.

The core security change (read-only host mount) is sound - just needs the rebase.

* feat(cli): add --skip-pull flag to use pre-downloaded images Add a new --skip-pull CLI flag that prevents Docker Compose from pulling images from the registry, allowing users to use pre-downloaded or cached images locally. This is useful for: - Air-gapped environments where registry access is unavailable - CI systems with pre-warmed image caches - Local development when images are already cached When --skip-pull is enabled, Docker Compose runs with --pull never. If the required images are not available locally, container startup will fail with a clear error message. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test: add tests for skipPull parameter in startContainers Add unit tests to verify: - --pull never is passed when skipPull is true - --pull never is not passed when skipPull is false Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: address review comments for --skip-pull flag - Add validation to reject --skip-pull + --build-local combination since building images requires pulling base images - Add security warning when using --skip-pull to inform users about verifying image authenticity - Add documentation for --skip-pull in CLI reference: - Options Summary table entry - Detailed explanation with usage examples - Security caution about image verification - Note about incompatibility with --build-local Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test: add tests for validateSkipPullWithBuildLocal function Extract flag validation logic into a testable function and add comprehensive tests to improve coverage on the new --skip-pull validation code. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * refactor: use validation function in CLI action handler Simplify the --skip-pull validation by using the extracted validateSkipPullWithBuildLocal function instead of inline checks. This reduces code duplication and improves coverage. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test: improve test coverage for docker-manager - Add test for when removing existing containers fails (covers catch block) - Add tests for allowHostPorts option in generateDockerCompose Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * test: improve coverage for skipPull and related features - Add test for container removal failure handling in startContainers - Add tests for allowHostPorts environment variable - Add tests for GOROOT/CARGO_HOME/JAVA_HOME passthrough in chroot mode These tests improve overall coverage from 82.15% to 82.37%, exceeding the baseline of 82.25%. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

When GOROOT is provided (via AWF_GOROOT), the entrypoint now prepends $GOROOT/bin to PATH before exporting GOROOT. This ensures the correct Go version is found when actions/setup-go installs a specific version. Previously, only GOROOT was exported without adding its bin directory to PATH. This caused the system Go (e.g., 1.24.12) to be found instead of the setup-go version (e.g., 1.25.0) because AWF_HOST_PATH might have wrong ordering due to sudo resetting PATH. This matches how JAVA_HOME and CARGO_HOME are handled - their bin directories are prepended to PATH. Fixes gh-aw smoke-copilot test failure: "Go 1.24.12 < required 1.25.0" Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

…de (#456) * Initial plan * fix: replace head with awk in setup-iptables for chroot mode Replace `head -n 1` with awk's NR==1 to avoid GLIBC version mismatch when running in chroot mode. In chroot mode, host binaries are mounted at /host/*, and setup-iptables.sh runs before the chroot happens. The host's head binary may require a newer GLIBC than available in the container (Ubuntu 22.04 has GLIBC 2.35, GitHub Actions runners have GLIBC 2.38+). This fixes the error: head: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.38' not found Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

* Initial plan * feat: allow empty allowDomains to block all network access Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> * test: add integration tests for empty domains (no network access) Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> * test: fix misleading test title for DNS behavior test Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> * ci: re-trigger workflow checks * chore: merge origin/main and fix integration test Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> Co-authored-by: Jiaxiao (mossaka) Zhou <duibao55328@gmail.com>

* Initial plan * feat: filter benign operational logs from Squid access.log - Add ACL and log_access directive to filter localhost healthcheck probes - Update log aggregator to skip transaction-end-before-headers entries - Add comprehensive tests for both changes Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

Copilot AI assigned Copilot and Mossaka Jan 27, 2026

Copilot started work on behalf of Mossaka January 27, 2026 09:05 View session

Copilot AI changed the title ~~[WIP] Change host filesystem mount to read-only with isolate.sh addition~~ feat: mount host filesystem read-only with isolate.sh fallback Jan 27, 2026

Copilot AI requested a review from Mossaka January 27, 2026 09:16

Copilot finished work on behalf of Mossaka January 27, 2026 09:16

Mossaka marked this pull request as ready for review January 30, 2026 20:32

Copilot AI and others added 4 commits January 30, 2026 20:36

Initial plan

790bab5

feat: mount host filesystem as read-only with isolate.sh fallback

8f11448

Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

docs: update AGENTS.md with read-only mount and isolate.sh documentation

f9f9d11

Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

fix: address code review feedback for isolate.sh

9b2c73d

Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

Mossaka force-pushed the copilot/secure-host-filesystem-mount branch from 81698d0 to 9b2c73d Compare January 30, 2026 20:38

github-actions bot added the smoke-claude label Jan 30, 2026

github-actions bot added the smoke-copilot label Jan 30, 2026

Copilot started work on behalf of Mossaka January 30, 2026 20:52 View session

Copilot finished work on behalf of Mossaka January 30, 2026 20:57

Merge branch 'main' of https://github.com/github/gh-aw-firewall into …

6481f74

…copilot/secure-host-filesystem-mount

Mossaka requested changes Feb 4, 2026

View reviewed changes

Mossaka and others added 9 commits February 4, 2026 17:16

0.13.2

cd81e21

0.13.3

b2885ba

chore: bump version to 0.13.4

59529b3

chore: rebase on main and remove stale isolate.sh comment

6255270

Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

Mossaka closed this Feb 4, 2026

github-actions bot mentioned this pull request Feb 4, 2026

fix: restructure smoke-chroot workflow to avoid Docker-in-Docker #508

Merged

3 tasks

Conversation

Copilot AI commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Changes

Security model

Documentation

Proposed Changes

Security Benefits

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

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Coverage Check Passed

Overall Coverage

Uh oh!

github-actions bot commented Jan 30, 2026

Uh oh!

github-actions bot commented Jan 30, 2026

Uh oh!

github-actions bot commented Jan 30, 2026

🔒 Security Review: Critical Issue Found

❌ Critical: chroot Escape Risk with awfuser

✅ Positive Security Changes

Recommendation

Uh oh!

github-actions bot commented Jan 30, 2026

Chroot Mode Binary Version Test Results

Summary

Version Comparison

Analysis

Root Cause

PATH Difference

Why Go Matches

Test Result

Recommendations

Uh oh!

Mossaka commented Jan 30, 2026

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI commented Jan 30, 2026

Code Review Results

❌ CRITICAL: isolate.sh cannot execute chroot as non-root user

Uh oh!

github-actions bot commented Jan 30, 2026

Uh oh!

github-actions bot commented Jan 30, 2026

Smoke Test: Verify Language Runtimes Match Host - CANNOT COMPLETE

Issue

Environment Analysis

Recommendations

Error Details

Uh oh!

Mossaka commented Feb 3, 2026

Uh oh!

Mossaka left a comment

Choose a reason for hiding this comment

Review: REQUEST_CHANGES

Critical Issue: Branch is Behind Main

Required Fix

Uh oh!

Reviewers

Assignees

Copilot AI commented Jan 27, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

github-actions bot commented Jan 30, 2026 •

edited

Loading

❌ CRITICAL: `isolate.sh` cannot execute chroot as non-root user