ChatGPT: authenticate in the daily browser and explicitly connect its session

[NOirBRight]

Part of #567. User-confirmed requirement: first sign-in and reauthentication must occur in the daily browser and reuse its Google / Passkey experience, rather than opening an empty dedicated profile.

Implementation candidate: a user-clicked Chromium/Chrome/Edge connector with only chatgpt.com host access sends the session through the authenticated, same-origin Runtime Settings API. The pinned browser verifies it before selecting a new account generation. The existing process/configuration remains unchanged until explicit restart. No Google credentials, passwords, Passkeys, daily profile copying, or remote debugging of the daily browser.

Acceptance:

• Reject foreign origins, missing settings sessions, malformed/foreign-domain cookies and invalid account verification.
• Preserve the old active account and process on save; load the verified generation only on explicit restart.
• Real account import/restart validation on Linux using user-authorized existing ChatGPT session data; secrets excluded from evidence.
• Extension logic rejects wrong tabs and tab-navigation races; no background collector or external destination.
• Install the proposed extension in the operator's daily browser after reviewing its permissions.
• Real extension-to-settings handoff in the daily browser, including Google/Passkey login when authentication is needed.
• Same-SHA Linux/Windows portable builds, embedded revision/source/extension/runtime hashes, and no-account-file inspection.
• Final Windows core and follow-up environment qualification: 3744 passed / 70 skipped; three fresh-checkout missing-runtime failures resolved by preparing the same embedded runtime, then the whole runtime module passed 118 / 3 skipped. Windows Rust/clippy passed.
• Real daily-browser acceptance on Windows.

The extension requires a one-time user installation. The selected browser UX is accepted; extension deployment and real browser acceptance remain open. See ADR-0018 in the implementation branch. This issue must not auto-close from a code-only merge.

Candidate: a6d6b79b6161a3381b0a26dbfbd84750a55393c5, PR #593 stacked on #591. Linux final Python core 3602 passed / 196 skipped; Linux Rust 799 passed / 1 ignored; Windows Rust 787 passed / 3 ignored. Real isolated Chromium popup handoff with synthetic cookies passed. Windows rejection reset reproduced 5/30 before fix, then 20/20 passed after consuming the bounded request body before origin rejection. The final portable files and Chinese test instructions are in Downloads/CodexHub-test-a6d6b79b on AM01S and Yoga. No formal release or production replacement.

[NOirBRight]

ADR + throwaway UI prototype captured per the explicitly invoked prototype skill.

Accepted decision: coding/tool capability is the only setup completion target. Reuse the daily-browser account and saved credentials; prepare Tunnel + ordinary API key; save immediately and instruct manual component restart; separately check runtime; authorize the connector; require a real harmless tool roundtrip in the eventual implementation. Text-only success does not finish setup.

• ADR-0019, decision commit 4ca4662c.
• Prototype branch, prototype commit db445a58.
• Prototype source and run/inspection notes.
• Run from the branch root: npm run prototype:chatgpt-setup --prefix frontend; visit http://127.0.0.1:43127/?variant=A (or B/C).

Question awaiting user feedback: which structure makes the next action and external-page handoff clearest? A focuses on one step, B exposes the whole checklist, C places the current task alongside an external-page mock. No winner has been selected; visual layout is not yet an accepted decision.

Fast verification: manually inspected A/B/C in the T3 collaborative browser at desktop and 390px width; walked existing-account and fresh-login flows, save/manual-restart separation, blocked authorization, failed and successful simulated tool results, variant state retention, and reset while a simulated check was pending. No horizontal page overflow observed. Node syntax and diff hygiene checks passed.

Every action is in-memory simulation, not real account/tool evidence. No production config changes, restart, release, installation, merge, or real-client acceptance is claimed. Prototype stays outside main. #592 and #567 remain open; the actual real-tool probe seam still requires implementation design.

[NOirBRight]

User selected A (single-step focus) and requested a substantial visual refinement. ADR-0019 now records that structural choice; the refined visual treatment awaits feedback.

Prototype iteration: 1c1b4a98 on prototype/chatgpt-coding-wizard. Uses a light studio canvas, existing CodexHub and OpenAI SVG assets, connected five-step navigation, focused service sheet, credential preparation links and completion cues, and an explicit save/next-step footer. No production implementation or account mutations.

Browser inspection covered desktop and 390px layouts (no horizontal page overflow), logo loading, and the revised prepare/save interaction. Saving still marks credentials saved while leaving runtime inactive and manual restart pending. Node syntax and diff hygiene passed. Launch command and scenario controls remain unchanged.

[NOirBRight]

Design finalized by the user: “OK，我没有问题了，定稿”.

Approved reference: refined A / single-step focus at 1c1b4a98, preserved on prototype/chatgpt-coding-wizard. ADR-0019 and prototype notes now record final approval (4add389f).

Implement this design: light studio canvas, deep-green primary actions, CodexHub/ChatGPT marks, connected five-step navigation, a focused service sheet, credential preparation links/readiness cues, and explicit save/next-step footer. B/C are historical alternatives, not open design choices. Remove prototype controls and dummy actions in production.

Flow stays account → Tunnel/API key → manual restart and separate runtime check → connector authorization → real tool roundtrip. Save returns immediately and never restarts or waits for restart. Existing credentials are reused. Only complete coding/tool capability satisfies setup.

Visual approval is complete. Production implementation and real integration acceptance remain outstanding; #592 and #567 stay open for those obligations. Documentation-only finalization: content inspection and git diff --check passed.