[codex] Decision: bound OpenCode Dia cookie import

[steipete]

Draft decision PR for #1822. This is not a behavior landing until product signs off on the Chrome -> Dia automatic import default.

Scope

• OpenCode web Auto cookie import now tries Chrome first, then Dia.
• The provider exception is exactly Chrome and Dia. It does not include Safari, Firefox, Edge, Brave, Arc, Chromium, or other browser families/forks.
• The shared BrowserCookieAccessGate now scopes Chromium Keychain preflight to the current candidate browser's own safeStorageLabels.
• The previous global-label behavior is retained only as a fallback for Chromium browser definitions that expose no browser-specific labels.

Privacy boundary proof

• Added call-recording Keychain preflight tests showing Chrome attempts query only Chrome Safe Storage labels.
• Added call-recording Keychain preflight tests showing Dia attempts query only Dia Safe Storage labels.
• Added suppression-order coverage showing an interaction-required Dia label suppresses only Dia and does not authorize or suppress Chrome.
• Added OpenCode provider order/label tests proving this provider's automatic path is limited to Chrome and Dia labels.
• No live browser stores or Keychain items were read during local validation.

Current limitation

Other Chromium browsers remain manual-only for OpenCode web cookies. Manual Cookie remains the escape hatch until CodexBar has an explicit user-selectable browser setting.

Product sign-off question

Should OpenCode web Auto broaden from Chrome-only to Chrome then Dia by default for #1822, accepting that users with Dia installed may see Dia's own Safe Storage prompt after Chrome is unavailable or unusable?

Validation

• swift test --filter BrowserDetectionTests
• swift test --filter BrowserCookieOrderStatusStringTests
• swift test --filter OpenCodeWebCookieSupportTests
• make check
• make test
• autoreview --mode uncommitted --no-web-search
• autoreview --mode commit --commit HEAD --no-web-search

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 1, 2026, 4:35 PM ET / 20:35 UTC.

Summary
The PR changes OpenCode web automatic cookie import to try Chrome then Dia, scopes Chromium Keychain preflight to each candidate browser's labels, and adds tests/docs/changelog coverage.

Reproducibility: yes. from source, but not from a live Dia setup. Current main routes OpenCode web Auto through automaticImportOrder(provider:), which returns [.chrome] for .opencode; AGENTS.md prevents unrequested live Keychain/browser validation that could prompt.

Review metrics: 3 noteworthy metrics.

• Provider default changed: 1 provider order changed. OpenCode web Auto moves from Chrome-only to Chrome then Dia, which can alter authentication source discovery.
• Browser gate changed: 1 shared access gate changed. The Keychain preflight helper is shared by browser cookie imports, so the per-browser label scope matters beyond the OpenCode descriptor.
• Files touched: 8 files affected. The PR includes implementation, tests, docs, and release-note surface that need a coherent decision.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1822
Summary: This draft PR is the candidate implementation and decision branch for the focused OpenCode Dia cookie-import issue.

Members:

• canonical: OpenCode web provider only searches Chrome cookies; misses Dia (and other Chromium browsers where users are logged in) #1822 - The PR body says it is a draft decision PR for the OpenCode Dia automatic cookie-import issue, which remains open.
• partial_overlap: feat(opencode): support multiple browsers for cookie import #373 - GitHub search found this closed-unmerged PR as an older broader multi-browser OpenCode cookie-import attempt, but it is not a safe canonical landing path.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P2] Record the maintainer decision on whether Dia belongs in the OpenCode Auto default before merge.

Risk before merge

• [P1] Maintainer product approval is explicitly pending because the PR broadens OpenCode Auto from Chrome-only to Chrome then Dia and may show Dia's Safe Storage prompt after Chrome is unavailable or unusable.

Maintainer options:

1. Approve bounded Dia default
   Merge after maintainers explicitly accept Chrome then Dia as OpenCode Auto behavior and the possible Dia Safe Storage prompt.
2. Keep Dia manual-only
   Close or retarget the PR if maintainers decide the browser selector should ship before any non-Chrome OpenCode Auto default.
3. Gate behind explicit browser choice
   Retarget the work toward a user-selectable browser setting if maintainers want Dia support without changing the existing automatic default.

Next step before merge

• [P2] The remaining action is maintainer product approval for the auth/privacy default, not an automated repair.

Security
Cleared: No supply-chain or secret-handling regression was found; the security-sensitive part is the bounded Keychain/browser prompt behavior, tracked as a merge risk.

Review details

Best possible solution:

Land a maintainer-approved bounded default if Dia should be automatic for OpenCode; otherwise keep Chrome-only Auto and leave Dia to Manual Cookie until an explicit browser selector exists.

Do we have a high-confidence way to reproduce the issue?

