Account Pooler prevents Claude in Chrome tools from loading despite --chrome #4707

Summary

With Account Pooler routing Claude requests, enabling Claude in Chrome still leaves BB Claude Code threads with no mcp__claude-in-chrome__* tools. BB passes --chrome, but the pool's ANTHROPIC_AUTH_TOKEN overrides the host's usable native Claude login, so Claude Code skips Chrome tool registration. I expected the enabled integration to work, or BB to explain the authentication conflict and offer a scoped workaround.

Versions and environment

• Reproduced on 2026-10-01 PDT with BB 0.44.0, installed as the macOS desktop app. This is the latest published release at filing time.
• Release tag desktop-v0.44.0, commit 0baa605b32a00619c1d7e3f32be6553ebcf8244a. Code links below are pinned to that release.
• macOS 26.5.2 (25F84), local execution host.
• Claude Code provider through Agent SDK 0.3.245, installed Claude CLI 2.1.287.
• Claude in Chrome extension 1.0.97, installed in Chrome Default and Profile 1.
• Built-in Account Pooler enabled, Claude routing on, no parent pool. The host has a usable native claude.ai login.
• chromeEnabled=true; user config has claudeInChromeDefaultEnabled=true, completed onboarding, and cachedChromeExtensionInstalled=false.
• Current main was inspected separately, but not run. The reproduced runtime is the installed release above.

Steps to reproduce

Prerequisites: Claude in Chrome installed/enabled, a usable native Claude /login on the execution host, and Account Pooler configured with an enabled Claude account.

1. Enable the Chrome integration and Claude pool routing:

   bb plugin config provider-claude-code set chromeEnabled true
   bb pool routing claude

2. In an existing BB project, start a fresh Claude Code thread:

   bb thread spawn --project <project-id> --provider claude-code --prompt 'Use ToolSearch with query "chrome browser navigate". Report its result. Do not navigate or modify browser settings.'

3. Observe that ToolSearch finds no Chrome tools. The same symptom occurs on existing threads.
4. From a BB Claude shell carrying the pool environment, run the standalone control probe below. It starts the real claude --chrome -p executable directly, without the Agent SDK, and asks only for initialization and MCP status. It sends no model prompt or browser action.

python3 - <<'PY'
import subprocess,os,json,select,time
for clean in [False,True]:
 env=os.environ.copy()
 if clean:
  env.pop('ANTHROPIC_AUTH_TOKEN',None);env.pop('ANTHROPIC_BASE_URL',None)
 proc=subprocess.Popen(['claude','--chrome','-p','--input-format','stream-json','--output-format','stream-json','--verbose','--strict-mcp-config'],stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.DEVNULL,env=env,text=True,cwd=os.getcwd())
 try:
  for rid,sub in [('init','initialize'),('mcp','mcp_status')]:
   proc.stdin.write(json.dumps(dict(type='control_request',request_id=rid,request=dict(subtype=sub)))+'\n');proc.stdin.flush()
   deadline=time.time()+15
   while time.time()<deadline:
    if not select.select([proc.stdout],[],[],max(0,deadline-time.time()))[0]:break
    line=proc.stdout.readline()
    if not line:break
    try:d=json.loads(line)
    except:continue
    if d.get('type')=='control_response' and d.get('response',{}).get('request_id')==rid:
     r=d['response']
     if rid=='mcp':
      statuses=r.get('response',{}).get('mcpServers',[])
      print(json.dumps({'mode':'BB shell minus pool auth vars' if clean else 'BB shell proxy environment','status':r.get('subtype'),'mcp':[{'name':s['name'],'status':s['status'],'toolCount':len(s.get('tools',[]))} for s in statuses]}))
     break
 finally:
  proc.terminate()
  try:proc.wait(timeout=3)
  except:proc.kill()
PY

Expected vs actual

Actual ToolSearch output, for chrome browser navigate:

No matching deferred tools found.

Actual direct CLI control-probe output:

{"mode": "BB shell proxy environment", "status": "success", "mcp": []}
{"mode": "BB shell minus pool auth vars", "status": "success", "mcp": [{"name": "claude-in-chrome", "status": "connected", "toolCount": 22}]}

Expected: Chrome tools load when the integration is enabled and the host's browser login is usable. If pooled authentication is incompatible, BB should identify the reason and offer a per-thread route to the native login instead of silently exposing no tools.

Evidence

