---
id: "34c187ca-6d9c-4a04-a2f0-1687228ea778"
name: "Incognito Tab Creation"
micro_summary: "Keeps new tabs inside an existing incognito context rather than accidentally opening a normal-context tab."
status: "resolved"
see_also: []
scope: "How browser-harness creates a sibling tab in an existing Chrome incognito context without changing the user's active tab."
warnings: "Do not use normal `new_tab()` when preserving a manually opened incognito context matters; verify the resulting target's context. Protect the active tab by default; any human-authorized exception follows the tab workflow loaded at entry."
---
## Verified path

`list_tabs()` found the existing `incognito - Google Search` page. Raw CDP target inspection identified its browser context.

Direct `Target.createTarget` using that reported context failed: Chrome rejected the context as unavailable for target creation.

Script-only `window.open('about:blank', '_blank')` also failed: it returned null and created no target because the popup lacked browser user activation.

The working path was a temporary blank `<a target="_blank">` element in the incognito page, followed by CDP mouse press/release events. Chrome created an `about:blank` sibling page whose `openerId` and `browserContextId` proved it belonged to the same incognito context. The temporary element was removed afterward.

The browser-harness daemon was reset to clear temporary CDP attachments; macOS remote-debugging approval was then completed, and verification showed both tabs present and unattached.

Evidence boundary: this is verified in one local Chrome run. It proves same-context sibling creation, not cloud-daemon or cross-platform behavior.