Concepts

Automation Targets

Automation Targets

Browser Profiles: Signed-In vs Temporary

For the most reliable bot-resistant runs, point GPAL at a real Chrome profile that already has a signed-in session, cookies, and browsing history. If you don't specify one, GPAL creates a temporary profile for the session and deletes it afterward. Which works, but looks more 'bot-like' and can run into its own problems.

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");

TIP

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 and later removes a temporary one automatically

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.

WARNING

Because the temporary profile directory is created fresh and removed on close, it's safe to run multiple GPAL sessions in parallel without profile collisions. A persistent profile passed via WithProfileDataDirectory, on the other hand, should not be used by two browser sessions at the same time. Chrome locks the profile directory, and a second session pointed at the same directory can fail to launch or fall back to creating its own temporary profile instead.

On this page

Automation Targets
Browser Profiles: Signed-In vs Temporary
  • Why a Real Profile Helps
  • The Default: A Disposable Temporary Profile
  • Where Temporary Profiles Cause Trouble