Multiple GitHub & GitLab Accounts for Client Work (2026 Guide)

Two weeks ago, a contractor in our network got an awkward email from GitHub Trust & Safety. His personal account — the one with his open-source contributions, his dotfiles repo, his 6-year commit streak — was "under review for potential policy violations."

He hadn't done anything wrong.

But a client project he'd been working on (under a separate GitHub account provided by the client's org) had triggered some kind of abuse flag. Automated scraping that went too aggressive, or a dependency bot that misbehaved, or something in the CI pipeline — he never got specifics. GitHub's opacity here is genuinely frustrating, and I say that as someone who understands why they can't reveal detection methods.

The problem: GitHub had linked his personal account to the client account. Same browser. Same fingerprint. When the client account got flagged, his personal account became collateral damage.

He sorted it out eventually. Appeals, explanations, a week of anxiety. But his takeaway was clear: if you're running multiple GitHub accounts for different clients, those accounts need to look like they're coming from different machines. Not just different Chrome profiles. Different devices.

That's what this guide covers. Browser fingerprint isolation for developers who legitimately need multiple GitHub and GitLab accounts — without triggering the detection systems designed to catch ban evaders and bot farms.

Why Developer Platforms Care About Fingerprints

GitHub and GitLab aren't freelance marketplaces with one-account-per-person rules. They explicitly allow multiple accounts for "separate purposes." But their abuse detection systems still fingerprint browsers, because bad actors (scraper farms, star-manipulation networks, spam account clusters) use multiple accounts too.

Here's what gets tracked.

Canvas fingerprint. Your browser renders a small image. The output depends on your GPU, graphics drivers, OS font rendering. The hash is essentially a device ID. Two accounts, same canvas hash — GitHub knows they're on the same machine.

WebGL renderer string. Your GPU identifier ("Apple M3 Max" or "Intel UHD Graphics 630") is exposed to any website that asks. Developer machines tend to have distinctive GPU configurations, making this a reliable clustering signal.

Timezone and locale. Not a hard signal, but inconsistencies matter. If one account is set up as a US developer and another as EU-based, but both have identical hardware fingerprints and matching login times, that's a pattern.

Session behavior. Login patterns, navigation flow, time-on-page. GitHub's ML models look for "coordinated" behavior across accounts — not identical actions, but suspiciously similar rhythms.

For most developers, account linking is invisible and harmless. Your personal account and your work account are both you, GitHub knows it, nobody cares. The problem surfaces when something goes wrong with one account and the linkage becomes liability.

The contractor I mentioned? If his accounts had distinct fingerprints, the client-account flag wouldn't have touched his personal account. Isolation isn't about hiding — it's about compartmentalization.

When You Actually Need This

Not every multi-account situation requires fingerprint separation. Here's when it matters.

Client-provided org accounts. Each client's account should be isolated so their operational issues don't splash onto your personal reputation.

Agency work. Keeping client environments fully separate prevents one client's security incident from implicating another.

Open-source maintainer + day job. Your employer's GitHub Enterprise shouldn't have any technical link to your personal open-source presence.

Security research. Testing API limits or building experimental tooling — do it from an isolated profile so your main account doesn't get caught in blast radius.

If you're just switching between a personal account and your employer's SSO account, standard Chrome profiles are probably fine. Honestly, most developers overthink this part. But if account linking would create contract risk or reputational risk — isolation is worth the setup time.

The Setup: One Browser Profile Per Client

The principle is simple. Each client relationship gets its own browser profile with a unique, locked fingerprint. Here's the practical walkthrough.

Step 1: Create the profile. In JustBrowser, create a new profile. Name it clearly — "ClientA-GitHub" or "Acme-Corp-GitLab" — so you don't accidentally cross-contaminate sessions.

Step 2: Generate and lock the fingerprint. Let the tool generate a randomized fingerprint, then save it. You want this specific canvas hash, WebGL renderer, font list, and timezone to stay consistent every session. I learned this the hard way — randomizing fingerprints per-launch looks like evasion behavior and actually increases detection risk. Counterintuitive, but that's how browser fingerprint detection works.

Step 3: Match the geography. If you're working with a US client, set timezone to America/New_York or America/Los_Angeles. If the client expects EU presence, set Europe/Berlin or similar. Mismatches between fingerprint locale and claimed location raise flags.

Step 4: Configure proxy (optional but recommended). For high-stakes client work, route through a clean residential or ISP proxy matching the expected geography. Not strictly necessary for GitHub's detection — they're more fingerprint-focused than IP-focused — but it adds a layer of consistency. Static residential IPs run $3-8/month from providers like IPRoyal or Bright Data. See our proxy configuration guide for setup details.

Step 5: Isolate credentials completely. Each profile should have its own:

