passing the Chrome profile directly to the large language model, and the browser skill is ignoring the profile name on starting chrome

[pleabargain]

I'm passing the Chrome profile directly to the large language model, and the browser skill is ignoring it.

[pleabargain]

I'm explicitly telling Browser Skill to use a specific profile, and it's ignoring that information! That is one of the key reasons I want to use the browser skill: it will use my existing profiles, but it is failing to do so.
152.0.7977.84 (Official Build) (64-bit) (cohort: Control)

error again

[pleabargain]

Sanitized — identifying references removed, technical detail preserved:

---

Bug report: Browser Skill does not bind to a specific Chrome user-data profile

Status: Open (workaround documented; product-side fix needed)
Severity: High — wrong-profile automation can publish to the wrong account context or block required work
Component: Browser Skill (bsk CLI + Chrome extension)
Affected workspace: [Redacted] — multi-profile setup requiring a specific Chrome profile
Date observed: 2026-09-10
Logged by: [Redacted]

Related local notes: chrome-profile-browserskill.md · preflight ../../scripts/assert-chrome-profile.ps1 · playbook ../../navigation-playbook.md

Summary

Browser Skill repeatedly connects to whichever Chromium instance has the extension in a Connected state, with no first-class way to select, pin, or verify a Chrome --profile-directory / user-data profile. In a multi-profile Windows Chrome setup, that silently selects the wrong profile (here: Other Profile instead of Required Profile), while agents and humans believe "browser is ready" because bsk browsers / the extension popup show Connected.

Compounding Chrome's process singleton behavior makes launching the correct profile from the CLI unreliable while another profile is already running. The combination produces a recurring failure mode: automation is blocked or aimed at the wrong identity until Chrome is forcibly restarted as the required profile and the extension is reconnected there.

Environment

Item	Value
OS	Windows 10/11
Browser	Google Chrome 152.x
User data root	%LOCALAPPDATA%\Google\Chrome\User Data
Required profile	Profile A — [Redacted UI name / account] — required
Wrong profile often connected	Profile B — day-to-day profile
Extension	BrowserSkill extension (protocol 1.1, ext 0.2.1)
CLI	bsk 0.2.1 — local daemon (WebSocket on loopback)
Skill docs	Cursor Browser Skill (browser-skill/SKILL.md)

Chrome Local State mapping (verified 2026-09-10):

Profile A → [Required account]     ← required
Profile B → [Other account]        ← frequently Connected first

Expected behavior

• Operator / agent can require a specific Chrome profile (by --profile-directory, profile path, or stable label).
• bsk browsers (and/or bsk doctor) reports enough metadata to prove which profile each connected instance is using.
• bsk session start fails closed if the required profile is not the connected instance (or if multiple profiles are ambiguous).
• Launching or selecting the required profile does not silently attach work to another already-running profile.

Actual behavior

• bsk browsers returns instance metadata (instance_id, browser_name, browser_version, extension_version, label, session_count) but no profile-directory, profile path, Gaia email, or Chrome profile name.
• Labels are often empty, so --browser <id> cannot be chosen by human-meaningful profile identity.
• Extension popup Connected / READY is treated as success even when the underlying Chrome process is the non-required profile.
• Starting Chrome with --profile-directory="<Required-Profile>" while the other profile holds the singleton prints:
  Opening in existing browser session.
  and no chrome.exe with profile-directory=<Required-Profile> appears in process listings.
• After killing Chrome and starting only the required profile, bsk doctor reports:
  FAIL extension connected 0 browsers connected
  until the user manually activates BrowserSkill on that window — easy to miss when a prior session was already "Connected" on another profile.
• Humans sometimes open http://0.0.0.X/ believing it relates to the profile folder name; that is an unreachable IP (ERR_ADDRESS_UNREACHABLE) and unrelated to Chrome user-data profiles.

Root causes (technical)

1. No profile binding in the Browser Skill control plane

Symptom: Connection identity is "browser instance + extension," not "Chrome user-data profile."

Evidence — bsk browsers --json fields observed:

instance_id, browser_name, browser_version, extension_version, label, session_count, connected_at_ms, version_skew, extension_protocol_version

Absent: profile_directory, user_data_dir, profile_path, profile_name, account_email

Workspace rule requires the specific profile, but neither the skill doc nor the CLI surface a profile filter. Agents must out-of-band scrape process CommandLine for profile-directory=… and hope it matches the connected extension instance.

Why it fails repeatedly: Any time the user normally browses in the other profile with BrowserSkill installed/connected, the daemon happily reports a ready browser. Agents that only check bsk browsers / extension UI proceed on the wrong profile.

2. Chrome process singleton vs multi-profile launch

Symptom: CLI "start required profile" does not create the required profile process when another profile already owns the user-data singleton.

Evidence (2026-09-10):

Start-Process chrome.exe --profile-directory="<Required-Profile>" …
→ "Opening in existing browser session."
→ Process list still shows only: chrome.exe --profile-directory="<Other-Profile>"

Chrome multiplexes subsequent launches into the existing browser process for the same user-data root. The requested --profile-directory is not reliably honored for a second concurrent profile from a simple second chrome.exe invocation.

3. Extension connection is orthogonal to profile process state

State	Chrome processes	bsk browsers
A	Other profile only	1 INSTANCE (Connected) — wrong
B	Required profile only, extension idle	(no browsers connected) — blocked
C	Required profile only, extension Connected	1 INSTANCE — correct

bsk doctor correctly distinguishes B vs C (FAIL vs ok), but cannot distinguish A from C without external process inspection.

4. Ambiguous multi-browser selection UX

Skill guidance: when multiple browsers are connected, use bsk session start --browser <id-or-label>.