Yes from source, but not from a live Dia setup. Current main routes OpenCode web Auto through automaticImportOrder(provider:), which returns [.chrome] for .opencode; AGENTS.md prevents unrequested live Keychain/browser validation that could prompt.

Is this the best way to solve the issue?

Unclear as a product choice. The patch is a narrow implementation of a bounded Chrome-then-Dia default, but the PR body correctly asks maintainers to decide whether that privacy/auth default should change.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against c3d33308ac06.

Label changes

Label changes:

• add P2: The PR is a normal-priority provider auth improvement with a manual-cookie workaround and an explicit product decision pending.
• add merge-risk: 🚨 compatibility: Existing users with Dia installed may see a new Dia Safe Storage prompt after Chrome is unavailable or unusable.
• add merge-risk: 🚨 auth-provider: Changing OpenCode Auto cookie-source order can change where session cookies are discovered and which provider auth path runs.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Owner-authored draft decision PR; the external contributor proof gate does not apply, and the PR body reports focused tests without live Keychain reads.

Label justifications:

• P2: The PR is a normal-priority provider auth improvement with a manual-cookie workaround and an explicit product decision pending.
• merge-risk: 🚨 auth-provider: Changing OpenCode Auto cookie-source order can change where session cookies are discovered and which provider auth path runs.
• merge-risk: 🚨 compatibility: Existing users with Dia installed may see a new Dia Safe Storage prompt after Chrome is unavailable or unusable.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Owner-authored draft decision PR; the external contributor proof gate does not apply, and the PR body reports focused tests without live Keychain reads.

Evidence reviewed

What I checked:

• Current main hardcodes OpenCode web Chrome-only: OpenCodeWebCookieSupport.automaticImportOrder only returns the provider metadata order for OpenCodeGo and otherwise returns [.chrome]. (Sources/CodexBarCore/Providers/OpenCode/OpenCodeWebCookieSupport.swift:53, c3d33308ac06)
• Prior scoped OpenCodeGo fix: git show confirms c42bdeb changed OpenCode web cookie support to use provider metadata only for OpenCodeGo and added a test preserving regular OpenCode Chrome-only behavior. (Sources/CodexBarCore/Providers/OpenCode/OpenCodeWebCookieSupport.swift:53, c42bdeb43e0d)
• PR scopes Keychain preflight by browser: The proposed head calls chromiumKeychainRequiresInteraction(for: browser) and falls back to global labels only when a browser exposes no specific safeStorageLabels. (Sources/CodexBarCore/BrowserCookieAccessGate.swift:66, 063eed0f29f2)
• PR adds bounded OpenCode browser order: The proposed head adds ProviderBrowserCookieDefaults.opencodeCookieImportOrder as [.chrome, .dia] and makes OpenCode web use provider metadata. (Sources/CodexBarCore/Providers/Providers.swift:226, 063eed0f29f2)
• Linked canonical issue remains open: The PR body identifies the open OpenCode Dia cookie-import issue as the decision target, and GitHub search found this PR as the only open PR for that central problem.
• No maintainer notes found: The repository has .agents skills but no .agents/maintainer-notes files to apply for these touched paths.

Likely related people:

• steipete: Authored the prior OpenCodeGo browser-order split, authored the BrowserCookieAccessGate suppression commits, and opened this decision PR. (role: recent area contributor and decision owner; confidence: high; commits: c42bdeb43e0d, b901f1b1716b, 077eef071bb9; files: Sources/CodexBarCore/Providers/OpenCode/OpenCodeWebCookieSupport.swift, Tests/CodexBarTests/BrowserCookieOrderLabelTests.swift, Sources/CodexBarCore/BrowserCookieAccessGate.swift)
• Ratul Sarna: Repository history shows Ratul Sarna added OpenCode Go support and later worked on OpenCode workspace auth fallback handling, both adjacent to the shared OpenCode web cookie support path. (role: shared OpenCode/OpenCode Go area contributor; confidence: medium; commits: 31bd4812d227, 20784e00eaed; files: Sources/CodexBarCore/Providers/OpenCode/OpenCodeWebCookieSupport.swift, Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift, Sources/CodexBarCore/Providers/OpenCode)
• anthnykr: Repository history shows anthnykr added the original OpenCode usage provider and then improved the OpenCode usage fetcher/logging shortly after. (role: introduced OpenCode web provider; confidence: medium; commits: 69e1443e2713, 18e8c8ea45a3, dbd63d2fa563; files: Sources/CodexBarCore/Providers/OpenCode/OpenCodeProviderDescriptor.swift, Sources/CodexBarCore/Providers/OpenCode/OpenCodeCookieImporter.swift, Sources/CodexBarCore/Providers/OpenCode/OpenCodeUsageFetcher.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.