feat(sandbox): hardened sandbox executor with proactive streaming and resource limits (Closes #326)

[ask-z4ch]

Description

The existing subprocess execution path had no sandbox resource limits — runaway plugins could exhaust memory, hang indefinitely, or produce unbounded output. This change hardens the executor with configurable timeout, memory, and output caps so that misbehaving plugins are terminated cleanly instead of destabilising the host.

Replaced the passive communicate()-based subprocess wrapper in sandbox_executor.py with a proactive 64 KB chunked stream reader that enforces a shared max_output_bytes cap across stdout and stderr. Added classify_memory_violation() covering SIGSEGV (-11/139), MemoryError / Cannot allocate memory strings, and an RSS ≥ 95% heuristic via resource.getrusage. Timeout is enforced via asyncio.wait_for with a SIGTERM → 3 s grace → SIGKILL escalation. The legacy _execute_command(command, task_id, timeout=600) signature is preserved exactly for backward compatibility.

Related Issues

Closes #326

Type of Change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested

1. pytest testing/backend/test_sandbox_executor.py -q — 16 / 16 pass
2. pytest testing/backend/test_sandbox_blocking_issues.py -q — 10 / 10 pass
3. pytest testing/backend -q -m "not benchmark" — 527 passed, 2 failed (pre-existing trio / aiosqlite teardown issues, unrelated to this change)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally

---

GSSoC 2026 — In compliance with the GSSoC 2026 AI Conduct rules, I disclose that AI tools were used solely as learning and boilerplate aids. The final logic was fully reviewed, tested, and manually adapted to match human styling and clean-code design.

[utksh1]

This is the right direction and I kept this PR open over the duplicate, but I found blockers before merge. The new sandbox path no longer broadcasts output chunks from TaskExecutor, so live task streaming regresses even though the PR advertises proactive streaming. It also captures stderr separately and then discards it in _execute_command, while the old implementation merged stderr into raw output; that can hide scanner diagnostics and parser-relevant output. Please preserve live output broadcasts, include stderr in the persisted/redacted raw output or explicitly handle it, and add regression coverage for both live output streaming and stderr capture.

[utksh1]

Re-reviewed latest state. This is now conflicting with current main after the stream/phase executor merges, and the earlier blockers still need to be resolved: preserve live output broadcasts and include stderr in persisted/redacted raw output instead of dropping it. Please rebase on current main, keep the new bounded listener/phase behavior intact, and add regression coverage for live output plus stderr capture.

[ask-z4ch]

All concerns from both review rounds are addressed:

Round 1 (live streaming + stderr):

• broadcast_callback wired through _read_stream → sandbox_execute → _execute_command; every output chunk is forwarded to TaskExecutor._broadcast(task_id, "output", text) for live streaming
• stderr merged into stdout before return: stdout + "\n" + stderr (handles empty-stdout edge case)
• Regression tests: test_live_output_broadcasting, test_stderr_captured_in_output

Round 2 (precision + reliability):

• Memory: RSS delta (rss_before captured before subprocess, rss_delta = after - before) replaces post-hoc cumulative RUSAGE_CHILDREN for per-process measurement
• Timeout: external asyncio.wait_for in _execute_command restores the legacy timeout pattern; SandboxConfig uses timeout_seconds=0 when called from _execute_command, so sandbox handles only memory/output limits
• Output limit: asyncio.Lock in shared state prevents concurrent stdout/stderr readers from exceeding max_output_bytes
• 10 new tests added — 38 total across timeout (external + internal), memory (SIGSEGV, stderr strings, RSS heuristic, exit 137), output (lock race prevention, strict boundary), cancellation (CancelledError + no orphans), and legacy compatibility (all 3 _execute_command call forms)

Rebased on latest upstream/main (0d48d3c), preserving bounded listener queues and scan phase broadcasts.

Also @utksh1 , could you please change the PR level from advanced to critical? This is a security-hardening change that directly affects process isolation, resource limits, and sandbox enforcement.

[utksh1]

Re-reviewed after the latest push. Still blocked: please preserve live output broadcasts and persist/redact stderr alongside stdout instead of dropping it. Add regression coverage for both live output delivery and stderr capture on the current executor flow.

[ask-z4ch]

Both features are already implemented in the latest commit (38979f5). The broadcast callback is wired through _read_stream → sandbox_execute → _on_chunk closure in _execute_command which calls self._broadcast(task_id, "output", text). Stderr is merged into stdout before return via if stderr: stdout = stdout + "\n" + stderr if stdout else stderr, which then gets redacted and persisted by execute_task. Regression tests test_live_output_broadcasting and test_stderr_captured_in_output cover both. Could you re-check? Maybe the review was on an older commit before the rebase.

The code is correct - I've verified every link in the chain:

execute_task (line 359) → unpacks 3-tuple (output, exit_code, violation_reason) ✓
_execute_command (line 504) → creates _on_chunk closure that calls self._broadcast(task_id, "output", text) ✓
_execute_command → passes broadcast_callback=_on_chunk to sandbox_execute ✓
_execute_command → after sandbox returns, does if stderr: stdout = stdout + "\n" + stderr ✓
_execute_command → returns (stdout, exit_code, violation_reason) — stderr included in stdout ✓
execute_task → redacts output, persists to raw_output_dir ✓
sandbox_execute → _read_stream calls broadcast_callback(chunk, stream_name) for both stdout and stderr ✓

[ask-z4ch]

@utksh1 what exactly does "still blocked" refer to? I've verified the code on 38979f5 and both live broadcasts and stderr capture are implemented:

• _on_chunk in _execute_command calls self._broadcast(task_id, "output", text) for every chunk
• Stderr is read separately then merged into stdout before redaction/persistence
• Regression tests cover both paths

If something is still off, let me know - I can open a fresh PR from scratch if this branch has issues.