[Hugo-DDT]

Problem

ExecuteBashTool.run_async() collected subprocess output with process.communicate(), which buffers all of stdout and stderr in the agent (parent) process with no size limit. RLIMIT_AS / RLIMIT_FSIZE apply to the child, not to the pipes, so a user-approved but verbose command could use up the agent process's memory before the timeout fires. The timeout path also returned everything it had captured, with no cap.

Fix

• New BashToolPolicy.max_output_bytes_per_stream (default 1 MiB, None disables).
• stdout and stderr are read concurrently in 64 KiB chunks into per-stream bounded buffers. Bytes over the limit are still read but thrown away, so the child never blocks on a full pipe, and memory stays at roughly limit + one chunk per stream.
• Truncated output ends with an explicit marker, e.g. ...[stdout truncated: N of M bytes omitted; limit is L bytes].
• Timeout: the read tasks are shielded from the wait_for cancellation, so the pipes keep draining after the process group is SIGKILLed. Then the process is reaped (with a short grace period, after which any leftover readers are cancelled). The process-group cleanup in finally is unchanged.

Tests

New TestOutputLimits in tests/unittests/tools/test_bash_tool.py:

• small output comes back unchanged
• 2 MiB of stdout is truncated to the limit, with the marker and the correct omitted-byte count
• interleaved large stdout and stderr are each bounded on their own
• None turns the limit off
• a command that never ends and writes nonstop times out, its output is bounded, and the process is reaped (returncode == -SIGKILL)

I updated the existing mocked-process tests to stub stdout/stderr instead of communicate().

Red/green: the new tests fail against main (7 failed) and pass with the fix. pytest tests/unittests/tools/test_bash_tool.py tests/unittests/tools/test_bash_tool_windows.py → 33 passed. Formatted with pyink + isort.

Fixes #7507

[BichengWang]

Reviewed head 9cf04517672d6b3f2a868ba2d5fc3eb81bf40234, including the cancellation follow-up discussed in #7507.

[P2] Retrieve the original completion future after cancellation — bash_tool.py:385–390

completion.cancel() cancels the original gather(), but the cleanup only awaits a different gather over readers. Since wait_for() has already cancelled the shield, nothing retrieves completion's CancelledError. A normal, handled cancellation consequently reaches the event loop's exception handler as:

_GatheringFuture exception was never retrieved
asyncio.exceptions.CancelledError

This produces an unhandled-error log and invokes application exception-reporting hooks for expected cancellation. It reproduces with a single sleeping subprocess; no background descendant is needed. The existing cancellation test checks pending reader tasks, so it passes despite this error.

Please await/consume the original completion future after cancelling it, while preserving cancellation propagation. A regression can install a temporary loop exception handler, start a command that writes a readiness marker and sleeps, wait for the marker, cancel run_async, catch its expected CancelledError, yield/collect finished futures, and assert that the handler received no errors. I verified that awaiting asyncio.gather(completion, return_exceptions=True) after completion.cancel() clears this reproduction. The timeout path also needs to consume completion when _finish_readers() cancels readers: a detached descendant holding a pipe open reproduced the same warning there.

Validation on macOS / Python 3.13.16, offline:

• PYTHONPATH=src python -m pytest -q -p no:cacheprovider tests/unittests/tools/test_bash_tool.py tests/unittests/tools/test_bash_tool_windows.py: 37 passed.
• The real-subprocess cancellation regression passes against the PR base 62745ccc62513514bc0f30f5cfdaf1c593d156ca, fails against this head with the error above, and passes with the completion-await remedy applied only to an in-memory module copy.
• Feeding 64 MiB in 64 KiB chunks into _BoundedOutput with a 1 MiB limit retained exactly 1,048,576 bytes, reported 66,060,288 omitted bytes, and peaked at 1,106,090 traced bytes during accumulation. This supports the bounded-capture approach independently of the returned string length.

I did not run the full multi-version tox suite.

[Hugo-DDT]

Thanks @BichengWang — addressed in e8581a2: the cancelled completion future is now awaited so its CancelledError is retrieved while cancellation still propagates, and I added the regression test with a temporary loop exception handler as you described.