Concepts

Basic Concepts

Basic Concepts

Browser Profiles: Signed-In vs Temporary

Why a Real Profile Helps

Anti-bot systems check more than fingerprint. They look at whether the browser belongs to a real returning person: cookies, saved logins, history, extensions, and site permissions all factor in. A brand-new empty profile is itself a signal. WithProfileDataDirectory points GPAL at a Chrome user-data directory on disk; WithProfileUserName finds the profile by Windows account. Sign in and browse once with that profile, and every GPAL session after inherits that history.

// Use an existing, signed-in Chrome profile

GPAL.Browser

.WithBrowserType(BrowserType.Chrome)

.WithProfileDataDirectory(@"C:GPALProfileswarmed-up-profile")

.GoTo("https://example.com");


// Or locate a profile by the Windows account that owns it

GPAL.Browser

.WithBrowserType(BrowserType.Chrome)

.WithProfileUserName("Ottomatic")

.GoTo("https://example.com");

NOTE

If both WithProfileUserName and WithProfileDataDirectory are set, the explicit directory takes precedence.

The Default: A Disposable Temporary Profile

If you don't specify a profile at all, GPAL creates a brand-new, empty Chrome user-data directory for that session. Chrome 136+ requires a user-data directory to be specified for anything, so GPAL always provides one. GPAL tracks that it created this temporary profile and removes the directory again when the browser closes, so nothing accumulates on disk between runs. This is the simplest path and is fine for quick, one-off tasks where stealth doesn't matter.

// No profile specified - GPAL creates a temporary one

GPAL.Browser

.WithBrowserType(BrowserType.Chrome)

.GoTo("https://example.com");

Where Temporary Profiles Cause Trouble

A freshly created profile has no cookies, no saved logins, no history, and no extensions. Which is exactly the pattern many anti-bot systems flag as automation. It can also trigger first-run dialogs (default browser prompts, sign-in nags, 'import bookmarks' offers) that a warmed-up profile would already have dismissed once. For sites that are sensitive to bot traffic, or for long-running/scheduled jobs where you want the session to look like the same returning user every time, set up a dedicated profile once. Sign in, browse around a bit, accept the usual cookie banners. And point GPAL at it with WithProfileDataDirectory rather than relying on the temporary default.

NOTE

Worth knowing before it costs you an afternoon. A Chromium browser hosting an extension's background page does not exit when its last window closes: it starts a replacement with --no-startup-window and that one keeps the user data directory open. OttoMagic is such an extension, so this happens on every OttoMagic run. Edge does it. Chrome, as of this writing, does not. The consequence is the warning above, arriving where you would not think to look for it: the browser is off your screen and gone from your taskbar, yet the profile is still held, so the next run on it is handed to the invisible survivor and exits with no debugging port and no extension. What you see is a workflow that launches nothing and fails saying very little. GPAL closes that successor when it closes the browser it started, so an ordinary run leaves nothing behind. A run that is killed rather than closed does leave it, and then it is yours to find: look for msedge.exe running with no window, whose command line is --no-startup-window. To stop it happening at all, turn off "Continue running background extensions and apps when Microsoft Edge is closed" in edge://settings/system. GPAL will not do that for you: the setting is browser wide rather than per profile, so changing it would change the browser you use yourself.

WARNING

Because the temporary profile directory is created fresh and removed on close, it is safe to run several GPAL sessions in parallel without profile collisions. A persistent profile passed to WithProfileDataDirectory is different: it must not be used by two browser sessions at once. Chromium hands its command line to whichever browser already owns a user data directory and then exits, so the flags this run needs, the debug port above all, are dropped and the launch looks like it worked while nothing is actually listening. GPAL checks for that before launching and refuses, naming the process that already holds the profile, rather than letting the run fail later for a reason that points nowhere near the cause.

On this page

Basic Concepts
Browser Profiles: Signed-In vs Temporary
  • Why a Real Profile Helps
  • The Default: A Disposable Temporary Profile
  • Where Temporary Profiles Cause Trouble
    • 💬 Ask GPAL