· via dev.to (home feed)
AIClaw v3.7.21 ties temporary browser tabs to agent turns for ownership-based cleanup
AIClaw v3.7.21 gives each agent turn its own browser state and closes only the tabs that turn created, leaving user pages untouched and moving cleanup from the model to the host.

What changed
AIClaw v3.7.21, released on October 23, adds ownership-based cleanup for browser work: temporary pages now live and die with the agent execution turn that created them. According to a detailed dev.to write-up, each turn gets its own browser state, and when that turn ends the host closes the pages it created while merely releasing debugging connections to pages the user already had open.
The problem it targets is familiar to anyone running browser agents: a step can finish correctly yet leave stray search pages behind, a later run can reuse stale shared browser state, and a blunt cleanup routine risks closing a tab the user opened personally.
One browser state per turn
The desktop session manager listens for turn-started and turn-completed notifications, creating browser state on the first event and beginning cleanup on the second. Runtime exit and stop also request cleanup of any still-active turns. A turn here is one execution run within a conversation, so cleanup happens promptly instead of waiting for the conversation to be archived or deleted.
Internally, a coordinator keyed by the pair of session ID and turn ID holds a browser instance plus a set of in-flight operation promises. Creating an entry does not itself open a window; the built-in window driver opens one lazily, only when an operation needs it. That keeps concurrent runs isolated — finishing one turn removes that turn's entry rather than tearing down an application-wide browser object another run may still need.
The coordinator also handles late-arriving pages. It records each operation's promise before awaiting it, deletes the finished turn's map entry first so no new work can start for that turn, then waits for the recorded promises with Promise.allSettled before closing. The choice of allSettled is deliberate: an error while opening or navigating a page must not cause cleanup to be skipped, though closing can lag the end-of-turn event while an in-flight operation settles.
Creation defines ownership, not the tab group
AIClaw supports two browser backends, and they clean up differently. The built-in Electron browser closes the turn's own window, which is separate from the user's Chrome or Edge pages. The extension backend is finer-grained: its driver generates a random owner ID per turn and includes it when creating tabs. The extension's background script records each numeric tab ID under an agentTab key in chrome.storage.session with the owner as its value, and cleanup removes only entries matching the requested owner, detaching from any other tab without closing it.
The design explicitly refuses to treat the visible AIClaw tab group as evidence of ownership. A user page sitting in the same group must survive a cleanup sweep, and selecting an existing user tab does not turn it into a driver-created page. Session storage survives suspension or restart of the background worker, but Chrome clears it when the extension is reloaded, updated or disabled, or when the browser restarts — so these records are not a general recovery database for abandoned tabs.
Last-window and concurrency edge cases
Removing a window's final tab can close the whole window, so before closing an owned tab the extension checks its sibling tabs and, if it is the last one, first creates an about:blank replacement. That fix introduces a race of its own: with two owned tabs left, two concurrent cleanups could each see a sibling count of two and both remove a tab without leaving a blank. The extension therefore serializes cleanup requests through a promise chain, where a failed request is still reported to its caller while the queue's error handler lets later cleanups proceed. The dev.to post notes this coordinates only AIClaw's own requests, not other extensions or a user's simultaneous manual tab actions.
Testing and known limits
The author, who discloses that the post was generated by an AI agent and checked against public tagged source, reran the browser test module from the public v3.7.21 tag and reports all five Node tests passing. The ownership regression runs the real extension background script against controlled Chrome API substitutes, covering cases such as one owner's cleanup preserving another owner's tab and a user tab in the same group, a fresh worker context recovering records from session storage, harmless repeated cleanup, and concurrent final-tab removals leaving a blank tab. An Electron smoke script additionally exercises the turn coordinator with concurrent turns and failure cases, though the author inspected those checks without rerunning the suite.
Limits remain: a manually loaded extension must be reloaded to pick up the new cleanup behavior, failed cleanup is logged rather than retried, and nothing guarantees that temporary pages disappear after an application crash or when the extension is unreachable.
Why it matters
Leaked tabs and clobbered user sessions are persistent annoyances in agent-driven browser work, and v3.7.21 answers them with a clear contract: creation defines what is temporary, and a temporary page lives exactly as long as the turn that made it. Just as important, the lifecycle work now lives in the host rather than the model, so the agent no longer needs to remember cleanup as a final task step — removing a whole class of prompt-level failure. The release has since been superseded by v3.7.22, but the ownership model it introduced is the durable part of the design.
- #browser-automation
- #ai-agents
- #release-notes
- #developer-tools
- #chrome-extension