Agent stuck in infinite scroll retry loop after session.close — no circuit breaker on repeated errors

[dimdasci]

Summary

A pi sub-agent entered an infinite retry loop sending scroll commands to a closed session. The daemon correctly returned SESSION_NOT_FOUND on every request, but the agent never broke out of the loop. Result: 608,970 failed scroll commands over 17 hours at ~10 req/s, bloating the log to 235 MB.

Reproduction

1. Agent opens a session, navigates to a LinkedIn page, begins scrolling
2. Session is closed (via session.close or externally)
3. Agent continues issuing bproxy scroll -s <dead-session> in a tight loop
4. Every command returns {"ok": false, "error_code": "SESSION_NOT_FOUND"}
5. Agent never stops

Evidence from logs

# Session closed at 01:42
{"time":1781826140544,"action":"session.close","session":"6afr3v","event":"received"}

# Scrolls continue immediately after, every ~100ms
{"time":1781826141514,"action":"scroll","session":"6afr3v","event":"received"}
{"time":1781826141515,"event":"response","ok":false,"elapsed_ms":0,"error_code":"SESSION_NOT_FOUND"}
{"time":1781826141614,"action":"scroll","session":"6afr3v","event":"received"}
{"time":1781826141614,"event":"response","ok":false,"elapsed_ms":0,"error_code":"SESSION_NOT_FOUND"}
...
# Still going 17 hours later at 18:51
{"time":1781887876856,"action":"scroll","session":"6afr3v","event":"received"}
{"time":1781887876856,"event":"response","ok":false,"elapsed_ms":0,"error_code":"SESSION_NOT_FOUND"}

Impact

• 608,970 wasted requests logged in 17 hours
• Log file grew to 235 MB (1.2M lines), dominated by this single session

Proposed fix

The issue is on the client (CLI) side, not the daemon. The daemon behaves correctly (returns errors). The CLI should implement:

1. Circuit breaker: If N consecutive commands to the same session return the same error (e.g., 3x SESSION_NOT_FOUND), the CLI should exit with a non-zero code and a clear message like "Session terminated — aborting" rather than returning the error to the caller in a way that allows silent retry.

2. Rate limiting on errors: If the CLI receives errors at >1/s from the same session, introduce exponential backoff or hard-stop after a threshold.

3. Session liveness check: Before executing a destructive action, optionally verify the session still exists (cheap tab list or internal state check).

Environment

• bproxy v0.7.4
• macOS, Chrome extension paired
• Agent: pi with Haiku model (sub-agent in pipe mode)

Workaround

Manual kill <pid> on the stuck agent process.

[dimdasci]

Additional request:

