Summary
Investigating my macOS generation failure exposed an inconsistent Keychain configuration: real-Chrome subprocess login omits --use-mock-keychain, while Playwright adds that switch when reopening the same profile for cookie extraction and generation.
Source inconsistency confirmed; incident causation unproven. Assessment: LIKELY-BUG / NEEDS-E2E. This needs an end-to-end test on a Mac before we call it the cause or claim a fix.
Source evidence
The gflow references below are pinned to develop commit 9b115173c44755d69ffe7bd03b999d56f543a604; these auth and launch paths are also unchanged in released v0.71.1.
My initial hypothesis about --password-store=basic was wrong: it is a Linux password-store choice, not a macOS basic-cookie backend selector. Removing gflow's explicit copy would also leave Playwright's default copy and its mock-Keychain switch in place. Existing comments attributing macOS basic-store behavior to that flag need correction.
This is distinct from the historical browser-channel diagnosis in #222. Related context: #644 and the landing failure in #756. None establishes this Keychain mismatch as the cause of my incident.
What the incident establishes, and what it does not
On macOS with v0.71.1, the direct cookie reader reported cookie_decryption_failed_falling_back_to_playwright. The fallback saw the labs-scoped __Secure-next-auth.session-token; exact-name SAPISID was absent from its full browser jar. Credits still succeeded, but migrated T2V reached /about and failed editor readiness.
That warning establishes a failure of the Python reader, not that Chrome decrypted zero cookies or that Keychain access was denied. The fallback's google_session boolean checks only exact-name SAPISID; it does not prove every Google credential was absent or expired. The evidence does not identify which launch lost SSO, which key encrypted any cookie, or whether Keychain permissions independently caused the reader warning. The installed Chrome, Playwright and browser-cookie3 versions still need recording; the primary-source versions above are not measurements of my Mac binary.
Diagnostic and conditional change
Preserve the stopped original profile. On independent copies of a freshly authenticated native-Chrome profile, with the same binary and other arguments, compare native Chrome, current Playwright defaults, and Playwright with only --use-mock-keychain removed. Keep --password-store=basic unchanged in the Playwright comparison. Exercise both the headless reader and headed editor-readiness path; record cookie names/domains/presence, settled page state and the direct-reader failure category, never secrets. Browser startup may write the profile, so do not compare sequentially on the sole original jar or open concurrent browsers on it.
If that Mac comparison confirms the cause: use the native Keychain consistently for real-Chrome profiles on Darwin, suppressing Playwright's mock-Keychain default in all readers and generation launches, including the earliest verification/preread. Scope non-Mac behavior separately. Correct the comments and make effective Keychain mode, actual executable and a sanitized reader-failure category diagnosable. Do not widen the labs-only HTTP cookie dictionary to carry Google SSO.
Reconcile this with the open login change at #767 rather than working around it. It moves login ownership to Playwright and may change this mismatch, but its recorded live scope is Windows and the current draft explicitly lacks a completed run of the shipped login path. It is not a verified Mac remedy. Making new launches consistently mock-backed would not by itself settle compatibility with existing native-Keychain profiles.
Acceptance on macOS
- Fresh native login retains the correct SSO and reaches the editor before and after the read-only headless reopen and headed generation reopen.
- Existing/mixed profiles have an explicit recovery test; removing a switch must not be described as restoring already-lost cookies.
- Supported CLI T2V and image generation, plus their queued MCP equivalents, produce and verify new output files. These share browser infrastructure but are separate surfaces to exercise. Use a build containing the migrated image implementation; released v0.71.1 lacks that path independently of auth.
No Mac E2E or functional fix is claimed here. Cookie values, account identifiers, profile paths, authentication URLs and raw incident bundles are deliberately omitted.
Summary
Investigating my macOS generation failure exposed an inconsistent Keychain configuration: real-Chrome subprocess login omits
--use-mock-keychain, while Playwright adds that switch when reopening the same profile for cookie extraction and generation.Source inconsistency confirmed; incident causation unproven. Assessment: LIKELY-BUG / NEEDS-E2E. This needs an end-to-end test on a Mac before we call it the cause or claim a fix.
Source evidence
The gflow references below are pinned to develop commit
9b115173c44755d69ffe7bd03b999d56f543a604; these auth and launch paths are also unchanged in released v0.71.1.--password-store=basic, but not--use-mock-keychain.--use-mock-keychainto choose the real or mock key source. The mock implementation supplies a testing secret.My initial hypothesis about
--password-store=basicwas wrong: it is a Linux password-store choice, not a macOS basic-cookie backend selector. Removing gflow's explicit copy would also leave Playwright's default copy and its mock-Keychain switch in place. Existing comments attributing macOS basic-store behavior to that flag need correction.This is distinct from the historical browser-channel diagnosis in #222. Related context: #644 and the landing failure in #756. None establishes this Keychain mismatch as the cause of my incident.
What the incident establishes, and what it does not
On macOS with v0.71.1, the direct cookie reader reported
cookie_decryption_failed_falling_back_to_playwright. The fallback saw the labs-scoped__Secure-next-auth.session-token; exact-nameSAPISIDwas absent from its full browser jar. Credits still succeeded, but migrated T2V reached/aboutand failed editor readiness.That warning establishes a failure of the Python reader, not that Chrome decrypted zero cookies or that Keychain access was denied. The fallback's
google_sessionboolean checks only exact-nameSAPISID; it does not prove every Google credential was absent or expired. The evidence does not identify which launch lost SSO, which key encrypted any cookie, or whether Keychain permissions independently caused the reader warning. The installed Chrome, Playwright and browser-cookie3 versions still need recording; the primary-source versions above are not measurements of my Mac binary.Diagnostic and conditional change
Preserve the stopped original profile. On independent copies of a freshly authenticated native-Chrome profile, with the same binary and other arguments, compare native Chrome, current Playwright defaults, and Playwright with only
--use-mock-keychainremoved. Keep--password-store=basicunchanged in the Playwright comparison. Exercise both the headless reader and headed editor-readiness path; record cookie names/domains/presence, settled page state and the direct-reader failure category, never secrets. Browser startup may write the profile, so do not compare sequentially on the sole original jar or open concurrent browsers on it.If that Mac comparison confirms the cause: use the native Keychain consistently for real-Chrome profiles on Darwin, suppressing Playwright's mock-Keychain default in all readers and generation launches, including the earliest verification/preread. Scope non-Mac behavior separately. Correct the comments and make effective Keychain mode, actual executable and a sanitized reader-failure category diagnosable. Do not widen the labs-only HTTP cookie dictionary to carry Google SSO.
Reconcile this with the open login change at #767 rather than working around it. It moves login ownership to Playwright and may change this mismatch, but its recorded live scope is Windows and the current draft explicitly lacks a completed run of the shipped login path. It is not a verified Mac remedy. Making new launches consistently mock-backed would not by itself settle compatibility with existing native-Keychain profiles.
Acceptance on macOS
No Mac E2E or functional fix is claimed here. Cookie values, account identifiers, profile paths, authentication URLs and raw incident bundles are deliberately omitted.