OpenAI web refresh ignores Chrome and enumerates removed browsers on macOS 27

[justinbao19]

Summary

On macOS 27, CodexBar 0.37.2 cannot fetch Codex/OpenAI web usage even though Chrome is the only installed/signed-in browser for ChatGPT. The fetch path still enumerates previously removed browsers (ChatGPT Atlas, Comet, and Dia) while Chrome is not enumerated, then fails with either No matching OpenAI web session found in browsers. or OpenAI web dashboard fetch timed out.

This looks like stale browser discovery plus a macOS 27 browser profile / TCC compatibility issue around Chrome cookie import.

Environment

• CodexBar: 0.37.2 (build 92)
• macOS: 27 beta
• Browser state:
  • Chrome is installed and signed in to chatgpt.com
  • ChatGPT Atlas was uninstalled earlier
  • Comet was uninstalled during troubleshooting
  • User expects CodexBar to use Chrome only

What I expected

CodexBar should enumerate Chrome as an OpenAI web session source and use the signed-in chatgpt.com session to fetch Codex/OpenAI web usage extras for the active Codex account.

What happened

CodexBar does not enumerate Chrome in the OpenAI web refresh logs. It only attempts:

browser=Dia
browser=ChatGPT Atlas
browser=Comet
browser=Dia

The fetch then fails with one of:

No matching OpenAI web session found in browsers.

or:

OpenAI web dashboard fetch timed out after 20/30/45 seconds.

This continues after granting Full Disk Access to both:

• /Applications/CodexBar.app
• /Applications/CodexBar.app/Contents/Helpers/CodexBarCLI

and after quitting/restarting CodexBar.

Diagnostic commands run

/Applications/CodexBar.app/Contents/Helpers/CodexBarCLI usage \
  --provider codex \
  --source web \
  --web-timeout 20 \
  --format json \
  --pretty \
  --log-level debug

Representative output:

2026-06-25T14:43:24+0800 debug com.steipete.codexbar.browser-cookie-gate: browser=Dia [CodexBarCore] Cookie access allowed
2026-06-25T14:43:24+0800 debug com.steipete.codexbar.browser-cookie-gate: browser=ChatGPT Atlas [CodexBarCore] Cookie access allowed
2026-06-25T14:43:24+0800 debug com.steipete.codexbar.browser-cookie-gate: browser=Comet [CodexBarCore] Cookie access allowed
2026-06-25T14:43:24+0800 debug com.steipete.codexbar.browser-cookie-gate: browser=Dia [CodexBarCore] Cookie access allowed
2026-06-25T14:43:26+0800 debug com.steipete.codexbar.openai-webview: [CodexBarCore] OpenAI webview show
2026-06-25T14:43:45+0800 debug com.steipete.codexbar.openai-webview: [CodexBarCore] OpenAI webview hide
[
  {
    "error" : {
      "code" : 1,
      "kind" : "provider",
      "message" : "OpenAI web dashboard fetch timed out after 20 seconds."
    },
    "provider" : "codex",
    "source" : "web"
  }
]

Earlier runs also returned:

No matching OpenAI web session found in browsers.

diagnose output:

{
  "appVersion": "0.37.2",
  "auth": {
    "configured": false,
    "modes": []
  },
  "displayName": "Codex",
  "error": {
    "category": "unknown",
    "safeDescription": "An unexpected error occurred"
  },
  "fetchAttempts": [
    {
      "errorCategory": "unknown",
      "kind": "oauth",
      "wasAvailable": true
    }
  ],
  "platform": "macOS",
  "provider": "codex",
  "schemaVersion": "1.0",
  "settings": {
    "sourceMode": "auto"
  },
  "source": "failed",
  "sourceMode": "auto"
}

Additional observations

• Before Comet/Atlas cleanup, their local cookie databases contained OpenAI/ChatGPT cookies, but the Atlas __Secure-next-auth.session-token was expired.
• After switching to Chrome as the only intended browser, CodexBar still did not enumerate Chrome.
• Reading ~/Library/Application Support/Google/Chrome from the troubleshooting shell returns Operation not permitted; however Full Disk Access was granted to both the app and helper and CodexBar was restarted.
• CodexBarCLI is separately signed with identifier CodexBarCLI, while the main app is com.steipete.codexbar, so this may be related to helper-level TCC behavior on macOS 27.

Possible root cause

macOS 27 may have changed how browser profile directories or Keychain-backed Chromium cookie stores are protected. CodexBar's OpenAI web cookie importer appears to:

1. Keep enumerating stale/uninstalled browser sources.
2. Not enumerate Chrome even when Chrome is installed and signed in.
3. Fall back to WebKit probing that times out or cannot prove a matching signed-in OpenAI session.

Acceptance criteria

• OpenAI web refresh enumerates Chrome when Chrome is installed and signed in to chatgpt.com.
• Removed browsers such as Atlas/Comet are not preferred or repeatedly enumerated when their app/data is no longer present.
• If Chrome profile access is blocked by macOS 27/TCC, diagnostics should say that directly and name the exact bundle/helper that needs permission.
• Codex provider web extras should fetch successfully from the Chrome session or fail with a specific actionable error instead of generic timeout / no matching session.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 2:53 AM ET / 06:53 UTC.

Summary
Keep open: current main still uses the same OpenAI web browser-cookie discovery path as v0.37.2, and source/tests show a plausible gap where stale browser profile data can remain eligible while unreadable Chrome access is only surfaced as a generic failure.

