[Critical] Division by zero when effectiveMemoryLimit is 0.

heapSizeLimit on the next line has an explicit > 0 guard, but effectiveMemoryLimit does not. If os.totalmem() returns 0 (possible in some containerized or unusual environments) and both cgroup reads return undefined, then computeEffectiveMemoryLimit() returns 0. This makes rssRatio = Infinity, which always evaluates to 'critical' — causing the monitor to aggressively clear FileReadCache every cleanupCooldownMs (default 5 s), degrading performance with no diagnostic output explaining why.

— qwen-latest-series-invite-beta-v36 via Qwen Code /review

[Suggestion] The memory-cleanup-ineffective event fires only at exactly === 3, never again. By contrast, recordCleanupFailure (line 320) uses >= 3 and keeps emitting on every subsequent failure. If cleanup remains ineffective for 10+ consecutive cycles, only the 3rd emits an event — cycles 4, 5, … are silent. Downstream consumers lose visibility into ongoing memory pressure after the initial alert.

Consider changing to >= 3 to match the failure-path pattern, or emit at periodic thresholds (3, 6, 12…) to limit noise while maintaining visibility:

— qwen-latest-series-invite-beta-v36 via Qwen Code /review

[Suggestion] All cgroup read errors are silently swallowed — permission denied, corrupt file content, unexpected format all fall back to hostTotal with no log. If a container has a misconfigured memory limit, the monitor falls back to the host total (potentially much larger), never triggers cleanup, and the container gets OOM-killed while the monitor logs show "normal pressure."

Consider adding a debugLogger.warn(...) when returning undefined for unexpected values, including the file path and raw content:

— qwen-latest-series-invite-beta-v36 via Qwen Code /review

[Suggestion] When enableExplicitGC is true (via QWEN_MEMORY_ENABLE_GC=1) but the process wasn't started with --expose-gc, this step silently no-ops with no log or warning. An operator debugging critical-level OOM could see enableExplicitGC=true in config and assume GC is running when it isn't.

— qwen-latest-series-invite-beta-v36 via Qwen Code /review

[Critical] Queued cleanup recommendation can be silently downgraded by a lower-ranked arrival.

The comparison on line 248 checks recommendation.action > this.activeCleanupAction but does NOT compare against the already-queued this.queuedCleanupRecommendation. Consider this sequence:

1. aggressive (rank 3) cleanup starts → activeCleanupAction = 'aggressive'
2. Between await Promise.resolve() boundaries, light (rank 1) arrives → 1 > 3 is false → skipped ✅

But:

1. light (rank 1) cleanup starts → activeCleanupAction = 'light'
2. aggressive (rank 3) arrives → 3 > 1 is true → queued ✅
3. moderate (rank 2) arrives → 2 > 1 is true → overwrites the queued aggressive with moderate ❌

The most aggressive needed cleanup is silently replaced by a weaker one.

— qwen3.7-max via Qwen Code /review

[Critical] heapSizeLimit is cached once at construction and never refreshed.

V8 dynamically adjusts heap_size_limit over the lifetime of a long-running session (e.g., on a 16 GB machine the initial limit might be ~1.5 GB, growing to 4+ GB as the old generation expands). A stale, too-small denominator inflates heapRatio = mem.heapUsed / this.heapSizeLimit, causing early critical cleanup — even when V8 could grow the heap much further before actually running out. Since ratio = Math.max(rssRatio, heapRatio), the stale heap ratio becomes the dominant signal.

getHeapStatistics() is a cheap V8 intrinsic (no I/O, no GC trigger). Refresh on each call:

Then in getPressureLevel():

const heapStats = getHeapStatistics();
const heapRatio = heapStats.heap_size_limit > 0
  ? mem.heapUsed / heapStats.heap_size_limit : 0;

— qwen3.7-max via Qwen Code /review

[Critical] Comment and code contradict each other — RSS measurement drives failure detection.

The comment on lines 268–269 says: "RSS can lag behind object graph cleanup, so this is diagnostic logging only and does not drive failure detection."

This is factually wrong: logCleanupResult (invoked via setImmediate using the memAfter captured on line 267) increments consecutiveIneffectiveCleanups and emits memory-cleanup-ineffective events when freedRatio < 0.01. The measurement directly drives both counter state and user-visible events.

Additionally, memAfter is captured in .then() before setImmediate fires — but in the default path (enableExplicitGC: false), cleanup only drops FileReadCache Map references. V8 has not yet GC'd the orphaned entries, so RSS is essentially unchanged and freedRatio < 0.01 fires on virtually every cleanup, generating false memory-cleanup-ineffective events.

Move the RSS measurement inside setImmediate so it benefits from the deferred timing:

— qwen3.7-max via Qwen Code /review

[Critical] No lower bound on cgroup memory limit — a value of "1" (1 byte) passes all validation checks.

A cgroup value like "1" passes Number.isFinite, > 0, Number.isSafeInteger, and <= hostTotal — producing rssRatio = rss / 1 which is astronomically high (~10 billion), triggering aggressive cleanup after every single tool execution. If enableExplicitGC is on with --expose-gc, this becomes a synchronous GC after every tool call — complete denial of service.

