Fix Cursor Arc cookie import and access errors

[jperezr21]

Summary

• add Arc-specific Chromium cookie import/decrypt path for Cursor sessions
• propagate browser cookie access-denied as a dedicated Cursor error
• expand recognized Cursor session cookie names
• harden Arc decrypt by stripping the 32-byte prefix only when it matches host-key SHA-256
• tighten cursor domain matching to exact/suffix rules
• add tests for likely/non-session cookie name detection

Validation

• ./Scripts/compile_and_run.sh
• swift test --filter CursorStatusProbeTests
• swift run CodexBarCLI usage --provider cursor --log-level debug

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 49afa43c77

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Narrow Cursor session cookie heuristics

Including very generic names like session, __wuid, and workos_id in the session-cookie allowlist makes importSession return on cookies that are not guaranteed to authenticate a user, and that short-circuits the browser scan before later browsers are tried. In fetch, a false-positive from the first browser can lead to .notLoggedIn (or fallback to stale stored cookies) even when another browser in the configured order has a valid Cursor login.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Distinguish missing Arc key from denied keychain access

This path throws .accessDenied whenever no safe-storage label yields a password, but findGenericPassword returns nil for both true permission denials and non-denial cases like missing/renamed keychain items. Treating all misses as access-denied causes BrowserCookieAccessGate.recordIfNeeded to suppress retries and surfaces a misleading “allow Keychain access” error when the actual issue is key lookup, not user denial.

Useful? React with 👍 / 👎.