fix(opencode): Go limits use the OpenCode Console sign-in#23606

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The implementation is a focused OpenCode usage-limits fix, but it newly reads OAuth Console credentials and account metadata from the local credential database and sends the access token to the usage service. That authentication-sensitive runtime change warrants human review despite the added tests and limited scope.

^{You can add or adjust custom eligibility rules. Learn more.}

Review in Change Stack →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: cb9629e
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9e6c0b71-2ba6-4440-9905-30437e498502

External image Commits

Reviewing files that changed from the base of the PR and between e4e61ada35ff6eb9f7dbc56497981a33b0a7355c and beb0877abf3c762614d830b843851fb7e02f6db0.

External image Files selected for processing: 3

• docs/user/usage.md
• packages/provider-opencode/src/server/status.test.ts
• packages/provider-opencode/src/server/usageLimits.ts

Limit details: You’ve used all 10 included reviews currently available.

Can confirm this on Linux with OpenCode 2.x as well: auth.json had an expired legacy opencode-go key (api_key_expired 401), causing probeFailed while the active opencode OAuth credential in opencode.db returns 200 OK with valid rolling, weekly, and monthly windows from zen/go/v1/usage. Looking forward to seeing this land!

updated the original branch, preserving @onlydole's commits and merging current main. the console oauth support, stored go key fallback, account fingerprints, and documentation remain intact. one runtime adjustment uses URL.parse so malformed metadata skips one credential instead of discarding its valid sibling. two cases in the existing status suite cover both directions. the follow-up also requires both account and organization ids for an account fingerprint; incomplete identity falls back to the token fingerprint, with a failing-first case in the same suite.

verification: the oauth case fails against current main (go-key instead of console-token); the malformed-console case fails against the original implementation (go-key instead of db-go-key). the missing-organization case also fails before its fix. all 35 status tests then pass. blacksmith vp run check:changed passed format, lint, both knip passes, five package typechecks, and the status suite. two independent source reviews approve head 9d04b403ceed3c9b5aa242abcca081fd24732bfb with no blockers.

unverified: this vm has no console oauth credential, so the signed-in provider-to-client path cannot be exercised. matching before/after limits captures below show the credentialless client only, not proof of live go limits. no ui components changed. native clients and a live multi-organization account were not exercised.

@onlydole: the existing multi-organization limitation remains a follow-up. upstream's newer usage reader sends x-opencode-org-id, and its tests assert workspace selection through it. this pr still sends only the bearer token, as disclosed in the original description; older unscoped tokens may need the header. this does not hold up the verified single-account fix.

before, main's probe, no console sign-in on this vm:

limits before, credentialless vm

after, this branch, matching data:

limits after, credentialless vm

final follow-up verification: blacksmith vp run check:changed passed again on the final head. both source reviewers approve that head. all 27 ci checks pass on the follow-up. the two older inline findings are resolved; the outside-diff incomplete-identity finding is addressed by the follow-up.

evidence images were reopened and inspected in the github comment; both render at full source resolution. git.cafe currently displays their alt text. no task-owned servers, browsers, or test workers remain running.

github directly reports final head 9d04b403ceed3c9b5aa242abcca081fd24732bfb as MERGEABLE with CLEAN merge state; git.cafe conflict observation is still pending. ready for maria's human review.

Confirming this on Linux with T3 Code server 0.1.2. Both the Windows desktop client and mobile showed OpenCode Go could not read usage.

OpenCode had an active Go API key and Console OAuth login in opencode.db, but T3’s usage reader selected a different legacy Go key from auth.json. Server traces showed repeated HTTP 401 responses from https://opencode.ai/zen/go/v1/usage.

Replacing only the legacy auth.json key with the active Go key from opencode.db restored usage reporting. No T3 source changes or database writes were needed.

This supports the stored Go key credential-selection fix in this PR.

Prepared with Codex using GPT-6.1 Sol.

Verified against a real OpenCode Console sign-in account.

