Tab reports "Another debugger is already attached" after a navigate; tabs_close / tabs_list time out #17

Summary

Once a tab has been driven (screenshot / navigate / javascript_execute), later calls against that same tab intermittently fail with either "Another debugger is already attached to the tab with id: N" or a timeout ("TaskWindow extension did not answer within 10s/30s"). A fresh tabs_create works once, then that tab shows the same behaviour after its first navigate. Over a long session this forces one new tab per interaction and leaves the tab strip full of one-tab groups.

Environment

• Extension 0.2.4, macOS (Darwin 25.5.0), Chrome
• Called over MCP (mcp__taskwindow__*) from an MCP client; single sessionToken for the whole session
• Target pages: http://localhost:5173/* (Vite dev server) and https://app.attio.com/*

Reproduction

1. tabs_create → tab A
2. computer { action: "screenshot" } on A → OK
3. navigate A to another URL on the same origin → OK
4. computer { action: "screenshot" } on A → "Another debugger is already attached to the tab with id: A"
5. tabs_create → tab B; screenshot OK; navigate B; screenshot → same error on B

Also observed, same session:

• tabs_close on a tab in this state times out (10s) but the tab sometimes closes anyway
• tabs_list itself timing out (10s)
• one "TaskWindow extension is not connected" between otherwise-working calls, with the options page reporting Connected

Expected

A tab the session created should stay drivable across navigations; tabs_close should either close it or return an error, not time out.

Guess at the cause

Looks like the CDP Debugger.attach for a tab is not released (or is re-acquired) around navigate, so the second attach sees the first still held. The timeouts on tabs_list / tabs_close suggest the same held attachment blocks the message loop.

Workaround

Create a new tab for each interaction. Works, but every tabs_create with a new task name makes a new tab group, which is how the strip ends up as seven one-tab groups.