• Affected fresh thread: thr_37wkyzde3k, provider session 15abd75d-72a1-4922-8a5d-11543533a10e. Existing affected thread: thr_77ejvweans.
• Live PID 10228 runs CLI 2.1.287 with --chrome, stream-json input/output, and --setting-sources=user,project,local. The process has the pool authentication override. Its bridge worker does not have its own ANTHROPIC_* variables.
• The affected thread's provider.env-resolved event attributes both ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN to account-pool. No credential values are included here.

Isolated startup results

These SDK probes used the installed SDK 0.3.245 and CLI 2.1.287, explicit extraArgs: {chrome: null}, user/project/local setting sources, and strict MCP configuration to exclude unrelated configured servers. There were no model prompts.

The custom-header row verifies tool registration only. It does not verify a pooled model completion.

Cause

1. Account Pooler's Claude env contribution supplies the hub bearer through ANTHROPIC_AUTH_TOKEN.
2. The provider explicitly enables Chrome with {chrome: null}. The bridge environment merge passes the pool override to the CLI.
3. In the installed CLI 2.1.287, Chrome startup is gated by pNt(chrome) && ft(). ft() requires native claude.ai authentication; the local-session check returns false when ANTHROPIC_AUTH_TOKEN is active. Explicit --chrome does not bypass that authentication check. This mechanism was inspected in the installed binary and isolated by the probes above. Anthropic's Chrome prerequisites also require native /login authentication.

Existing per-thread workaround

bb pool bypass <thread-id>

The bypass contribution path removes the pool overrides on this configuration. The bridge detects the changed env and rebuilds with resume on the next new turn, not on a steer.

This is per thread, needs a usable native login, uses that local account's quota, and loses pool failover. New threads remain pooled. Revert with bb pool bypass <thread-id> --off. I verified the code path but did not apply this routing change during the investigation. Globally disabling Claude pool routing would also affect hosts without a usable local login, so it is not the scoped workaround.

Candidate fix, with constraints

Separate hub authentication from native Claude/browser identity. The hub already accepts x-bb-account-pool-token, and Claude supports custom headers. Moving the pool token there restored Chrome startup locally.

This is not a drop-in global replacement for ANTHROPIC_AUTH_TOKEN:

• The server needs a trustworthy host-local login/scopes signal and a fallback when that login is absent, logged out, expired, or inference-only. If a host RPC changes, bump HOST_DAEMON_PROTOCOL_VERSION.
• Native auth also loads claude.ai connectors and uses the local account for plan/usage checks while inference may use another pooled account. The local Claude bearer is sent to the hub on inference requests, including remote-host traffic. These behavior changes need an explicit decision.
• Preserve existing custom headers and test /v1/messages and /v1/messages/count_tokens through the pool on local and remote hosts. Those tests have not been performed here.

At minimum, BB should explain this conflict and expose the existing per-thread bypass alongside the Chrome setting.

What you ruled out

• Missing --chrome: verified in the live process and provider code.
• SDK incompatibility: the same SDK/CLI exposes all 22 Chrome tools without the auth override; the direct CLI control probe reproduces the distinction without the SDK.
• Missing extension or bad host registration: extension 1.0.97 and both native-host manifests are present.
• Desktop owning the extension as the cause of missing tool registration: Desktop stayed running during the successful probes. A separate read-only query found the local browser over Claude's account bridge, not the Desktop native-host socket. No claim of socket-based reachability is made.
• The false extension-detection cache: the installed CLI's explicit-flag path is not vetoed by cachedChromeExtensionInstalled; the successful probes left that value false.
• Duplicate of Claude Code threads have no browser control through chrome extension #1667: that issue fixed the missing launch flag in feat(provider-claude-code): add Claude in Chrome setting #2988. This happens after that fix, with the flag present, because pooled authentication suppresses Chrome.
• Duplicate of Disabling Account Pooler breaks Claude: running turns 503-retry for ~3 min, new threads fail with an expired local OAuth login #4352: that issue concerns disabling the pooler and failed local credential fallback. Here the pool remains enabled and the native login is usable.

Suggested priority and effort

Medium priority: prevents browser work in pooled Claude threads even when users enabled the integration. A per-thread workaround exists, but sacrifices failover. Effort needs scoping around host login state and authentication behavior. No BB code, persistent settings, or browser settings were changed during this investigation.

Checks

• Reproduced on the latest published desktop release, 0.44.0.
• Searched open and closed issues for Chrome tools, claude-in-chrome, Account Pooler, browser integration, and ANTHROPIC_AUTH_TOKEN.
• The report links the investigation and ends with the required marker.

BB-Thread-ID: thr_rfgvnpzenx

AGENT GENERATED