Browser Use Version
0.12.2
Bug Description, Steps to Reproduce, Screenshots
Title
Agent.close() with keep_alive=True drops CDP WebSocket connections, triggering unnecessary reconnection cycle
Body
Context
We maintain a pool of pre-authenticated browsers using Browser(keep_alive=True). At startup, a lightweight agent logs each browser into our target application, then the browser sits idle in the pool until a real task arrives. This avoids repeating login for every task and lets us reuse authenticated sessions across sequential agent runs.
Bug Description
When Agent.close() completes with keep_alive=True, all CDP WebSocket connections are dropped. In 0.12.2, the built-in reconnection logic recovers (after ~1.7s), but this is unnecessary overhead — the connections shouldn't be dropped in the first place when the intent is to keep the browser alive.
Observed Behavior (0.12.2)
Immediately after warmup agent completes on a keep_alive=True browser:
WARNING [BrowserSession] CDP WebSocket message handler exited unexpectedly (connection closed)
WARNING [BrowserSession] CDP WebSocket message handler exited unexpectedly (connection closed)
WARNING [BrowserSession] CDP WebSocket message handler exited unexpectedly (connection closed)
WARNING [BrowserSession] WebSocket reconnection attempt 1/3...
INFO [BrowserSession] [SessionManager] Cleared all owned data (targets, sessions, mappings)
WARNING [BrowserSession] WebSocket reconnection attempt 1/3...
INFO [BrowserSession] [SessionManager] Cleared all owned data (targets, sessions, mappings)
...
INFO [BrowserSession] WebSocket reconnected after 1.7s (attempt 1)
INFO [BrowserSession] WebSocket reconnected after 1.7s (attempt 1)
This happens for every Agent.close() on a keep_alive=True browser — multiple WebSocket handlers all disconnect and reconnect, clearing session manager data each time.
Expected Behavior
With keep_alive=True, Agent.close() should preserve the CDP WebSocket connections and session state. The browser should remain fully connected and ready for the next Agent.run() without any disconnection/reconnection cycle.
Impact
- ~1.7s recovery delay after every agent run before the browser is usable again
- Session manager data cleared on each reconnection ("Cleared all owned data (targets, sessions, mappings)")
- In pre-0.12.x (which lacked WebSocket reconnection), this same issue caused permanent CDP connection collapse — the browser became unusable after the first agent completed
- Multiple reconnection warnings per browser pollute logs in pooled setups
Reproduction
from browser_use import Agent, Browser
browser = Browser(keep_alive=True)
# First agent — e.g. a login warmup
agent1 = Agent(task="Navigate to example.com", browser=browser, llm=llm)
await agent1.run()
# Immediately after: CDP WebSocket handlers exit, reconnection cycle begins
# Browser recovers after ~1.7s, but all session data was cleared
Root Cause (from investigation)
In agent/service.py, Agent.close() with keep_alive=True tears down the event bus, which appears to cascade into closing CDP WebSocket connections. The 0.12.2 reconnection logic masks the issue but doesn't prevent the unnecessary disconnect.
Environment
- browser-use: 0.12.2
- Python: 3.13
- OS: Cloud Foundry (Linux) with Browserless container via CDP
- Setup: Pool of 3-5
Browser(keep_alive=True) instances, each warmed up by a login agent, then reused for sequential tasks
Failing Python Code
from browser_use import Agent, Browser
browser = Browser(keep_alive=True)
# First agent — e.g. a login warmup
agent1 = Agent(task="Navigate to example.com", browser=browser, llm=llm)
await agent1.run()
# Immediately after: CDP WebSocket handlers exit, reconnection cycle begins
# Browser recovers after ~1.7s, but all session data was cleared
LLM Model
No response
Operating System & Browser Versions
No response
Full DEBUG Log Output
The relevant section is:
WARNING [BrowserSession] CDP WebSocket message handler exited unexpectedly (connection closed)
WARNING [BrowserSession] CDP WebSocket message handler exited unexpectedly (connection closed)
WARNING [BrowserSession] CDP WebSocket message handler exited unexpectedly (connection closed)
WARNING [BrowserSession] WebSocket reconnection attempt 1/3...
INFO [BrowserSession] [SessionManager] Cleared all owned data (targets, sessions, mappings)
WARNING [BrowserSession] WebSocket reconnection attempt 1/3...
INFO [BrowserSession] [SessionManager] Cleared all owned data (targets, sessions, mappings)
...
INFO [BrowserSession] WebSocket reconnected after 1.7s (attempt 1)
INFO [BrowserSession] WebSocket reconnected after 1.7s (attempt 1)
Browser Use Version
0.12.2
Bug Description, Steps to Reproduce, Screenshots
Title
Agent.close()withkeep_alive=Truedrops CDP WebSocket connections, triggering unnecessary reconnection cycleBody
Context
We maintain a pool of pre-authenticated browsers using
Browser(keep_alive=True). At startup, a lightweight agent logs each browser into our target application, then the browser sits idle in the pool until a real task arrives. This avoids repeating login for every task and lets us reuse authenticated sessions across sequential agent runs.Bug Description
When
Agent.close()completes withkeep_alive=True, all CDP WebSocket connections are dropped. In 0.12.2, the built-in reconnection logic recovers (after ~1.7s), but this is unnecessary overhead — the connections shouldn't be dropped in the first place when the intent is to keep the browser alive.Observed Behavior (0.12.2)
Immediately after warmup agent completes on a
keep_alive=Truebrowser:This happens for every
Agent.close()on akeep_alive=Truebrowser — multiple WebSocket handlers all disconnect and reconnect, clearing session manager data each time.Expected Behavior
With
keep_alive=True,Agent.close()should preserve the CDP WebSocket connections and session state. The browser should remain fully connected and ready for the nextAgent.run()without any disconnection/reconnection cycle.Impact
Reproduction
Root Cause (from investigation)
In
agent/service.py,Agent.close()withkeep_alive=Truetears down the event bus, which appears to cascade into closing CDP WebSocket connections. The 0.12.2 reconnection logic masks the issue but doesn't prevent the unnecessary disconnect.Environment
Browser(keep_alive=True)instances, each warmed up by a login agent, then reused for sequential tasksFailing Python Code
LLM Model
No response
Operating System & Browser Versions
No response
Full DEBUG Log Output