Browser mode: login probe uses /backend-api/me (now Bearer-only) → false 'session not detected' for logged-in users

[hexsprite]

Bug

Browser mode (--engine browser with --remote-chrome) fails the login check with ERROR: ChatGPT session not detected on every run, even when the connected Chrome profile is genuinely and fully signed into ChatGPT (chat history, custom GPTs, composer all render).

Verified on v0.13.0 (latest), connecting to a remote Chrome (--remote-chrome 127.0.0.1:<port>) whose profile is logged in.

Root cause

ensureLoggedIn (src/browser/actions/navigation.ts, buildLoginProbeExpression) probes login via:

const response = await fetch('/backend-api/me', { cache: 'no-store', credentials: 'include' });
status = response.status || 0;

ChatGPT migrated /backend-api/* to Bearer-token auth. A cookie-only fetch to /backend-api/me now returns 401 for every logged-in user (the SPA attaches an Authorization: Bearer <access_token> it fetches from /api/auth/session; a bare credentials: 'include' fetch has no bearer). It is no longer a cookie-authed endpoint.

The 0.13.0 DOM fallback (appAuthenticated) only rescues cfBlocked || status===429 || status===503 || status===0 — plain 401/403 are treated as authoritative "logged out" (comment: "Plain 401/403 remain authoritative because they can mean the ChatGPT session really expired."). That assumption is now wrong: a logged-in user gets 401 unconditionally.

Reproduction (run in the logged-in ChatGPT tab's console)

await fetch('/backend-api/me',      {credentials:'include',cache:'no-store'}).then(r=>r.status)   // => 401
await fetch('/api/auth/session',    {credentials:'include',cache:'no-store'}).then(r=>r.json()).then(j=>!!j.user)  // => true

/api/auth/session is still cookie-authed and returns { user, accessToken, ... } when signed in (and {} when not).

Suggested fix

Two viable options:

A. Accept 401/403 when the DOM proves an authenticated shell. appAuthenticated already requires a visible composer and (accounts-profile-button or a history-item), which a logged-out/guest session never has, so this can't false-positive:

const apiBlocked =
  cfBlocked || status === 429 || status === 503 || status === 0 ||
  status === 401 || status === 403;   // /backend-api/* now needs Bearer; cookie fetch 401s when logged in
const ok = !loginSignals && (status === 200 || (apiBlocked && appAuthenticated));

B. Probe the cookie-authed endpoint instead — fetch('/api/auth/session') and treat 200 + body.user as logged in.

Option A is the smaller diff and keeps the existing DOM safety gate.

Environment

• oracle 0.13.0 (also reproduced on 0.8.3)
• macOS, remote Chrome via --remote-chrome, ChatGPT Plus, profile signed in
• Distinct from Browser model picker broken: ChatGPT renamed labels + thinking effort skip guard wrong for lower-tier plans #182 (that was the model-picker label rename); this is the login probe.

Happy to send a PR for option A if useful.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 11, 2026, 12:42 AM ET / 04:42 UTC.

Summary
Current main still preserves the reported false-negative path: the login probe retries plain 401/403 responses but ultimately rejects them even when the page has the strong authenticated-shell signal. The merged related work only handles Cloudflare-marked or unavailable probes, no later commit or open PR owns the remaining fix, and the issue is a narrow source-reproducible browser-auth regression.

Reproducibility: yes. at source level. Current main deterministically returns ok: false for plain /backend-api/me 401/403 responses even when its strong appAuthenticated signal is true, matching the reporter’s concrete console reproduction; this review did not run a live signed-in browser.

Next step
The defect is source-reproducible, limited to one login probe with focused tests and documentation, and requires no new feature, configuration, or product-policy decision.

Review details

Best possible solution:

Use /api/auth/session user presence as the primary cookie-authenticated signal, retain the strong composer-plus-account/history DOM fallback for transient or Cloudflare failures, and preserve explicit login-wall rejection.

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

Yes at source level. Current main deterministically returns ok: false for plain /backend-api/me 401/403 responses even when its strong appAuthenticated signal is true, matching the reporter’s concrete console reproduction; this review did not run a live signed-in browser.

Is this the best way to solve the issue?

Yes, a focused login-probe repair is the narrowest maintainable solution. Prefer validating user through /api/auth/session over broadly redefining all backend 401/403 failures, with regression coverage for genuine logout and the existing Cloudflare fallback.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A repair that accepts every 401/403 without a trustworthy secondary signal could mistake an expired or guest session for an authenticated one.
• If /api/auth/session is used, implementation and diagnostics must avoid exposing the returned access token; only the presence of a valid user should influence login state.

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

Label changes

Label justifications:

• P1: The current login gate can reject every genuinely authenticated remote-Chrome browser run before a prompt is sent.
• impact:auth-provider: The defect is in ChatGPT session-authentication detection and blocks use of the browser-backed provider.

Evidence reviewed

Acceptance criteria:

• pnpm vitest run tests/browser/pageActions.test.ts
• Run a signed-in remote-Chrome browser smoke covering the login gate, following docs/manual-tests.md and never clicking ChatGPT’s “Answer now” button
• Confirm a logged-out or auth-page fixture still produces the login-specific failure

What I checked:

• Current source reproduces the failure: The probe calls /backend-api/me with cookies, records authenticated DOM state, but excludes plain 401/403 from apiBlocked, so ok remains false despite appAuthenticated being true. (src/browser/actions/navigation.ts:544, 1c4d26cc3181)
• The behavior is intentional and test-covered: Focused tests exercise plain 401 and 403 outcomes with authenticated DOM evidence and preserve them as failed login probes, confirming the report is not based on an incidental branch. (tests/browser/pageActions.test.ts:355, 1c4d26cc3181)
• Documentation matches the failing contract: Browser-mode documentation says /backend-api/me 401/403 aborts early with the login-specific error, so current documented behavior also reflects the obsolete endpoint assumption. (docs/browser-mode.md:81, 1c4d26cc3181)
• Related fallback was only partial: Merged fix(browser): accept authenticated ChatGPT DOM when auth probe is blocked #216 introduced authenticated-DOM fallback for blocked probes; its final commit explicitly retained plain 401/403 as authoritative despite noting that a signed-in SPA may receive a Bearer-related 401. (src/browser/actions/navigation.ts:609, b0c69d3a6ecb)
• No later fix on main: No commit after the v0.13.0 release touches the probe, its focused tests, or browser-mode documentation, and current main remains aligned with the reported decision branch. (src/browser/actions/navigation.ts:608, 1c4d26cc3181)
• Canonical search found no replacement: Repository PR search found only the already-merged partial fallback PR and no open or merged follow-up implementing the remaining plain-401/403 repair.

Likely related people:

• orbitingflea: Authored the merged related PR that established the current blocked-probe fallback and focused login-probe coverage. (role: introduced authenticated-DOM fallback; confidence: high; commits: b0c69d3a6ecb; files: src/browser/actions/navigation.ts, tests/browser/pageActions.test.ts)
• steipete: Authored the earlier stale-cookie validation behavior, co-authored refinement of the fallback, and carried the present probe, tests, and docs into v0.13.0. (role: recent area contributor and releaser; confidence: high; commits: 9c0bba9dad7f, abb7c9a7d9c8; files: src/browser/actions/navigation.ts, tests/browser/pageActions.test.ts, docs/browser-mode.md)

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.