How to launch Cypress test with Chrome Incognito Mode?

Running tests in incognito mode can be incredibly useful for keeping your testing environment clean and predictable. In this guide, we’ll cover why you might want to run Cypress tests in incognito, the advantages of doing so, and the potential pitfalls of testing in a normal browser window.

Why Launch Cypress in Incognito Mode?

When you run tests in a regular browser session, data from previous sessions—like cookies, history, and cache—can affect the results. Incognito mode, on the other hand, starts fresh each time, which means you can avoid interference from any stored data and focus on testing the actual functionality.

Advantages of Testing in Incognito Mode

1. Data Isolation: Incognito mode prevents cached data, cookies, and login sessions from impacting test results. This is especially helpful when testing login flows or session management, where residual data can interfere.

2. Consistent Results: Running tests in incognito mode helps you avoid issues caused by leftover data, resulting in more reliable and consistent test results.

3. Efficient Debugging: With incognito, you don’t need to clear cache or cookies between tests, saving time and making it easier to debug issues without extra steps.

Common Issues in a Normal Browser Window

When running Cypress tests in a normal browser session, some common issues include:

• Interference from Cached Data: Cached data can cause tests to behave inconsistently, especially when testing dynamic content or APIs.
• Session Conflicts: Existing cookies or login sessions can cause issues in tests that involve authentication, leading to misleading results.
• Time-Consuming Debugging: Clearing the cache and cookies manually can slow down your workflow, adding unnecessary steps.

How to Configure Cypress to Launch in Incognito Mode

To run Cypress tests in Chrome’s incognito mode, configure Cypress to pass the --incognito flag in cypress.config.js file when launching Chrome. Here’s how to do it:

const { defineConfig } = require("cypress");

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('before:browser:launch', (browser = {}, launchOptions) => {
        if (browser.family === 'chromium' && browser.name !== 'electron') {
          launchOptions.args.push("--incognito");
          return launchOptions;
        }
      });
    },
  },
});

Adding this code will ensure that each time Cypress launches Chrome, it will open in incognito mode, providing a fresh, isolated environment for each test.

What Cypress Already Does For You

Worth knowing before you add the flag: Cypress does not reuse your everyday Chrome profile. It launches the browser with a fresh, isolated profile directory of its own, and since Cypress 12, testIsolation is on by default — cookies, localStorage, and sessionStorage are cleared between every test in a spec.

So if the problem you’re solving is “state from my own browsing is leaking into tests”, that’s already handled. Incognito earns its place for narrower reasons: matching a production environment where users arrive cookie-less, ruling out anything the profile directory persists across runs (service workers, cached bundles, extensions), or debugging a failure that only reproduces on a genuinely cold start.

When State Still Leaks

If tests interfere with each other despite the above, incognito usually isn’t the fix — the state is living somewhere Cypress doesn’t clear:

• IndexedDB, which testIsolation does not clear.
• The application server — a seeded user whose data one test mutates and the next depends on.
• Service workers, which can serve cached responses from a previous run.

For the first and third, clear them explicitly in a beforeEach:

beforeEach(() => {
  indexedDB.deleteDatabase('my-app-db');
});

For the second, the fix is test data, not browser settings.

Don’t Throw Away Your Login Speed

The common reason people want a clean session is authentication, and incognito is an expensive way to get it — every test logs in through the UI again. cy.session() caches and restores the session instead:

beforeEach(() => {
  cy.session('standard-user', () => {
    cy.visit('/login');
    cy.get('[data-cy=email]').type(Cypress.env('USER_EMAIL'));
    cy.get('[data-cy=password]').type(Cypress.env('USER_PASSWORD'), { log: false });
    cy.get('[data-cy=submit]').click();
    cy.url().should('include', '/dashboard');
  });
});

The login runs once; subsequent tests restore the cached cookies and storage in milliseconds. You get isolation and speed, which incognito alone can’t give you.

If the Flag Seems to Do Nothing

A few things to check:

• Confirm which browser you launched. The config above only applies to Chromium-family browsers and explicitly skips Electron — and Electron is Cypress’s default. Run with --browser chrome.
• Return launchOptions on every path. In the snippet above, the if block returns but the function returns undefined when the condition is false. That works today, but it’s worth restructuring so the return sits outside the conditional.
• Incognito and --headless don’t combine meaningfully. Headless Chrome already starts from a clean profile, so the flag buys you nothing there.
• Chrome extensions are disabled in incognito by default, which occasionally breaks setups that depend on one.

When a test does fail after this change, the error message is usually the fastest route to the cause — the Cypress error reference covers the common ones, from cy.visit() failures to element-not-found timeouts.

Final Thoughts

Running Cypress tests in incognito mode can help with isolating test environments and improving reliability — but treat it as one tool among several rather than the default answer. For most suites, testIsolation plus cy.session() gets you cleaner isolation and faster runs. Reach for incognito when you specifically need a cold browser, and you’ll know exactly what it’s buying you.