Gap: If two profiles ever connect simultaneously, IDs are opaque and labels are often blank. There is no documented way to map instance_id → required profile.

5. Documentation / mental-model mismatch

• Local skill doc emphasizes session lifecycle (session start → commands → session stop) and does not mention Chrome --profile-directory or Windows multi-profile pitfalls.
• Workspace rule says "confirm required profile process before session start," but no shipped bsk command performs that check.
• Path ...\User Data\<Profile-Name> is a folder name, not a URL. Confusion with 0.0.0.X delayed recovery.

6. Incomplete / profile-local extension state (secondary)

On the required profile, extension files existed under Extensions\<extension-id>\0.2.1_0 and the id appeared in pinned extensions / update client data, while extensions.settings parsing did not show a normal enabled settings blob the same way as a healthy install. This contributed to "required profile up, extension not Connected" after a forced restart until the Web Store / toolbar popup was used again.

Reproduction steps

1. On Windows, have at least two Chrome profiles under the same User Data root (e.g. Profile A = required, Profile B = other).
2. Install BrowserSkill in the profile you use day-to-day (Profile B). Open it until Connected.
3. Run bsk browsers / bsk doctor → reports connected browser(s). No profile field.
4. Without quitting Chrome, run:
   chrome.exe --profile-directory="<Required-Profile>" https://example.com
   Observe Opening in existing browser session and process list still showing the other profile.
5. Agent checks only bsk browsers → believes ready → drives wrong profile.
6. Quit all Chrome; start only required profile; do not click BrowserSkill → bsk doctor FAIL (0 browsers). Agent blocked even though the correct profile is open.
7. Click BrowserSkill Connected on required profile → finally healthy.

Impact

• Policy violation risk: Workspace rules forbid non-required-profile automation; product UX makes compliance unverifiable from bsk alone.
• Operational delay: Hours of thrash (wrong Connected instance, singleton launches, help prompts on the wrong session, IP-address confusion) before pages could be published.
• Data / auth risk: Wrong profile may be logged into a different identity; admin actions could target the wrong cookies/session if both can reach the same host.
• False confidence: Extension UI "Connected" is not "Connected to the profile you care about."

Workarounds (current)

• Preflight script (repo):
  powershell -NoProfile -ExecutionPolicy Bypass -File "scripts\assert-chrome-profile.ps1"
  Cross-checks process profile-directory and bsk browsers / doctor.
• If required profile will not start: fully quit other Chrome profiles (or all chrome.exe), then launch only:
  chrome.exe --profile-directory="<Required-Profile>"
• On that window only: BrowserSkill → Connected / READY; confirm bsk doctor → ok extension connected.
• Do not treat other-profile Connected as success; do not use http://0.0.0.X/.
• Prefer bsk session start --browser <id> only after process proof of required profile.

These are operator workarounds, not fixes to the underlying binding gap.

Proposed product fixes (Browser Skill)

P0 — Expose profile identity on each connected browser

Include in bsk browsers --json (and doctor):

• profile_directory
• user_data_dir
• profile_path
• optional: Chrome profile name / signed-in email if available from the extension

Implementation sketch: extension reads its own Chrome profile context and reports it on the daemon handshake.

P0 — Session start filter / fail-closed

bsk session start --profile-directory "<Required-Profile>"
bsk session start --profile-path "<Chrome User Data>\<Required-Profile>"

Exit non-zero if no matching connected instance. Optional config file: default required profile per machine/workspace.

P1 — Stable human labels

Auto-label instances as Chrome's profile name when label is empty, or allow bsk browsers --label <name>.

P1 — Document Windows multi-profile + singleton

In Browser Skill skill/docs:

• Same User Data root → second --profile-directory launch may not create a second profile process.
• Connected ≠ correct profile.
• Recommended preflight: process list + bsk doctor.

P2 — Diagnose command

bsk doctor --expect-profile "<Required-Profile>"

Prints side-by-side: connected instances vs running chrome.exe profile-directory values; highlights mismatch.

Proposed workspace / agent fixes (already in progress locally)

Artifact	Role
scripts/assert-chrome-profile.ps1	Fail-fast preflight
logs/…/chrome-profile-browserskill.md	Incident procedure
.cursor/rules/chrome-profile.mdc	Always-apply: no fallback to other profiles
navigation-playbook.md	Should cite preflight before bsk session start

Agents must run the assert script before bsk session start for this repo.

Acceptance criteria for "fixed"

• bsk browsers --json includes profile directory (or equivalent) for every instance.
• bsk session start --profile-directory "<Required-Profile>" refuses to start on the other profile.
• With other profile Connected and required profile not Connected, an expect-profile doctor check fails clearly.
• Skill documentation describes the Chrome singleton multi-profile failure mode on Windows.
• Local assert script remains green when only required profile + extension Connected.

Appendix — command transcript excerpts (2026-09-10, redacted)

Wrong profile Connected:

profile-directory="<Other-Profile>"
INSTANCE … <instance_id> chrome … SESSIONS 0

Singleton ignore of required-profile launch:

Opening in existing browser session.
Pid … <Other-Profile>

Correct process, extension not yet Connected:

chrome.exe --profile-directory=<Required-Profile> …
bsk doctor → FAIL extension connected — 0 browsers connected

Healthy:

chrome.exe --profile-directory=<Required-Profile> …
bsk doctor → ok extension connected — 1 browser(s) connected

One-line root cause

Browser Skill connects to an extension session, not to a Chrome user-data profile — and Chrome's singleton launcher often prevents the desired profile from existing as a separate process — so "Connected" repeatedly means "ready on the wrong profile" or "not ready on the right one."