fix(harness): prevent pipe deadlock in LocalFilesystemWithShell.execute

[zzz-ghost]

What this PR does

Fixes a pipe deadlock in LocalFilesystemWithShell.execute(): the child process's stdout/stderr are now drained on daemon threads concurrently with Process.waitFor(), instead of only after it returns.

Root cause

Previously execute() called Process.waitFor(timeout) first and read getInputStream() / getErrorStream() only afterwards. If the child wrote more than the OS pipe buffer (≈4 KB on Windows, 64 KB default on Linux), it blocked in write() forever while the parent blocked in waitFor() — a classic pipe deadlock. Every such command was misreported as a timeout (exit 124) and forcibly killed, even though it would have finished in well under a second.

Fix

• Start two daemon drainer threads (8 KB chunks into ByteArrayOutputStream) immediately after ProcessBuilder.start(), then waitFor(timeout), then join the drainers — destroying the process first on timeout so the drainers terminate.
• This mirrors the fix already applied to ShellCommandTool in agentscope-core ("Start asynchronous stream readers immediately to prevent pipe buffer deadlock"), which LocalFilesystemWithShell was missed by.
• Behavior is otherwise unchanged: same timeout messages, exit code 124 semantics, charset selection, and maxOutputBytes truncation.

Testing

New regression test execute_outputLargerThanOsPipeBufferCompletesWithoutDeadlock prints ~70 KB via shell builtins (works on both sh and cmd.exe, no Python needed):

	Before fix	After fix
Result	deadlock → killed after 60 s, exit 124	completes in 0.4 s, exit 0
Output	—	all 4000 lines captured, not truncated

Verified on Windows 10 (≈4 KB pipe buffer); the threshold (68–72 KB) also exceeds the 64 KB Linux default pipe buffer, so the test covers both platforms.

Fixes #2838

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 5 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ent/filesystem/local/LocalFilesystemWithShell.java	80.00%	4 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[zzz-ghost]

Note: the two earlier build (ubuntu-latest) failures on this PR were a pre-existing flaky
test, unrelated to this change — HarnessAgentDynamicHookBuilderTest failed in different
methods each run with JUnitException: Failed to close extension context
(DirectoryNotEmptyException on the JUnit @TempDir). It looks like a race between JUnit
temp-dir cleanup and the framework's fire-and-forget session/transcript mirror writes;
HarnessAgent.close() documents this race, but these tests never close the agent.
CI is green after re-running. Happy to file a separate issue for the flaky test if you'd like.

[dailingtao]

LGTM cc @jujn

[xiaoyuuuuuupeng]

Deadlock fix LGTM.

Please open follow-up PR(s)/issues for:

1. Cap writes inside drainAsync using maxOutputBytes (keep reading so the pipe stays drained; mark truncated). Post-hoc truncate can OOM before truncation runs. gemini-cli / qwen-code both bound capture during async drain.
2. Align reader teardown with ShellCommandTool (Future.get + cancel(true), or after join if isAlive() → interrupt and discard the untrusted BAOS).

Optional: add a stderr / dual-stream regression test.

[xiaoyuuuuuupeng]

nit / follow-up: please bound memory while draining, not only after assembling the final string.

maxOutputBytes currently truncates post-hoc, so a huge command can OOM before truncation. Cap buf.write once buf.size() hits the limit, but keep reading so the OS pipe stays drained (same idea as gemini-cli / qwen-code). Mark truncated when bytes were discarded.

[xiaoyuuuuuupeng]

nit / follow-up: please align reader completion with ShellCommandTool.

join(5s) may return while the drainer is still alive; ByteArrayOutputStream is not thread-safe, so calling toString() concurrently with write is racy. Prefer Future.get(timeout) + cancel(true) and discard untrusted output on timeout, or after join check isAlive() → interrupt and do not trust the buffer.

[zzz-ghost]

Thanks! Filed #2850 to track these — will send a follow-up PR once this one lands.