No realistic container/VM has a memory limit below a few hundred MB. Add a sensible floor:

— qwen3.7-max via Qwen Code /review

[Suggestion] Cooldown blocking branch has no test verifying it actually blocks.

All tests that set cleanupCooldownMs to a nonzero value (e.g., 60000) exercise the isEscalation bypass branch — they never test that a same-level or lower-level cleanup is actually suppressed within the cooldown window. All other tests set cleanupCooldownMs: 0, making the guard always pass.

The cooldown is the primary throttling mechanism. If the comparison logic were inverted, the test suite would not detect it. Consider adding:

it('blocks same-level cleanup within the cooldown window', async () => {
  const evictSpy = vi.fn().mockReturnValue(0);
  const monitor = new MemoryPressureMonitor(
    createMockConfig({ fileReadCache: { evictNotAccessedSince: evictSpy } }),
    { ...DEFAULT_PRESSURE_CONFIG, cleanupCooldownMs: 60_000 },
  );
  setMemUsage(9 * 1024 * 1024 * 1024); // soft pressure
  monitor.performCheck();
  await drainCleanupMeasurement();
  expect(evictSpy).toHaveBeenCalledTimes(1);

  // Second check at same level within cooldown → should be a no-op
  monitor.performCheck();
  await drainCleanupMeasurement();
  expect(evictSpy).toHaveBeenCalledTimes(1); // still 1
});

— qwen3.7-max via Qwen Code /review

[Suggestion] The consecutiveIneffectiveCleanups = 0 reset on the effective-cleanup branch is untested.

Tests verify the counter increments (when RSS drops < 1%) and can be reset via the public resetConsecutiveFailures(). But no test verifies that an effective cleanup (RSS drops ≥ 1%) automatically resets the counter. If this line were accidentally removed, the monitor would emit spurious memory-cleanup-ineffective events after just 3 total ineffective cleanups spread across effective ones — breaking the consecutive-invariant.

Consider adding a test that interleaves effective and ineffective cleanups and asserts the counter resets.

— qwen3.7-max via Qwen Code /review

[Suggestion] The consecutiveCleanupFailures = 0 auto-reset after successful cleanup is untested in a failure-then-success scenario.

Tests verify failure counting and the public resetConsecutiveFailures() method, but no test runs failures followed by a successful cleanup and asserts the counter returns to zero. If this reset were removed, the counter would monotonically increase, eventually emitting memory-cleanup-failed events even after recovery.

Consider adding:

it('resets consecutive failures after a successful cleanup', async () => {
  const evictSpy = vi.fn().mockImplementation(() => { throw new Error('fail'); });
  const monitor = new MemoryPressureMonitor(
    createMockConfig({ fileReadCache: { evictNotAccessedSince: evictSpy } }),
    { ...DEFAULT_PRESSURE_CONFIG, cleanupCooldownMs: 0 },
  );
  setMemUsage(9 * 1024 * 1024 * 1024);
  monitor.performCheck();
  await drainCleanupMeasurement();
  expect(monitor.getConsecutiveFailures()).toBe(1);

  evictSpy.mockReturnValue(0); // now succeed
  monitor.performCheck();
  await drainCleanupMeasurement();
  expect(monitor.getConsecutiveFailures()).toBe(0);
});

— qwen3.7-max via Qwen Code /review

[Critical] resetConsecutiveFailures() only resets counters — it does not cancel in-flight cleanup. startNewSession() (config.ts:1928-1929) calls getFileReadCache().clear() then resetConsecutiveFailures(), but if cleanup is in-flight at that moment, the async resolution (.then → setImmediate → clear_file_cache) fires against the FileReadCache after startNewSession has cleared it and the new session may have started re-populating it.

The same applies to a queued escalation in queuedCleanupRecommendation — it is drained by finishCleanupAndRunQueued after the session boundary.

A generation counter (bumped here, checked in the .then/setImmediate chain) would be more robust if simply resetting state has side effects on the currently-running runCleanupSteps promise.

— qwen3.7-max via Qwen Code /review

[Suggestion] No adaptive backoff when cleanup is repeatedly ineffective. When freedRatio < 0.01 under critical pressure, this counter increments and shouldEmitRepeatedDiagnostic throttles the event — but the next performCheckInternal still triggers executeCleanup({ action: 'aggressive', steps: ['clear_file_cache', 'trigger_gc'] }) at full cooldown cadence (5 s).

If memory pressure comes from non-cache sources (chat history accumulation, native allocations), every 5-second cycle runs a stop-the-world global.gc() (if enabled) plus a full cache clear — neither of which helps — degrading responsiveness without reducing RSS. The memory-cleanup-ineffective event is fire-and-forget; nothing subscribes with corrective action.

Consider applying exponential backoff when consecutiveIneffectiveCleanups exceeds a threshold (e.g., cleanupCooldownMs * min(2^k, 64)) or temporarily suspending the aggressive tier until pressure drops below hardPressureRatio.

— qwen3.7-max via Qwen Code /review