GitHub/GitLab credentials (obviously)
SSH key pair (don't reuse across profiles)
GPG signing key (if you sign commits)
Email address (ideally client-specific)
Password manager entry (don't mix)

The credential isolation matters as much as the fingerprint isolation. Reusing your personal SSH key across client accounts creates linkage outside the browser layer.

Git Configuration Per Profile

Most developers already handle SSH key separation with ~/.ssh/config blocks. The browser profile adds another layer.

SSH config example:

Host github-clienta
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_clienta
  IdentitiesOnly yes

Host github-clientb
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_clientb
  IdentitiesOnly yes

When cloning repos for ClientA, use git clone git@github-clienta:org/repo.git. This keeps SSH identities per-client.

Git config per repo:

cd /path/to/client-a-project
git config user.email "[email protected]"
git config user.name "Your Name"
git config user.signingkey ABC123DEF456

Local .git/config overrides global, so each repo uses the right identity.

The browser profile is for web UI interactions — viewing PRs, managing settings, OAuth flows, CI dashboards. The SSH/GPG setup is for command-line git operations. Both need to be isolated for full separation.

Verification: Confirming Fingerprint Isolation

Before using a profile for real client work, verify the fingerprint is distinct.

Test sequence: Launch profile, visit CreepJS, note the fingerprint hash. Close completely. Launch a different profile. Run the same test. Hashes should be completely different.

If two profiles show the same hash, you're probably opening tabs in one profile instead of launching separate instances. (I've made this mistake.)

Consistency check: Launch the same profile across three different days. The fingerprint should stay identical — drift looks like a bot signal. See our CreepJS walkthrough for step-by-step verification.

IDE and Tooling Considerations

Your browser profile handles web UI interactions. But VS Code and JetBrains IDEs have their own account linking through Settings Sync and GitHub integrations.

Quick fixes: Disable Settings Sync for client workspaces. Use project-level .git/config overrides. For GitHub CLI, switch contexts with gh auth switch or use GH_CONFIG_DIR per terminal session.

The IDE doesn't touch browser fingerprinting — that's a web layer concern. But sync features and stored credentials can still create correlation. Keep them separate.

Annoying? Yes. But it's the price of actual isolation.

Common Errors and Fixes

CreepJS shows identical fingerprints across profiles

Cause: Opening tabs in one profile instead of launching separate profiles. Fix: Close everything. Launch Profile A, test, close. Launch Profile B, test.

GitHub asks for additional verification

Cause: New device fingerprint triggers risk scoring. Fix: Complete verification — this is normal for new devices. Use the profile consistently afterward.

SSH key conflicts between profiles

Cause: Default SSH key used instead of host-specific key. Fix: Add IdentitiesOnly yes to your ~/.ssh/config host blocks.

Profile fingerprint changes between sessions

Cause: You regenerated the fingerprint manually, or you are comparing two different profiles. Fix: Don't regenerate a fingerprint on a profile that already has an account tied to it; fingerprints stay fixed between launches on their own.

What This Doesn't Solve

Fingerprint isolation handles the browser detection layer. It doesn't handle git commit authorship (use client-appropriate user.email per repo), payment linkage (if multiple accounts bill the same card), or code style fingerprinting (your variable naming habits, if someone's looking that hard).

The goal isn't perfect anonymity — and anyone selling you "perfect anonymity" is overselling. It's compartmentalization so automated systems don't create unintended linkages between legitimately separate professional contexts.

Next Steps

Add clients incrementally. Create profiles as you onboard clients, not speculatively. Each profile is maintenance overhead.

Document everything. Track which profile maps to which client, which SSH key, which email. I use a simple markdown file. (Yes, I've mixed up profiles before. It was embarrassing.)

For automation workflows — JustBrowser's REST API, included in the one plan at $9.99/mo, lets you launch profiles programmatically for CI/CD monitoring or API integrations. See our REST API quickstart for Playwright and Puppeteer integration.

For analytics without leaking data between clients, JustAnalytics keeps everything separated. For click fraud protection on client ad campaigns, ClickzProtect monitors and blocks invalid clicks.

Frequently Asked Questions

Does GitHub actually track browser fingerprints across accounts?

Yes. GitHub's abuse detection systems fingerprint browsers to detect coordinated inauthentic behavior, ban evasion, and account farming. Two accounts with identical canvas hashes and WebGL renderer strings logging in from the same machine get correlated. GitHub won't necessarily ban you immediately, but the link exists in their systems — and if one account gets flagged for any reason, the other becomes suspect.

Can I just use separate Chrome profiles instead of an antidetect browser?

Chrome profiles share the same underlying browser engine and many hardware fingerprint values. Canvas rendering, WebGL output, and audio fingerprints will be identical across profiles. You'll have separate cookies and history, but not separate device identities. For casual separation that's fine. For client work where account linking could cause contract problems, it's not enough.

What about SSH keys and GPG signing — do those link accounts too?

Not at the browser fingerprint layer, but operationally yes. If you sign commits with the same GPG key across accounts, or push using the same SSH key, that's linkage. Keep SSH keys and GPG identities per-client just like you keep browser profiles per-client. Most developers already do this with SSH config blocks — the browser side just extends the same principle.

Is running multiple GitHub accounts against their Terms of Service?

GitHub ToS allows multiple accounts if they're used for "separate purposes." A personal account and a client-org account are separate purposes. The policy targets ban evasion and sock puppets, not legitimate contractor workflows. That said, if accounts get linked and one gets suspended for unrelated reasons, the other may face scrutiny. Fingerprint separation reduces that risk.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. REST API for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower