fix(ahma_mcp): stop routing Windows spawns through the broken AppContainer path - #558
Merged
Merged
Conversation
…ainer path A windows-latest CI run of the newly-landed R6.3.3 work (#555) proved the AppContainer grant DACL does not take effect: in-scope writes are denied along with out-of-scope ones. Because create_platform_sandboxed_ command() routed every non-Test-mode Windows spawn through the launcher unconditionally, this broke essentially every Windows integration test that runs a real subprocess - handshake/timeout/roots tests across ahma_http_bridge, tool availability probes, and the two AppContainer gate tests themselves - not just the AppContainer-specific coverage. create_platform_sandboxed_command() now falls back to the plain (Job-Object-contained) base_command() on Windows, matching the platform's pre-R6.3.3 behavior and AGENTS.md's standing status ("AppContainer spawn isolation is still pending"). The AppContainer code, its launcher, and plan_windows_sandboxed_spawn stay in place and directly tested; only the two behavioral gate tests that depend on the grant actually working are marked #[ignore] with the CI failure cited, matching the existing precedent for red_team_command_write_escape_ blocked. SPEC R6.3.3 status updated from "unproven" to "disproven". Also fixes five egress-proxy unit tests in shell::modes::server that asserted maybe_start_egress_proxy always starts a proxy under restrict_network=true - it deliberately returns None on Windows (R6.3.3.1a: AppContainer blocks loopback), so those five are now gated #[cfg(not(windows))] and a new Windows-specific test pins the None-return behavior instead of leaving it silently untested.
paulirotta
enabled auto-merge (squash)
August 8, 2026 13:55
paulirotta
added a commit
that referenced
this pull request
Aug 8, 2026
…nore] (#559) reads_outside_the_scope_are_blocked only passed on windows-latest CI by accident: the (now-disabled, see #558) AppContainer grant denied every read, in-scope included, so a read genuinely outside the scope also failed and satisfied the assertion for the wrong reason. With Windows spawns now falling back to Job-Object-only containment (no path confinement per SPEC R6.3.9), the read legitimately succeeds and the test fails honestly instead of passing by coincidence. Ignored with the same rationale as the other two appcontainer gate tests, and SPEC R6.3.3's status note updated to cover all three.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A windows-latest CI run of the newly-landed R6.3.3 work (#555) proved
the AppContainer grant DACL does not take effect: in-scope writes are
denied along with out-of-scope ones. Because create_platform_sandboxed_
command() routed every non-Test-mode Windows spawn through the launcher
unconditionally, this broke essentially every Windows integration test
that runs a real subprocess - handshake/timeout/roots tests across
ahma_http_bridge, tool availability probes, and the two AppContainer
gate tests themselves - not just the AppContainer-specific coverage.
create_platform_sandboxed_command() now falls back to the plain
(Job-Object-contained) base_command() on Windows, matching the
platform's pre-R6.3.3 behavior and AGENTS.md's standing status
("AppContainer spawn isolation is still pending"). The AppContainer
code, its launcher, and plan_windows_sandboxed_spawn stay in place and
directly tested; only the two behavioral gate tests that depend on the
grant actually working are marked #[ignore] with the CI failure cited,
matching the existing precedent for red_team_command_write_escape_
blocked. SPEC R6.3.3 status updated from "unproven" to "disproven".
Also fixes five egress-proxy unit tests in shell::modes::server that
asserted maybe_start_egress_proxy always starts a proxy under
restrict_network=true - it deliberately returns None on Windows
(R6.3.3.1a: AppContainer blocks loopback), so those five are now
gated #[cfg(not(windows))] and a new Windows-specific test pins the
None-return behavior instead of leaving it silently untested.