Setup: Linux (CachyOS), OpenCode 2.2.0 running locally, Server URL empty. opencode.db → credential has an active opencode row with type oauth (methodID: device, metadata.server: https://opencode.ai/console). auth.json has no opencode-go entry, and OPENCODE_API_KEY is not set.

I called readOpenCodeGoUsageLimits directly with the real environment and the database opened read-only.

The numbers match OpenCode's own Limits popover for the same account.

Also confirmed: GET https://opencode.ai/zen/go/v1/usage returns 200 with the sign-in's access token whether or not the x-opencode-org-id header is sent. OpenCode 2.2.0 sends that header, but the endpoint doesn't need it.

via Claude Opus 5.5 in Claude Code

Verified in a real dev environment

partial verification only. this run does not establish that the opencode oauth fix works.

ran vp i and the real background dev server on github/main at be2ea30d2b269f1526be3fd556bc5380b4dc01b3 in /home/user/main, then stopped it before running the exact contributor head 9d04b403ceed3c9b5aa242abcca081fd24732bfb in /home/user/t3code. used separate empty development state, playwright from the repo, and /usr/bin/google-chrome.

through the web ui on each revision, added the real /home/user/t3code git repository as a project, selected codex gpt-6.1-sol, and submitted reply with exactly: provider verification ok. do not use tools or change files. both turns completed with provider verification ok. added an opencode instance through settings with an empty server url. its real health check reported installed v1.19.5 and ready.

on the pr, switched between cost, tokens, and limits, then clicked refresh limits. cost and tokens rendered real codex usage. the client received the real servers

Verified in a real dev environment

partial verification only. this run does not establish that the opencode oauth fix works.

ran vp i and the real background dev server on github/main at be2ea30d2b269f1526be3fd556bc5380b4dc01b3 in /home/user/main, then stopped it before running the exact contributor head 9d04b403ceed3c9b5aa242abcca081fd24732bfb in /home/user/t3code. used separate empty development state, playwright from the repo, and /usr/bin/google-chrome.

through the web ui on each revision, added the real /home/user/t3code git repository as a project, selected codex gpt-6.1-sol, and submitted reply with exactly: provider verification ok. do not use tools or change files. both turns completed with provider verification ok. added an opencode instance through settings with an empty server url. its real health check reported installed v1.19.5 and ready.

on the pr, switched between cost, tokens, and limits, then clicked refresh limits. cost and tokens rendered real codex usage. the client received the real servers provider status over websocket:

the codex limits error also occurs on main with this vm proxy. codex turns still complete. credentialless opencode adds no go row or spurious error.

before, main with no go credentials:

main limits without opencode go credentials

after, pr with the same credentialless setup:

pr limits without opencode go credentials

neighboring usage tabs and manual refresh on the pr:

cost tokens limits and refresh interaction

inspected both full-size screenshots and the clip. uploaded video playback and seeking passed in chrome. all 27 existing ci checks are successful. no source changes, commits, or pushes were made. both task-owned dev servers were stopped.

Not verified

this disposable vm has no opencode console oauth credential, stored go key, legacy auth.json, or OPENCODE_API_KEY. its actual opencode credential table is empty. therefore the original signed-in bug could not be reproduced on main, and live go limits, 401/403 credential fallback, account fingerprint grouping, and multi-organization behavior could not be verified on the pr. the installed opencode cli is also 1.19.5 rather than the opencode 2 sign-in described by this change. the screenshots show only the credentialless case and are not evidence of successful go limits.

native ios/android and electron desktop were not exercised. this run result is unverifiable for the changed behavior, with the neighboring web/client checks above passing. a real opencode 2 console sign-in with a go subscription is needed to finish the requested proof. no mocks, fixture credentials, or fabricated usage were used.

Follow-up on the organization header already noted here, against head 9d04b403ceed3c9b5aa242abcca081fd24732bfb:

OpenCode 2.2.0's Go usage reader sends the selected workspace in x-opencode-org-id. Its test separately identifies x-org-id as the Console header.

In one local installation, read-only requests without x-opencode-org-id returned 403 both for the T3-configured API key and the active Console OAuth token. The response bodies, effective permissions, Go entitlement and workspace binding were not established; the same request with the header was not tested. This does not show that the omitted header causes the 403, nor that this PR fails the previously reported successful account.

Two possible follow-up test cases, subject to the intended account-selection and error-reporting policy:

1. Verify the selected workspace header for a Console credential when that metadata is available, without logging the credential or workspace identifier.
2. Exercise an OAuth 403 followed by another stored credential, including a different-account case, and an eventual 403. The current head tries another credential after 401/403 and maps a final 403 to unsupported; the correct presentation and attribution need a defined policy.

This is a source inspection and a separate endpoint observation, not a run of the PR or a full security review.

Follow-up: direct-probe correction

A subsequent OAuth request with x-opencode-org-id returned Cloudflare Error 1010 with Python urllib's default user agent. The earlier 403 response bodies were not retained, so their exact source was not independently established.

With a descriptive diagnostic User-Agent, consistent with Cloudflare's 1010 guidance, the same OAuth credential returned HTTP 200 both with and without the organization header; the T3-configured API key also returned 200. This comparison does not show that the header is required for this account or that it is unnecessary for other workspaces.

The installed T3 probe still skips the active OAuth credential and prioritizes the older auth.json entry over the configured API key. Its earlier 401 trace does not identify the credential sent. No PR build or end-to-end T3 fix has been tested on this account.

The retained T3 provider snapshot reports OpenCode 2.2.0, probeFailed, and no Go windows. We have not directly tested the older Go key, so the credential behind the earlier 401 remains unverified.

Local workaround verified

After setting OPENCODE_AUTH_CONTENT to the literal empty JSON object {} on the local T3 OpenCode instance and retaining its existing OPENCODE_API_KEY, the refreshed T3 provider snapshot reported all three Go windows with no unavailable reason. The user confirmed the values, and a user-provided desktop capture shows the three windows and their reset countdowns. The legacy authentication file was not modified; no screenshot, account identifiers or usage figures are shared here. The issue comment documents the steps and scope for other users.

This verifies the workaround only for the installed T3 Nightly 0.1.4-nightly.20261028.3824 and OpenCode 2.2.0; it is not a run of this PR. The displayed usage is for the API key's workspace. OpenCode 1.x can use OPENCODE_AUTH_CONTENT for credentials, so its behavior is not established by this check.

merged current main into the existing fork branch without rebasing. head: beb0877abf3c762614d830b843851fb7e02f6db0. the conflict resolution preserves both stored go key fallback and console oauth support. the diff remains three files.

blacksmith vp run check:changed passed format, lint, both knip passes, 10 package typechecks, and 37 tests, including all 36 opencode status tests. both independent source reviewers approve this head. resolved the malformed-metadata review thread, which the existing fix and regression cases address.

new ci is pending. live signed-in opencode provider/client behavior and native clients remain unverified in this run. no ui components changed. macroscope still requests human approval.

@maria-rcks Here's a macOS run of the signed-in case you asked for on Oct 28, on head beb0877.

Setup

• macOS 27.2 (26B123), Apple silicon
• OpenCode 2.2.5 (Homebrew), signed in through the Console. The active opencode credential in opencode.db is oauth with metadata.server: https://opencode.ai/console, and the account has a Go subscription. There's no auth.json, and OPENCODE_API_KEY is not set.
• The same database also holds an older opencode-go key that has expired.
• I ran the T3 web dev server (vp run dev, isolated state), added OpenCode in Settings → Providers with an empty Server URL, and opened Usage → Limits.

Result

The PR's numbers and reset times match OpenCode's.

main:

PR head:

Tests

vp test run src/server/status.test.ts in packages/provider-opencode at beb0877: 36 of 36 pass.

Unexpected

• Main shows an error here instead of hiding the row, unlike Derpedyea's unsupported result. Since #26165 (merged Oct 30), main reads opencode.db, but only key rows. It skips the Console OAuth row and sends the expired stored Go key, which gets 401 api_key_expired, so the probe ends in probeFailed. Derpedyea ran main at b31de684d2, before #26165, with no stored Go key. The PR tries the Console sign-in first, gets a 200, and never reaches the expired key. This is the same stale-key failure pedrosatin and amixaam reported.
• x-opencode-org-id: with the Console OAuth token, GET https://opencode.ai/zen/go/v1/usage returned 200 both with and without the header. No 403s and no Cloudflare 1010. My manual requests set a descriptive User-Agent. T3's own request from the PR head also succeeded, since the windows rendered.

Not covered

Desktop and mobile clients, remote or relay connections, and a multi-organization account. This account has one organization.

via Claude Opus 5.5 in Claude Code

I re-ran the macOS check today on head beb0877.

• macOS 27.2 (26B123), Apple silicon, OpenCode 2.2.5 from Homebrew
• Signed in through the Console with OAuth, on the Go plan. No auth.json or OPENCODE_API_KEY. An expired opencode-go key is also stored.

main at 0847a448fd shows no Go windows, only "OpenCode Go could not read usage." It sends the expired stored key and gets a 401. The PR head shows Go · Session 100% left, Weekly 100% and Monthly 59%. The reset times match OpenCode's own reader, which reports 0%, 0% and 41% used.

All 36 tests in status.test.ts pass, and CI on beb0877 is green. The Console token returned 200 with and without x-opencode-org-id. I saw no 403s and no Cloudflare 1010.

Thanks @maria-rcks for carrying this. Could a maintainer vouch for and review it? Macroscope flagged the credential handling, which reads the Console OAuth token and sends it to the usage endpoint, for human approval.

I merged current main into the branch without rebasing. The new head is 0a6563d. Two changes that landed after Oct 30 conflicted:

• usageLimits.ts: #26833 moved hashing from Crypto to Digest. The sign-in fingerprint now calls Digest.sha256 with the same input as before.
• docs/user/usage.md: #29419 rewrote the Cursor sentences in the same paragraph. I kept its text and this PR's OpenCode sentences.

All 36 tests in status.test.ts and all 158 tests in packages/provider-opencode pass, and vp run check:changed passes. Nothing else changed.

One note for anyone running the suite locally. The new in-place upgrade test in driver.test.ts from #27779 reads the local OpenCode data folder, so on a Mac that's signed in to OpenCode it fails with "A local binary must not be probed over HTTP". It passes with XDG_DATA_HOME pointed at an empty folder, so CI isn't affected.

I also corrected the header name in the description. OpenCode's own reader sends x-opencode-org-id, not x-org-id.

#27166 fixes the same Console sign-in case. Here's how the two PRs differ, in case it helps with choosing one.

• Base. This PR merges cleanly with current main and keeps the fallback from #26165 to the stored opencode-go key in opencode.db. #27166 branched before #26165 and conflicts with main in usageLimits.ts. As it stands, after a 401 or 403 it falls back only to the auth.json key or OPENCODE_API_KEY.
• Org header. #27166 sends x-opencode-org-id from the credential's orgID, which matches OpenCode's own reader. This PR sends only the bearer token. Derpedyea and I both got a 200 without the header on single-org accounts. Neither PR has been tested on a multi-org account.
• Fingerprint. #27166 keys any credential that stores an orgID by the workspace alone. This PR keys a sign-in by account and org ID together, and a stored key by a hash of the key. Two people signed in to the same workspace share one limits account under #27166 and get separate ones here.
• Console address. This PR accepts a sign-in stored for https://opencode.ai/console or https://console.opencode.ai. #27166 accepts only the first.
• Docs. This PR rewrites the OpenCode limits sentence in docs/user/usage.md. #27166 leaves the line that says a Console browser sign-in doesn't report limits.

The header is the one thing #27166 does that this PR doesn't.

Thanks @onlydole for the early investigation, regression coverage, and live verification. #27166 by @Fushi500 addresses the same Console OAuth usage failure with a smaller focused change, including the workspace header, so I am closing this as a duplicate. It does not cover the legacy https://console.opencode.ai address; please open a smaller follow-up for that compatibility if it still matters.