🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🔵 AbortSignal listener leak and ignored pre-aborted signal in runCronIsolatedAgentTurn attempt runner

Description

In runCronIsolatedAgentTurn, the per-attempt abort forwarding registers an abort event listener on the outer abortSignal, but the listener cleanup is not guaranteed on all exit paths.

Impacts:

• Listener leak / retained closures: If the attempt exits via an exception/rejection (e.g., runEmbeddedPiAgent(...) throws) or via the runCliAgent(...) early-return path, the abort listener is never removed. Over multiple model fallback attempts and/or multiple prompts within the same cron run, this can accumulate listeners and retain AbortController/closure objects.
• DoS / resource overuse risk: runWithModelFallback can invoke run(...) multiple times (per candidate model). Repeated failing attempts can therefore register multiple listeners without cleanup, growing memory use and adding abort propagation overhead.
• Cancellation bypass (functional/security impact): The previous code threw immediately when abortSignal.aborted was already true. The new code skips listener registration when already aborted, but also does not abort the per-attempt controller; the attempt proceeds with a non-aborted attemptSignal, potentially continuing expensive work after the job timed out/canceled.

Vulnerable code (listener added, but removed only on one successful path):

const attemptController = new AbortController();
const attemptSignal = attemptController.signal;
const forwardAbort = () => attemptController.abort(abortSignal?.reason);
if (abortSignal && !abortSignal.aborted) {
  abortSignal.addEventListener("abort", forwardAbort, { once: true });
}
...
if (isCliProvider(providerOverride, cfgWithAgentDefaults)) {
  const result = await runCliAgent({ ... });
  ...
  return result; // <- listener is never removed
}
const result = await runEmbeddedPiAgent({ ..., abortSignal: attemptSignal, ... });
...
abortSignal?.removeEventListener("abort", forwardAbort);
return result;

Why this can repeat:

• runWithModelFallback loops through fallback candidates and calls params.run(...) for each attempt until one succeeds or all fail, so the above run callback may execute multiple times per cron turn.

Recommendation

Ensure listener cleanup and correct abort propagation on all exit paths by using try/finally, and immediately abort the per-attempt controller when the outer signal is already aborted.

Suggested pattern:

const attemptController = new AbortController();
const attemptSignal = attemptController.signal;
const forwardAbort = () => attemptController.abort(abortSignal?.reason);

if (abortSignal?.aborted) {
  attemptController.abort(abortSignal.reason);
} else if (abortSignal) {
  abortSignal.addEventListener("abort", forwardAbort, { once: true });
}

try {
  if (isCliProvider(providerOverride, cfgWithAgentDefaults)) {
    return await runCliAgent({ /* ... */ });
  }

  const result = await runEmbeddedPiAgent({
    ​/* ... */
    abortSignal: attemptSignal,
  });
  return result;
} finally {
  abortSignal?.removeEventListener("abort", forwardAbort);
}

This guarantees:

• no leaked listeners on exceptions or early returns
• per-attempt signal is aborted immediately if the outer job was already canceled/timed out

Analyzed PR: #38149 at commit b02874f

_{Last updated on: 2026-03-06T17:02:08Z}

Greptile Summary

This PR correctly fixes a bug where the shared AbortController used by the cron timeout would abort the first model attempt and immediately fail all subsequent fallback attempts.

The fix: Creates a fresh AbortController per runWithModelFallback attempt with addEventListener("abort", ..., { once: true }) to forward the outer signal's abort event. This allows fallback models to start with a clean, non-aborted signal while remaining cancellable by the outer timeout.

Why it works: Each attempt gets its own controller. When the outer signal aborts, the { once: true } listener fires once and self-removes, forwarding the abort to the current attempt's controller. The loop in runWithModelFallback then proceeds to the next fallback with a new controller.

Tests: Well-structured coverage of signal isolation (confirms per-attempt controller is not the outer signal) and abort forwarding behavior.

Confidence Score: 5/5

• The fix correctly implements per-attempt abort controllers that preserve fallback chain functionality under timeout.
• The core fix is sound: fresh AbortController per attempt with proper signal forwarding ensures fallback attempts start with non-aborted signals while remaining cancellable by the outer timeout. Listener cleanup via { once: true } is sufficient for the job-scoped lifetime. Tests validate signal isolation and forwarding behavior. No functional issues identified.
• No files require special attention

_{Last reviewed commit: b02874f}