claude-code - 💡(How to fix) Fix Claude in Chrome: false-positive block on dashboard.tossplace.com (SMB merchant analytics, not payment processing)

Summary

dashboard.tossplace.com is currently blocked by Claude in Chrome with the message "This site is blocked." (server-side category, not an org policy). I believe this is a false positive — the domain is a merchant-facing analytics dashboard for small business owners, not a payment-processing site.

What dashboard.tossplace.com actually is

• TossPlace is a SaaS POS product run by Toss (Korean fintech) for small/medium business owners — cafes, restaurants, retail shops.
• dashboard.tossplace.com is the owner's analytics dashboard: shows their own store's sales totals, hourly sales charts, transaction history, settlement reports, etc.
• It does not process payments, hold card data entry forms, or accept money transfers from anyone. It only reads sales records the owner already owns.
• Public marketing pages confirm this positioning (e.g. https://tossplace.com/product/sajangnim-book, https://tossplace.com/story/salesreport).

In other words: this is closer to "Shopify admin analytics" or "Square Dashboard sales reports" than to a checkout/payment page.

Comparison: same brand, different products

Toss runs multiple products under similar domains. They are not equivalent in risk:

This is analogous to: Kakao operates KakaoPay (payments), but Claude in Chrome does not block kakao.com, mail.kakao.com, or KakaoTalk admin tools just because they share the brand. The block should be on payment-handling surfaces, not the company's entire footprint.

Why this is harmful

Small business owners are an explicit target audience for Claude (data analysis, automation, dashboards). The current block prevents Claude in Chrome from:

• Reading the owner's own sales data they're already looking at
• Helping summarize hourly/daily sales trends
• Inspecting the page's network requests so the user can build their own integration

Users have no way to override this on personal accounts (confirmed by Issue #55580). The official TossPlace OpenAPI exists as a workaround, but requiring every shop owner to apply for API keys just to let Claude read a dashboard they're authorized to view is a friction mismatch.

Reproduction

1. Open https://dashboard.tossplace.com/sales-detail/period in Chrome (logged in as a merchant)
2. Ask Claude in Chrome to read the page or tab context
3. Result: "This site is blocked." (no nav, no read)

Tested on extension v1.0.71.

Requested fix

• Reclassify dashboard.tossplace.com (and any sibling merchant-admin subdomains like *.tossplace.com that are not payment surfaces) out of the auto-block category.
• More generally: consider distinguishing payment processing surfaces from merchant analytics dashboards in the classification rules. Many fintech brands have both; only the former carries the safety risk the current block is designed to mitigate.

Related

• #55580 (user-controlled allowlist override — would also solve this, but a classification fix is the cleaner path)
• #43279 (same false-positive pattern on app-dev.nomercy.tv)

Reporting from a real SMB use case: I run a small retail/cafe operation in Korea and use TossPlace as one of several POS systems. The dashboard is where I'd most want Claude's help, and it's the one site that's blocked.