fix: restore background Chromium cookie imports without Keychain prompts - #2611
fix: restore background Chromium cookie imports without Keychain prompts#2611tangzhu599 wants to merge 1 commit into
Conversation
Background refreshes skipped every Chromium browser (17c8729) to avoid Safe Storage prompts, which broke cookie-only providers like Kimi ("No available fetch strategy for kimi") until a manual refresh. Bump SweetCookieKit to 0.5.1 and run background cookie reads with withUserInteractionDisallowed: browsers whose Safe Storage key requires interaction yield no cookies instead of prompting, the prompt-free attribute preflight still filters locked/denied keychain states, and background probes never write denial cooldowns that would suppress the next manual refresh.
|
ClawSweeper status: review started. I am starting a fresh review of this pull request: fix: restore background Chromium cookie imports without Keychain prompts This is item 1/1 in the current shard. Shard 0/1. This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking. Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f86068d904
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Only user-initiated actions may write denial cooldowns. Background probes must | ||
| // not suppress a browser for hours (including the user's next manual refresh) | ||
| // based on a non-interactive probe outcome. | ||
| guard ProviderInteractionContext.current == .userInitiated else { return } |
There was a problem hiding this comment.
Because ProviderInteractionContext.current defaults to .background, this guard makes every existing unwrapped recordDenied test seed a no-op. Multiple macOS tests still rely on those calls, including OllamaUsageFetcherTests.swift:170, which immediately expects hasActiveDenial to be true, and CLICookieRefreshTests.swift:305, which expects a stored-denial recovery hint; the full test suite will therefore fail. Wrap all intended user-denial seeds in a .userInitiated context or provide a dedicated test-state helper.
AGENTS.md reference: AGENTS.md:L23-L24
Useful? React with 👍 / 👎.
|
Closing as duplicate: upstream #2528 (a388338) already implements the same fix — background refreshes reuse an already-authorized Safe Storage ACL. This branch also carried two hardening deltas (read-site withUserInteractionDisallowed wrapper, userInitiated-only denial recording) that can be re-proposed as a focused follow-up if wanted. |
1 participant
Summary
Restore automatic Chromium cookie imports for background refreshes without reintroducing Keychain prompts. Cookie-only providers such as Kimi currently report "No available fetch strategy for kimi." on every automatic refresh and only work after a manual refresh.
Root cause
#2225 (17c8729) blocked all background Chromium cookie access by returning
falsefromBrowserCookieAccessGate.shouldAttemptwhenever the interaction context is not.userInitiated. Periodic and menu-open refreshes run in.background, so a provider whose only credential path is browser cookies (no API key, no fresh CLI credential) reportsnoAvailableStrategyuntil the user performs a manual (.userInitiated) refresh. The #2225 review even flagged this: "users who rely on Chromium cookies for automatic provider refresh may receive stale usage or authentication failures until they perform a manual refresh."#2225's own follow-up prescribed the fix: SweetCookieKit was hardened so hosts can suppress interactive Safe Storage promotion, and "once released, CodexBar should bump that dependency."
Change
BrowserCookieKeychainAccessGate.withUserInteractionDisallowed, the hardening Block background Chromium Keychain access #2225 planned for.BrowserCookieAccessGate.shouldAttempt— background path now: honors recorded denial cooldowns, runs the prompt-free attribute preflight (skips when interaction is required), and allows the import otherwise, instead of blanket-skipping every Chromium browser.codexBarRecords— every cookie read goes throughwithCookieReadInteractionPolicy: background reads run withwithUserInteractionDisallowed(SweetCookieKit can never promote to an interactive prompt; a key that needs UI simply yields no cookies), user-initiated reads keep the interactive recovery path.recordDenied— only user-initiated actions write denial cooldowns, so a background probe can never suppress the user's next manual refresh for 6h.Safety
withUserInteractionDisallowed.Validation
swift build --target CodexBarCoreandCodexBarCLIpass.