Venice Web source always reports "session cookie not found" — venice.ai sign-in now uses Clerk

[LachieFREEDOM]

Summary

With Source: Web, the Venice provider reports Venice browser session cookie not found. Sign in to venice.ai in your browser. even while signed in to venice.ai in Chrome.

The Web path only recognises the __venice-auth.session-token cookie family (VeniceCookieHeader.isSessionCookieName). A fresh venice.ai sign-in no longer sets that cookie. It sets Clerk cookies instead. Because VeniceWebUsageFetcher.requireSessionCookieHeader applies the same filter, Manual cookie mode is affected too.

Environment

• CodexBar 0.65.0 (latest release); the Venice cookie code is unchanged on main at 5f70bfc
• macOS 27.0 (arm64), Google Chrome 153, default profile
• venice.ai account signed in through the website

Steps to reproduce

1. Sign in at venice.ai in Chrome.
2. In CodexBar, set Venice → Source to Web.
3. Refresh, or run codexbar usage --provider venice --source web --format json.

Expected: subscription-credit details, as added in #3474.
Actual: missingCredentials → "Venice browser session cookie not found."

Evidence

Cookie names only for venice.ai after sign-in (no cookie values were read or decrypted):

Host	Auth-relevant cookie names
venice.ai	__session, __session_<suffix>, clerk_active_<suffix>
.venice.ai	__client_uat, __client_uat_<suffix>
.clerk.venice.ai	__client (HttpOnly)
venice.ai (leftover)	__Host-authjs.csrf-token, __Secure-authjs.callback-url

There are no __venice-auth.session-token or __venice-auth.session-token.N cookies. The leftover Auth.js cookies suggest venice.ai moved from Auth.js to Clerk.

The current venice.ai web client (public JS bundle) still calls https://outerface.venice.ai/api/user/session and still validates the response as { token: string }. It now authenticates that call with Authorization: Bearer <Clerk session token> from Clerk.session.getToken(), alongside credentials: "include". An unauthenticated GET returns 401 with a JSON { "error": ... } body.

Not verified

• Whether /api/user/session accepts the Clerk token from a non-browser client, either as a Bearer header or as a __session cookie.
• Whether the returned token still carries the bundledCreditsUsage claims the parser expects.

I didn't send a real session to confirm either point. I'm happy to run a probe build if that helps.

Possible directions (your call)

1. Clearer failure (small). When Clerk cookies are present but the legacy cookie is not, report that the Venice sign-in format is unsupported. Today's "cookie not found" error sends users into sign-in loops.
2. Use __session as a Bearer token. Accept __session and __session_<suffix>, then send the value as Authorization: Bearer to /api/user/session. Clerk session tokens expire after 60 seconds, and the browser only refreshes the cookie while a venice.ai tab is active. Most background refreshes would probably hit the existing expiredSession path.
3. Mint a fresh token the way Clerk's frontend does. Use the long-lived __client cookie, which is HttpOnly and set on the Clerk frontend-API host. This is durable, but it reads a more privileged credential than the Web source reads today. That trade-off seems like a maintainer decision.

A synthetic parser test for directions 1 and 2 might look like this (fake values):

@Test
func `clerk session cookie is recognised`() {
    let raw = "__client_uat=1700000000; __session=eyJhbGciOiJub25lIn0.eyJleHAiOjB9."
    #expect(VeniceCookieHeader.header(from: raw) != nil)
}

@Test
func `legacy session cookie still wins when present`() {
    let raw = "__session=eyJhbGciOiJub25lIn0.eyJleHAiOjB9.; __venice-auth.session-token=synthetic"
    #expect(VeniceCookieHeader.header(from: raw) == "__venice-auth.session-token=synthetic")
}

Related: #3474 (Web credits), #3804 (shared browser cookie import).

[clawsweeper]

Codex review: this still needs some work. Reviewed September 24, 2026, 2:48 AM ET / 06:48 UTC.

Summary
The reported failure is credible on current main: Venice Web and Manual modes accept only the legacy session cookie, while the reporter observed only Clerk cookies after signing in. The safe authentication path remains unverified, so the issue needs a maintainer decision before an authentication change.

Reproducibility: yes. for the reported failure path: Clerk-only cookie names are rejected by both browser import and manual-cookie normalization on current main. A live authenticated Venice response has not been verified.

Maintainer decision needed

Question	Recommendation
Should Venice Web support Clerk authentication, and may CodexBar read Clerk’s longer-lived HttpOnly __client cookie if short-lived session tokens cannot support background refresh?	Verify short-lived session flow: Improve the recovery message and test a consented Clerk session against the production endpoint before adopting the least-privileged working request.

Why: The choice changes which browser credential CodexBar reads and could make an existing Web workflow depend on a more privileged, longer-lived token.

Next step
The cookie mismatch has a bounded diagnostic repair, but restoring authenticated credits requires a maintainer choice about credential scope and proof of Venice’s current endpoint contract.

Security
Needs attention: The proposed Clerk recovery routes need an explicit credential-scope decision before implementation.

Review details

Best possible solution:

Provide an in-app Venice sign-in recovery message now, then restore Web credits using the least-privileged authenticated flow that a consented live probe verifies; preserve legacy-cookie support.

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

Yes for the reported failure path: Clerk-only cookie names are rejected by both browser import and manual-cookie normalization on current main. A live authenticated Venice response has not been verified.

Is this the best way to solve the issue?

