fix(network): bypass Cloudflare bot protection using WKWebView

[willsheldon]

Summary

• Replace URLSession-based NetworkService with WKWebView-based implementation to bypass Cloudflare's bot protection on Claude.ai API endpoints
• Fix organization selection to prefer orgs with "chat" capability for users with multiple organizations
• Add capabilities field to Organization model

Problem

Cloudflare recently started blocking requests from URLSession due to TLS fingerprint mismatch. The cf_clearance cookie is tied to browser TLS fingerprints, so simple HTTP clients (URLSession, curl) cannot pass JavaScript challenges even with valid session keys.

Solution

Created WebViewNetworkService using WKWebView which shares Safari's TLS stack. WKWebView automatically handles Cloudflare JS challenges and has the correct TLS fingerprint that Cloudflare expects.

The service polls page content until valid JSON is detected, handling the delay while Cloudflare challenges complete.

Additional Fixes

• Added capabilities field to Organization model with hasChatCapability helper
• Updated org selection in UsageService and AppModel to prefer organizations with "chat" capability
• This fixes issues for users with multiple orgs (API-only vs Claude.ai personal org)
• Added timeout case to NetworkError enum
• Changed NetworkServiceProtocol from Actor to Sendable constraint to support @mainactor classes

Test plan

• Build succeeds
• App launches and displays usage data in menu bar
• Verified API requests bypass Cloudflare (no 403 errors)
• Verified correct organization is selected for users with multiple orgs

🤖 Generated with Claude Code

[vinisalazar]

Just FYI I ran a security analysis of this repo with Copilot and it flagged this PR as a security risk:

4. Medium risk: open PR fix(network): bypass Cloudflare bot protection using WKWebView #8 uses WKWebView to bypass Cloudflare bot protection
   There is one open PR that explicitly replaces a URLSession-based network path with a WKWebView implementation to bypass Cloudflare bot protection on Claude.ai endpoints.

That is security-relevant for several reasons:

it changes trust boundaries from API client logic to browser/webview behavior
cookies/session material may be handled inside webview/browser storage contexts
HTML/JS challenge content becomes part of the execution path
parsing JSON out of page content after challenge completion is more fragile than direct API use
from a policy/risk standpoint, “bypass bot protection” is itself a red flag
This does not automatically mean the repo is malicious, but if merged, I would rate the security risk higher than the current main branch. It deserves careful review before adoption.

[eddmann]

Thanks for this. I’ve been reviewing the change again and wanted to check whether you’re still able to reproduce the Cloudflare blocking issue on the latest release.

I haven’t been seeing Cloudflare blocks locally with the current URLSession-based networking path, so before taking on the larger WKWebView transport change I’d like to confirm whether this is still an active problem and under what conditions it happens.

If you are still seeing Cloudflare blocks, could you share:

• the ClaudeMeter version you’re running, shown in Settings -> About
• whether it happens while entering the session key during setup, while refreshing usage from the popover, or both
• the visible error message shown by ClaudeMeter
• whether pressing Retry/refreshing again changes the behavior
• whether quitting and reopening ClaudeMeter changes the behavior