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:\GPALProfiles\warmed-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 user data directory for that session and hands it to the browser. Chrome 136+ requires a user-data directory to be specified for anything, so GPAL always provides one, and every engine and every browser does it the same way, Firefox included.

These temporary profiles are created under C:Profiles unless you name somewhere else with GPAL.WithTempProfileParentDirectory, which expands environment variables, so %TEMP%gpal-profiles is a valid thing to give it.

GPAL knows it created the profile and deletes the directory when the browser closes, so nothing accumulates between runs. A run that is killed rather than closed never gets to that point, and profiles left that way are cleared as later runs open and close browsers.

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 and deletes it on close

GPAL.Browser

.WithBrowserType(BrowserType.Chrome)

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


// Create them somewhere other than C:Profiles. Environment variables are expanded

GPAL.WithTempProfileParentDirectory("D:\GPALTemp");

GPAL.WithTempProfileParentDirectory("%TEMP%\gpal-profiles");

NOTE

A temporary profile a browser still has open is left alone and cleared later, so parallel runs never disturb each other's profiles, and a directory carrying a .sweeping suffix is one GPAL was part way through removing and will finish on a later run. Leave the parent directory to GPAL and keep your own profiles elsewhere: everything under it named BrowserProfile_ is GPAL's to delete. One kind of leftover is not GPAL's and does not live there at all. Selenium with Firefox and no profile named lets geckodriver create a profile of its own in %TEMP%, named rust_mozprofile, which GPAL neither creates nor removes. Name a profile, or expect those to build up.

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