Unclear for restoring credits: recognizing __session alone does not establish that the endpoint accepts it or that the response still has credit claims. A clearer recovery message is a safe interim repair.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reporter has not verified that Venice’s session endpoint accepts a Clerk token outside the browser or still returns the credit claims CodexBar parses.
• Reading Clerk’s longer-lived HttpOnly __client credential would expand the credential and privacy boundary beyond the current Venice Web source.

Codex review notes: model internal, reasoning medium; reviewed against fec33b3bc619.

Label changes

Label changes:

• add P0: A signed-in user selecting Venice Web is blocked from its first useful credit result and receives only a repeat-sign-in instruction with no in-product recovery.
• add impact:auth-provider: The failure occurs where Venice browser authentication is converted into a session request.
• add impact:ux-release-blocker: The reported sign-in loop offers no in-product path to complete Venice Web provider setup.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P0: A signed-in user selecting Venice Web is blocked from its first useful credit result and receives only a repeat-sign-in instruction with no in-product recovery.
• impact:auth-provider: The failure occurs where Venice browser authentication is converted into a session request.
• impact:ux-release-blocker: The reported sign-in loop offers no in-product path to complete Venice Web provider setup.

Evidence reviewed

Security concerns:

• [medium] Long-lived Clerk credential access
  The suggested __client route would read a more privileged HttpOnly credential than the current Venice Web source and needs an owner-approved privacy boundary.
  Confidence: 0.9

What I checked:

• Current cookie filter: Current main recognizes only __venice-auth.session-token and numbered chunks; the reporter’s listed Clerk cookie names cannot pass this filter. (Sources/CodexBarCore/Providers/Venice/VeniceCookieHeader.swift:7, fec33b3bc619)
• Browser and manual entrypoints: Browser import filters records through the legacy cookie predicate; the manual strategy also normalizes its input through the same cookie header helper. (Sources/CodexBarCore/Providers/Venice/VeniceCookieImporter.swift:49, fec33b3bc619)
• Network and claims boundary: The fetcher sends a Cookie header to the Venice session endpoint and expects a token containing bundledCreditsUsage claims. Acceptance of a Clerk Bearer token and continued availability of those claims have not been demonstrated. (Sources/CodexBarCore/Providers/Venice/VeniceWebUsageFetcher.swift:23, fec33b3bc619)
• Released behavior: The v0.65.0 tag contains the same legacy cookie filter, and the release changelog advertises the Venice Web credit source. (CHANGELOG.md:253, 20a70d955d47)
• Feature history: The legacy cookie filter was added with the merged Venice Web credits work at commit 6f211d4. That PR explicitly said authenticated session compatibility remained unverified. (Sources/CodexBarCore/Providers/Venice/VeniceCookieHeader.swift:7, 6f211d429d72)
• Reporter observation: The issue reports a signed-in Chrome profile with Clerk cookie names but no legacy Venice session cookie. It expressly leaves authenticated non-browser acceptance and returned credit claims unverified.

Likely related people:

• 唐鳳: Raw commit 6f211d4 adds Sources/CodexBarCore/Providers/Venice/VeniceCookieHeader.swift:7 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 6f211d429d72; files: Sources/CodexBarCore/Providers/Venice/VeniceCookieHeader.swift)
• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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]

Venice’s current Web source accepts the old __venice-auth.session-token cookie and its chunks; the bundled JavaScript plugin currently serves API-key balance requests only. A Clerk-only session would not pass the Web cookie filter. To verify the replacement flow, please provide cookie names and domains only, the successful session/credits request URL and method, and a response example with credentials and personal data removed. Please do not post cookie values, JWTs, authorization headers, or a raw HAR. We have not yet verified a working Clerk fix.

[LachieFREEDOM]

Thanks for looking at this. I ran a consented probe outside the browser. It printed only status codes, key names and value types; no values were logged or kept.

Cookie names and domains: same as the table in the issue (also identical in a second Chromium browser). There's no __venice-auth.session-token cookie or chunk.

Working request:

GET https://outerface.venice.ai/api/user/session
Authorization: Bearer <value of the __session cookie>
→ 200 {"token": "<JWT>"}

The same __session value sent as a Cookie: __session=… header instead returns 401 {"error": …}. So the endpoint needs a Bearer header and ignores the cookie form.

Response (redacted): the returned token still carries the claims VeniceWebUsageFetcher parses, with the same names and numeric types:

{
  "bundledCredits": 0,
  "bundledCreditsUsage": {
    "availableCredits": 0,
    "monthlyRefillCredits": 0,
    "nextRefillAt": 0,
    "tierCap": 0,
    "usedThisCycle": 0
  }
}

(Values zeroed; other claims omitted.)

Caveat for background refresh: __session is a Clerk session JWT with a 60-second lifetime. When I read it, it had 16 seconds left. The browser only rewrites it while a venice.ai tab is active, so a background refresh will often find it expired. Swapping the cookie name (option 2 in the issue) would work only while a Venice tab is open. Anything more durable goes through Clerk's __client cookie, which is the credential-scope decision the review flagged.

I haven't changed any code. I'm happy to test a build.

[steipete]

Thanks @LachieFREEDOM; your probe established the missing authentication contract. Fixed on main via #4019 and shipping in 0.67.1: the Venice Web and Manual cookie modes now accept __session and __session_<suffix> from the Venice site and send the selected value as Bearer authentication to the existing session endpoint, with the legacy session cookies and chunks still supported and unrelated Clerk cookies excluded. One caveat the probe made clear: Clerk sessions last about a minute and refresh only while a signed-in Venice tab is active, so keep a tab open when refreshing, and Manual mode needs a freshly copied cookie. This fix deliberately does not use the longer-lived __client credential; unattended renewal would be a separate decision. Please reopen if the updated build still fails against your account.