#3926's stderr drain loop terminated at line 101:

    while lines_read < MAX_LINES {
        match reader.next_line().await { ... lines_read += 1; ... }
    }

After the 100th line the task exits and stops reading the pipe.  Once
the kernel pipe buffer fills (64 KiB on Linux), the child's next
write(stderr) blocks forever — re-creating the exact pipe-stall
failure mode #3926 claimed to fix.  Any moderately chatty MCP server
(e.g. one that prints a banner + per-request log) hits this within
seconds.

Switch to a  that keeps reading after MAX_LINES but skips
the format/log work:

  - lines_read < MAX_LINES → format and debug! the line as before.
  - lines_read == MAX_LINES → log a single 'capped, still draining'
    notice so an operator can correlate.
  - lines_read > MAX_LINES → next_line(), discard, continue.

The pipe stays drained indefinitely.  The only break paths are now
EOF (child closed stderr) and a real I/O error (pipe unusable),
which is the only correct shutdown signal.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…n stall

The audit of #3926 caught two real properties of the stdio shutdown
path:

  1. tokio Command's kill_on_drop(true) only sends SIGKILL — it does
     NOT call wait().  The child becomes a zombie until tokio's
     internal child reaper task runs.  If the reaper is itself
     starved (runtime spinning down) or already dropped (synchronous
     drop on a runtime that's been ejected), the zombie persists
     until the daemon process itself exits.

  2. McpConnection::close() awaits client.close() unconditionally —
     a wedged rmcp transport loop blocks the caller forever.  Hot
     reload (which awaits this) and daemon graceful shutdown both
     accumulate stalls there.

A full fix for the kill_on_drop / no-wait gap requires hijacking
the child handle out of rmcp's RunningService, which means either
patching rmcp upstream or replacing the transport entirely — far
outside follow-up scope.  The contained improvement is bounding
both close paths so the daemon stops betting on the tokio reaper:

  * Explicit close (close()): wrap client.close() in a 10s
    tokio::time::timeout.  Healthy servers complete easily; a stuck
    one stops blocking hot-reload.
  * Implicit close (Drop): same 10s timeout inside the spawn so a
    wedged transport doesn't pin a tokio worker.

10s is generous enough that a normally-shutting child finishes
without a warning but tight enough that 'still running 10 seconds
after kill' is the right signal that something failed and we
should rely on OS-level reap-on-process-exit.

#3926's stderr drain loop terminated at line 101:

    while lines_read < MAX_LINES {
        match reader.next_line().await { ... lines_read += 1; ... }
    }

After the 100th line the task exits and stops reading the pipe.  Once
the kernel pipe buffer fills (64 KiB on Linux), the child's next
write(stderr) blocks forever — re-creating the exact pipe-stall
failure mode #3926 claimed to fix.  Any moderately chatty MCP server
(e.g. one that prints a banner + per-request log) hits this within
seconds.

Switch to a  that keeps reading after MAX_LINES but skips
the format/log work:

  - lines_read < MAX_LINES → format and debug! the line as before.
  - lines_read == MAX_LINES → log a single 'capped, still draining'
    notice so an operator can correlate.
  - lines_read > MAX_LINES → next_line(), discard, continue.

The pipe stays drained indefinitely.  The only break paths are now
EOF (child closed stderr) and a real I/O error (pipe unusable),
which is the only correct shutdown signal.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…n stall

The audit of #3926 caught two real properties of the stdio shutdown
path:

  1. tokio Command's kill_on_drop(true) only sends SIGKILL — it does
     NOT call wait().  The child becomes a zombie until tokio's
     internal child reaper task runs.  If the reaper is itself
     starved (runtime spinning down) or already dropped (synchronous
     drop on a runtime that's been ejected), the zombie persists
     until the daemon process itself exits.

  2. McpConnection::close() awaits client.close() unconditionally —
     a wedged rmcp transport loop blocks the caller forever.  Hot
     reload (which awaits this) and daemon graceful shutdown both
     accumulate stalls there.

A full fix for the kill_on_drop / no-wait gap requires hijacking
the child handle out of rmcp's RunningService, which means either
patching rmcp upstream or replacing the transport entirely — far
outside follow-up scope.  The contained improvement is bounding
both close paths so the daemon stops betting on the tokio reaper:

  * Explicit close (close()): wrap client.close() in a 10s
    tokio::time::timeout.  Healthy servers complete easily; a stuck
    one stops blocking hot-reload.
  * Implicit close (Drop): same 10s timeout inside the spawn so a
    wedged transport doesn't pin a tokio worker.

10s is generous enough that a normally-shutting child finishes
without a warning but tight enough that 'still running 10 seconds
after kill' is the right signal that something failed and we
should rely on OS-level reap-on-process-exit.

…all (#4045)

#3926's stderr drain loop terminated at line 101:

    while lines_read < MAX_LINES {
        match reader.next_line().await { ... lines_read += 1; ... }
    }

After the 100th line the task exits and stops reading the pipe.  Once
the kernel pipe buffer fills (64 KiB on Linux), the child's next
write(stderr) blocks forever — re-creating the exact pipe-stall
failure mode #3926 claimed to fix.  Any moderately chatty MCP server
(e.g. one that prints a banner + per-request log) hits this within
seconds.

Switch to a  that keeps reading after MAX_LINES but skips
the format/log work:

  - lines_read < MAX_LINES → format and debug! the line as before.
  - lines_read == MAX_LINES → log a single 'capped, still draining'
    notice so an operator can correlate.
  - lines_read > MAX_LINES → next_line(), discard, continue.

The pipe stays drained indefinitely.  The only break paths are now
EOF (child closed stderr) and a real I/O error (pipe unusable),
which is the only correct shutdown signal.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

…n stall

The audit of #3926 caught two real properties of the stdio shutdown
path:

  1. tokio Command's kill_on_drop(true) only sends SIGKILL — it does
     NOT call wait().  The child becomes a zombie until tokio's
     internal child reaper task runs.  If the reaper is itself
     starved (runtime spinning down) or already dropped (synchronous
     drop on a runtime that's been ejected), the zombie persists
     until the daemon process itself exits.

  2. McpConnection::close() awaits client.close() unconditionally —
     a wedged rmcp transport loop blocks the caller forever.  Hot
     reload (which awaits this) and daemon graceful shutdown both
     accumulate stalls there.

A full fix for the kill_on_drop / no-wait gap requires hijacking
the child handle out of rmcp's RunningService, which means either
patching rmcp upstream or replacing the transport entirely — far
outside follow-up scope.  The contained improvement is bounding
both close paths so the daemon stops betting on the tokio reaper:

  * Explicit close (close()): wrap client.close() in a 10s
    tokio::time::timeout.  Healthy servers complete easily; a stuck
    one stops blocking hot-reload.
  * Implicit close (Drop): same 10s timeout inside the spawn so a
    wedged transport doesn't pin a tokio worker.

10s is generous enough that a normally-shutting child finishes
without a warning but tight enough that 'still running 10 seconds
after kill' is the right signal that something failed and we
should rely on OS-level reap-on-process-exit.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…n stall

The audit of #3926 caught two real properties of the stdio shutdown
path:

  1. tokio Command's kill_on_drop(true) only sends SIGKILL — it does
     NOT call wait().  The child becomes a zombie until tokio's
     internal child reaper task runs.  If the reaper is itself
     starved (runtime spinning down) or already dropped (synchronous
     drop on a runtime that's been ejected), the zombie persists
     until the daemon process itself exits.

  2. McpConnection::close() awaits client.close() unconditionally —
     a wedged rmcp transport loop blocks the caller forever.  Hot
     reload (which awaits this) and daemon graceful shutdown both
     accumulate stalls there.

A full fix for the kill_on_drop / no-wait gap requires hijacking
the child handle out of rmcp's RunningService, which means either
patching rmcp upstream or replacing the transport entirely — far
outside follow-up scope.  The contained improvement is bounding
both close paths so the daemon stops betting on the tokio reaper:

  * Explicit close (close()): wrap client.close() in a 10s
    tokio::time::timeout.  Healthy servers complete easily; a stuck
    one stops blocking hot-reload.
  * Implicit close (Drop): same 10s timeout inside the spawn so a
    wedged transport doesn't pin a tokio worker.

10s is generous enough that a normally-shutting child finishes
without a warning but tight enough that 'still running 10 seconds
after kill' is the right signal that something failed and we
should rely on OS-level reap-on-process-exit.

…n stall (#4052)

The audit of #3926 caught two real properties of the stdio shutdown
path:

  1. tokio Command's kill_on_drop(true) only sends SIGKILL — it does
     NOT call wait().  The child becomes a zombie until tokio's
     internal child reaper task runs.  If the reaper is itself
     starved (runtime spinning down) or already dropped (synchronous
     drop on a runtime that's been ejected), the zombie persists
     until the daemon process itself exits.

  2. McpConnection::close() awaits client.close() unconditionally —
     a wedged rmcp transport loop blocks the caller forever.  Hot
     reload (which awaits this) and daemon graceful shutdown both
     accumulate stalls there.

A full fix for the kill_on_drop / no-wait gap requires hijacking
the child handle out of rmcp's RunningService, which means either
patching rmcp upstream or replacing the transport entirely — far
outside follow-up scope.  The contained improvement is bounding
both close paths so the daemon stops betting on the tokio reaper:

  * Explicit close (close()): wrap client.close() in a 10s
    tokio::time::timeout.  Healthy servers complete easily; a stuck
    one stops blocking hot-reload.
  * Implicit close (Drop): same 10s timeout inside the spawn so a
    wedged transport doesn't pin a tokio worker.

10s is generous enough that a normally-shutting child finishes
without a warning but tight enough that 'still running 10 seconds
after kill' is the right signal that something failed and we
should rely on OS-level reap-on-process-exit.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…llocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

…jection allocation) (#4051)

* fix(mcp): stream MCP response body with running cap to avoid 16 MiB allocations

read_response_bytes_capped used response.bytes().await — which
buffers the FULL body in memory before checking the cap.  A server
that omits Content-Length (chunked transfer) forces a fresh
~16 MiB allocation per request before rejection, creating real
memory pressure under concurrent abuse.  The audit of #3926
flagged this as a MEDIUM exploitation surface.

Switch to streaming via reqwest::Response::chunk() (already in the
crate's reqwest version, no extra feature flag).  Loop:

  match response.chunk().await {
      Ok(Some(chunk)) if running + chunk > cap => err and abort
      Ok(Some(chunk)) => extend buf
      Ok(None) => break
      Err(e) => err
  }

Pre-allocate Vec capacity from Content-Length when present, clamped
to MAX_RESPONSE_BYTES so a malicious large hint can't bypass the
fix.  When Content-Length is missing the Vec grows organically; the
running counter still aborts the moment the next chunk would breach
the cap.  Worst-case allocation is now MAX_RESPONSE_BYTES + 1 chunk
size, not the buffered 16 MiB ceiling regardless of Content-Length.

* fix(mcp): compare Content-Length in u64 to keep fast-path bypass closed on 32-bit

Fast-path `content_length as usize > MAX_RESPONSE_BYTES` truncates a
u64 to usize on 32-bit / wasm32 targets, so a malicious
Content-Length: 0x1_0000_0001 casts to 1 and slips past the
"no bytes read" guarantee. The streaming loop's running counter
saves us from OOM, but the fast-path semantic is lost on non-64-bit
builds (notably the wasm32 sandbox tests). Compare in u64 instead.

The `hint.min(MAX_RESPONSE_BYTES) as usize` reserve has the same
shape — clamp in u64 before the cast for the same reason.