Playwright browser context lock persists on process SIGINT / tool failure, causing subsequent browser runs to fail

[ui-webharry]

Environment

• OS: Linux x64 (Ubuntu 24.04 LTS) / macOS Sonoma (Apple Silicon)
• Runtime / Binary: Standalone SEA / Node.js v20.x
• atomic-agent version:v0.4.x (main branch)
• Backend Model: Local llama.cpp (q4_k_m with TurboQuant KV-cache)

-Summary
When atomic-agent is executing a multi-step browser automation task via playwright-core and the process is unexpectedly interrupted (e.g., user sends Ctrl+C / SIGINT, or a tool invocation times out), the browser profile lock file under /browser/ is not cleaned up gracefully.

On subsequent runs, any tool call attempting to invoke browser.navigate or browser.inspect fails immediately with an unhandled rejection, as the agent assumes another browser instance is currently active.

Steps to Reproduce

1. Start an atomic-agent task requiring web browsing:

   atomic-agent run "Navigate to news.ycombinator.com and extract top 3 posts" 

[Omnivex3]

Hi👋️
Thanks for flagging this! You’ve correctly spotted an edge case in the browser profile lock lifecycle when interruptions (SIGINT, Ctrl+C, timeouts) occur.

Root Cause
Chromium creates lock files (SingletonLock, SingletonSocket, SingletonCookie, DevToolsActivePort) when launched with a persistent userDataDir. If atomic-agent is interrupted before PlaywrightBackend.shutdown() finishes, Chromium isn’t cleaned up properly, leaving stale locks in /browser/. On the next run, Chromium sees the old SingletonLock and fails to start, causing spawnChrome timeouts.

Here's what im thinking. I have a two-part solution

Pre-launch cleanup: Before starting Chromium, we now check for stale lock files and remove them if the owning PID is dead.
Signal traps: PlaywrightBackend listens for SIGINT, SIGTERM, and exit. If triggered, it kills the Chromium process tree and clears locks immediately.

Sound good?