fix(extension): release the pending agent-tab slot when tab creation fails

tool.tab_create increments pendingAgentTabCount *before* chrome.tabs.create
so the onCreated listener can tell an agent tab from a user-opened tab. When
the create failed, no onCreated event arrived and the counter leaked, so the
next tab the user opened was misclassified as agent-created — the exact
confusion the counter exists to prevent, a variant of issue #57.

handleTabCreate now releases the slot on failure via
SessionManager.releaseAgentTabPending. An abort (cancelled) is excluded: the
tab did open (and was cleaned up), so its onCreated still consumes the slot.

Added a regression test asserting that after a failed tab_create, a
user-opened tab is still classified as 'user' (not 'agent').
This commit is contained in:
iAstro
2026-09-01 15:36:44 +08:00
parent a4fed136e3
commit 91621b2545
3 changed files with 40 additions and 1 deletions
+11 -1
View File
@@ -431,7 +431,17 @@ export async function handleTabCreate(
manager.markAgentTabPending(ctx.agentWindowId);
const tab = await createTabAndCleanup(deps, buildCreateProps(ctx, params));
if (isRpcError(tab)) return tab;
if (isRpcError(tab)) {
// Release the pending slot when no tab was actually opened: with no
// `onCreated` event to consume it, the counter would leak and the next
// tab the user opens would be misclassified as agent-created. An abort
// (`cancelled`) is the exception — the tab did open (and was cleaned up),
// so its `onCreated` still consumes the slot.
if (tab.code !== "cancelled") {
manager.releaseAgentTabPending(ctx.agentWindowId);
}
return tab;
}
// Track agent-created tabs so session_stop can clean them up (design §3.1).
// The onCreated listener also adds this id; this is an idempotent fallback