• Activity rate cap (e.g., max N navigations per minute, enforced at daemon level)
• Timing variance injection (add random jitter to command execution so even autonomous agents don't produce metronome patterns)

[dimdasci]

Root Cause Analysis

The chain of events

1. Agent sends bproxy scroll -s 6afr3v after the session was closed
2. CLI does its one-shot job correctly: POST → daemon → SESSION_NOT_FOUND → exit code 1 + error JSON on stdout
3. The calling agent (pi sub-agent in pipe mode) sees exit 1 + error response, but does not interpret SESSION_NOT_FOUND as terminal — it retries immediately
4. The daemon processes each request at ~0ms (session lookup fails instantly, no pacing applied), enabling ~10 req/s throughput

Why it happens — three contributing factors

1. CLI is stateless by design (primary architectural constraint)

The CLI is explicitly one-shot: one command → one POST → one JSON → exit. It has no cross-invocation state and therefore cannot implement a circuit breaker or track consecutive failures. This is not a bug — it's ADR-004 + the architecture's "CLI = one shot" invariant.

A CLI-side circuit breaker would require either:

• A state file in BPROXY_HOME tracking recent errors per session (adds complexity, race conditions, staleness)
• Changing the CLI from stateless to session-aware (violates the architectural boundary)

2. Pacing is bypassed for early-rejected requests

Looking at service/src/routes/command.ts line 112: pacing (waitForSlot) runs after validateSession(). When validateSession returns SESSION_NOT_FOUND, the response is logged and returned immediately — the pacing engine is never invoked. This means dead-session requests cost ~0ms each with no rate limiting whatsoever.

validateSession → SESSION_NOT_FOUND → logResponse → return (0ms)
                   ↑ pacing never reached

3. retry: "conditional" is ambiguous for dead sessions

Per ADR-023, SESSION_NOT_FOUND carries retry: "conditional". This is architecturally correct (the session might not exist because you haven't created it yet, or because someone else closed it and you should create a new one). But from the agent's perspective, retrying the same closed session ID is always futile — the ID will never come back. The error response doesn't distinguish "session was explicitly closed" from "session never existed."

---

Blast Radius

Direct impact (observed)

• Log pollution: 235 MB / 1.2M lines from a single stuck agent over 17 hours
• Daemon CPU/IO: ~10 JSON parses + session lookups + structured log writes per second (low per-request cost, but sustained for 17h)
• No cascading failure: other sessions, the extension, and Chrome itself are unaffected — the daemon handles each request independently

Potential escalation scenarios

Scenario	Risk	Likelihood
Multiple stuck agents on different dead sessions	Log grows linearly per agent; disk fill possible	Medium (multi-agent workflows)
Stuck agent saturating the HTTP listener	Unlikely at 10 req/s; Fastify handles thousands/s	Low
Log rotation/monitoring alerting on volume	Ops noise; false positive alerts	High if monitoring exists
Agent token/API cost (if agent is LLM-backed)	Each retry iteration costs inference tokens even though the tool call is trivial	High — this was a Haiku sub-agent running 17h
Daemon memory growth from trace ring buffer	Ring buffer is bounded (capacity 200 per debug.last), so no growth	None

What is NOT affected

• Extension stability (no WS messages sent for dead-session requests)
• Other active sessions (session isolation is correct)
• Daemon crash risk (the daemon is robust; it just logs honestly)
• Security (no auth bypass, no token exposure)

---

Proposed Fix Layers

Given the constraints (CLI must stay one-shot, daemon must stay honest), the fix belongs in daemon-side defense-in-depth rather than CLI-side state:

Layer 1: Daemon error-path rate limiting (primary fix)

Add a per-session error throttle in the command route. If the same {session, error_code} pair has been returned N times within a window (e.g., 5 times in 10s), start injecting a short delay (e.g., 1s → 2s → 4s exponential backoff, capped at 30s) before responding. This:

• Does not change the protocol contract (same response shape)
• Does not require CLI state
• Caps the damage from any tight-loop caller
• Is analogous to the existing /pair/claim rate limiter

Layer 2: Enrich SESSION_NOT_FOUND with suggestedAction

Add suggestedAction: "Session is permanently closed. Create a new session with 'bproxy session create' or 'bproxy tab open --url ...'" to the error response. Well-behaved agents that read suggestedAction will break the loop.

Layer 3: retry: "never" when session was explicitly closed (stretch)

Track recently-closed session IDs briefly in the daemon (bounded set, short TTL). If a request targets a known-closed session, return retry: "never" instead of retry: "conditional". This gives agents a definitive "stop" signal. Requires ADR-023 amendment or clarification.

Layer 4: Activity rate cap (from your additional comment)

Global or per-session max requests/minute at the daemon level, independent of error state. Catches not just dead-session loops but any pathological agent behavior. This is the broadest defense.

---

Files likely touched

Layer	Component	Files
1	service	service/src/routes/command.ts, new service/src/error-throttle.ts
2	service	service/src/dispatch.ts, service/src/routes/session-actions.ts
3	service + shared	service/src/sessions.ts, shared/src/errors.ts (RetryHint semantics)
4	service	service/src/routes/command.ts, service/src/pacing.ts or new module