Is your feature request related to a problem? Please describe.
Feature Request
Summary
Add support for opening incognito (private) browser windows via the new_page tool,
either as a parameter (incognito: true) or via a dedicated tool.
Describe the solution you'd like
Proposed Solution
- Add an
incognito: boolean parameter to new_page
- Or a
--incognito CLI flag that launches Chrome in incognito mode by default
- Alternatively, support launching a second Chrome instance via
--browser-url with
a user-data-dir that has no cached NTLM tokens
Describe alternatives you've considered
Motivation
The current isolatedContext parameter creates isolated browser contexts within the
same Chrome process, which is useful for cookie/storage isolation. However, it does not
help when testing applications that use Windows Integrated Authentication (NTLM/Kerberos).
In Windows Auth applications, credentials are resolved at the OS level (SSPI), so
isolated contexts still pass through the same Windows identity. A true incognito window
(separate process, separate credential cache) would allow agents to test the app as
a different Windows user — extremely useful in Windows Authentication Applications.
Additional context
Use Case
Testing role-based access control in ASP.NET Core Blazor Server apps with Windows
Authentication, where different AD group memberships result in different UI behavior.
Currently impossible to test multiple user roles via DT-MCP in the same session.
Is your feature request related to a problem? Please describe.
Feature Request
Summary
Add support for opening incognito (private) browser windows via the
new_pagetool,either as a parameter (
incognito: true) or via a dedicated tool.Describe the solution you'd like
Proposed Solution
incognito: booleanparameter tonew_page--incognitoCLI flag that launches Chrome in incognito mode by default--browser-urlwitha user-data-dir that has no cached NTLM tokens
Describe alternatives you've considered
Motivation
The current
isolatedContextparameter creates isolated browser contexts within thesame Chrome process, which is useful for cookie/storage isolation. However, it does not
help when testing applications that use Windows Integrated Authentication (NTLM/Kerberos).
In Windows Auth applications, credentials are resolved at the OS level (SSPI), so
isolated contexts still pass through the same Windows identity. A true incognito window
(separate process, separate credential cache) would allow agents to test the app as
a different Windows user — extremely useful in Windows Authentication Applications.
Additional context
Use Case
Testing role-based access control in ASP.NET Core Blazor Server apps with Windows
Authentication, where different AD group memberships result in different UI behavior.
Currently impossible to test multiple user roles via DT-MCP in the same session.