Playwright MCP browser context is lost after 8-12 minutes of idle time.

An 8-12 minute pattern sounds more like a connection, relay, or Azure Container Apps lifecycle timeout than a normal Playwright browser-context timeout. A Playwright context does not normally disappear simply because no browser actions were sent for a few minutes. However, once the CDP connection or the MCP server process is lost, the server-side Playwright objects are no longer valid, even if the user's Chrome window and tab are still open.

Start with Azure Container Apps. Set the MCP relay to keep at least one replica running, so it does not scale to zero while the agent is idle. Then check the container logs at the time of failure. Log three simple events: when the extension connects, when it disconnects, and when the MCP server process starts or stops. This will show whether the problem is the browser connection, the relay, or a container restart.

Next, make sure the extension uses a real persistent connection, such as WebSocket, rather than depending only on normal HTTP webhook calls. Send a small ping message every 30-60 seconds and have the extension reply with pong. If several pings are missed, reconnect the extension automatically. The ping should only prove that the connection is alive; it should not open pages, click anything, or otherwise affect the user's browser.

The recovery logic should reconnect before it closes anything. Keep a record of the logical session ID and the Chrome tab ID when the session begins. After a disconnect, ask the extension whether that tab still exists. If it does, reconnect to the same running browser and attach to that tab again. Only call browser_close when the extension confirms that the browser or tab has actually gone away. This preserves the open page and, in most cases, the existing login session.

Finally, test the setup deliberately: leave the agent idle for 15, 30, and 60 minutes, then send one harmless request each time. Compare the relay logs, Azure Container Apps events, and extension logs. That should identify the layer that is ending the session before adding more retry logic.

It sounds like your browser context is getting dropped because something in the chain goes idle, most likely the CDP connection from the extension back to your MCP server. Playwright itself doesn’t enforce an 8-12 minute timeout, so this is probably a transport or container‑level idle limit. I’d look at keep‑alive or heartbeat messages from the extension to prevent the connection from being reclaimed. Some people solve this by periodically pinging the active context or re‑establishing the CDP session instead of creating a new browser. Checking Azure Container Apps’ idle timeout settings might also point you in the right direction.

hi shobhit-vishwakarma​ Given the architecture, I wouldn't immediately assume that Playwright itself is closing the browser context. The 8-12 minute window makes me suspect a timeout somewhere in the connection chain, especially with Azure Container Apps and the long-lived connection between your MCP server and the Chrome extension.

I'd investigate the issue layer by layer:

• Check Azure Container Apps logs around the exact time the context is lost.
• Verify whether the MCP server process/container is being restarted or scaled down.
• Check whether the webhook/HTTP connection between the extension and MCP relay has an idle timeout.
• Confirm whether the CDP connection is still alive after the idle period.
• Check Playwright MCP logs to determine whether the browser context actually disappeared or whether the MCP server simply lost its reference to it.

I would also avoid automatically calling browser_close and creating a new session as the first recovery action. If the browser is still running locally, try implementing a reconnect/recovery mechanism first. The MCP server could periodically check the connection or re-establish communication with the existing browser before deciding that the context is genuinely gone.

A heartbeat or lightweight keep-alive may help if the issue is caused by an idle network connection, but I'd first identify exactly which component is timing out. Otherwise, you could end up masking the underlying problem.

One other thing I'd consider is session state management. For a production system, I'd treat the browser context as a separate long-lived resource and maintain a session ID/state mapping on the server side. If the MCP connection drops, the agent should attempt to reconnect to the existing session rather than assuming the browser context has been destroyed.

The fact that this happens consistently after roughly 8-12 minutes is a useful clue. I'd focus on finding which component has a timeout in that range. Once you know whether it's Azure Container Apps, the webhook connection, the CDP channel, or Playwright MCP itself, the solution should become much clearer.