[BUG] Claude in Chrome v1.0.69 inconsistently blocks Salesforce Lightning content reads — same domain, same plan, different sessions yield different results

Summary

Claude in Chrome v1.0.69 server-side classifier produces non-deterministic / per-session false positives when reading content from Salesforce Lightning Experience domains.

Two users on the same extension version, same org, same Team plan, same Salesforce tenant, same client-side "All sites" permission, empty admin blocklist observe different results within the same hour:

• User A: All MCP actions succeed (navigate, read_page, get_page_text, javascript_tool)
• User B: tabs_context_mcp succeeds, but read_page, get_page_text, and javascript_tool are denied on daiichi-keiei.lightning.force.com

Since the only variable that differs is the user account / browser session, this is a server-side classifier issue, not a per-domain hardcoded rule.

Affected domain

• daiichi-keiei.lightning.force.com (Salesforce Lightning Experience)
• Almost certainly affects other *.lightning.force.com tenants the same way (any Salesforce instance).

Repro

1. Two users in the same Team plan, both with Claude in Chrome v1.0.69, both with "Site access = On all sites".
2. Both navigate the same Salesforce Lightning page (e.g. a Chatter feed / record list).
3. Both invoke MCP read_page / get_page_text from a Claude Code session.
4. One succeeds. The other is denied with no actionable error path.

What we observed (User B, blocked session)

• tabs_context_mcp returned the Salesforce tab info correctly
• read_page, get_page_text denied
• javascript_tool denied
• navigate to chrome://extensions denied (expected; chrome:// is universally blocked)
• Client-side site access shows "On all sites"
• Org admin blocklist: empty
• The user has no override path available

What we observed (User A, working session)

• All MCP actions succeed on the same Salesforce domain
• read_page returned the full Lightning Experience accessibility tree

Why this is a false positive

• Salesforce is a general-purpose CRM, not a financial services / banking / trading / crypto platform.
• The classifier seemingly groups Salesforce under "financial services" because record contents may include monetary fields. Every business CRM contains such fields; that alone should not classify the platform as financial services.
• Critically, the classifier is non-deterministic: the same domain on the same extension version yields different decisions in different sessions in the same org. This indicates per-session classification drift, not a deliberate policy.

Environment

• Claude in Chrome: v1.0.69 (both users, identical)
• Chrome: latest stable
• OS: Windows 11 (both users)
• Plan: Team
• Org admin blocklist: empty
• Org admin allowlist: not configured
• Client-side site access: "On all sites" (both users)

Related issues

• #46491 — server-side classifier false positive (pd.smileynova.com)
• #43279 — legitimate dev subdomain blocked
• #48960 — script.google.com blocked after v1.0.68 update
• #50157 — claude.ai itself blocked at v1.0.68
• #41034 — all sites blocked in Cowork mode

The pattern across these reports — and ours — points at the v1.0.68 / v1.0.69 server-side classifier configuration being too aggressive and non-deterministic for legitimate enterprise SaaS domains.

Workaround

None at user or org-admin level for the affected user. Options:

1. Disable Claude in Chrome and use Salesforce manually
2. Use Claude Code with the sf CLI / MCP outside the browser
3. Ask another user in the same org whose session is currently classified as allowed to retrieve the content (this is what we are doing as a workaround — clearly unsustainable)

Request

1. Treat Salesforce (*.lightning.force.com, *.force.com, *.salesforce.com) as a general enterprise CRM, not as financial services, in the server-side classifier.
2. Investigate the non-determinism — same extension version, same domain, same org should produce the same classification for all sessions.
3. Provide an admin-level override path so that Team / Enterprise admins can allowlist verified business domains and have that decision authoritative over the classifier.