Reproducibility: Source-only: the current BrowserDetection and OpenAI web importer code match the stale-profile and unreadable-Chrome failure shape, but live probing was not run because it can trigger Keychain or TCC prompts.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
This is a narrow source-level bug candidate, but live macOS 27 proof remains a maintainer-side validation step because browser-cookie probes can trigger prompts.

Review details

Best possible solution:

Keep this open and fix the candidate filtering/diagnostics for Chrome and stale browser profile data with focused tests, then ask a maintainer to smoke-test macOS 27 if possible.

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

Source-only: the current BrowserDetection and OpenAI web importer code match the stale-profile and unreadable-Chrome failure shape, but live probing was not run because it can trigger Keychain or TCC prompts.

Is this the best way to solve the issue?

Yes: a narrow repair in browser-cookie candidate filtering and OpenAI web diagnostics is the best current path; avoid new config or broad auth changes unless the source fix cannot cover macOS 27.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live macOS 27/Chrome/TCC reproduction was attempted because repository policy forbids ad-hoc validation that can trigger Keychain prompts unless explicitly requested.
• A source-level fix may still need maintainer validation on macOS 27 beta because the reported TCC behavior is platform-specific.

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

Label changes

Label changes:

• add P2: The bug blocks optional OpenAI web extras for a specific browser/macOS path while core Codex OAuth/CLI paths remain available.
• add impact:auth-provider: The failure is in OpenAI web browser-session discovery and cookie-based provider authentication.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P2: The bug blocks optional OpenAI web extras for a specific browser/macOS path while core Codex OAuth/CLI paths remain available.
• impact:auth-provider: The failure is in OpenAI web browser-session discovery and cookie-based provider authentication.

Evidence reviewed

Acceptance criteria:

• swift test --filter BrowserDetectionTests
• swift test --filter BrowserCookieOrderStatusStringTests
• swift test --filter CodexUserFacingErrorTests
• make check

What I checked:

• Repository policy read: AGENTS.md was read fully; it says browser-cookie imports and live provider probes can trigger macOS Keychain prompts, so this review used source/history checks rather than live cookie probing. (AGENTS.md:25, ada3660e9d61)
• OpenAI web candidate loop: OpenAIDashboardBrowserCookieImporter builds the OpenAI web candidate list from the Codex browser-cookie order and iterates those sources before returning no-session or access-denied errors. (Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardBrowserCookieImporter.swift:182, ada3660e9d61)
• Candidate filtering behavior: cookieImportCandidates filters by BrowserDetection.isCookieSourceAvailable and BrowserCookieAccessGate.shouldAttempt, but does not require non-Safari browsers to still have an installed app bundle. (Sources/CodexBarCore/BrowserCookieImportOrder.swift:17, ada3660e9d61)
• Chrome and stale-profile tests: BrowserDetection tests show Chrome is considered available only when the expected cookie DB exists, while Dia becomes available from leftover profile cookie data, matching the reported failure shape. (Tests/CodexBarTests/BrowserDetectionTests.swift:134, ada3660e9d61)
• No main fix after release: The central OpenAI web importer, BrowserDetection, and provider browser-order files show no relevant source diff from v0.37.2 to current main, so the reported release behavior is not already fixed there. (ada3660e9d61)
• History provenance: git history ties recent browser-cookie source detection and access-gate behavior to commits 33d1994, 501cb51, and 620a86c, which are the likely behavior lineage for this issue. (Sources/CodexBarCore/BrowserDetection.swift:67, 501cb51c210d)

Likely related people:

• steipete: Recent commits hardened browser cookie source detection and BrowserCookieAccessGate behavior in the central files for this issue. (role: recent browser-cookie detection contributor; confidence: high; commits: 33d1994f5cf4, 501cb51c210d, 2cd166facff8; files: Sources/CodexBarCore/BrowserDetection.swift, Sources/CodexBarCore/BrowserCookieImportOrder.swift, Sources/CodexBarCore/BrowserCookieAccessGate.swift)
• ratulsarna: Commit 620a86c added the current Codex browser-cookie order helper and OpenAI web importer integration that feeds the candidate list. (role: Codex browser-order feature contributor; confidence: medium; commits: 620a86c76b1a; files: Sources/CodexBarCore/Providers/Providers.swift, Sources/CodexBarCore/OpenAIWeb/OpenAIDashboardBrowserCookieImporter.swift, Tests/CodexBarTests/BrowserCookieOrderLabelTests.swift)
• Mert Can Demir: Commit 9950ada added Dia browser support, one stale browser candidate named in the report. (role: adjacent browser support contributor; confidence: medium; commits: 9950ada7c5e8; files: Sources/CodexBarCore/BrowserDetection.swift, Sources/CodexBarCore/BrowserCookieImportOrder.swift)

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.

[steipete]

Fix prepared in #1764; focused tests, packaged-app smoke testing on macOS 26.5, full local tests, and autoreview are clean. I do not have a macOS 27 VM, so could you please validate the PR branch on macOS 27 and confirm:

• Chrome is attempted when its app and ChatGPT profile are present.
• Removed Atlas, Comet, and Dia apps are no longer enumerated from leftover profile data.
• If Chrome profile access is blocked, the error names the exact CodexBar component and permission remedy instead of reporting a generic timeout.

Keeping this issue open pending macOS 27 confirmation.