Repository navigation
fix(core): explain a restricted OpenCode Console workspace - #58905
Irish-Joseph wants to merge 1 commit into
Conversation
Console answers config and inference requests with 403 Forbidden when the workspace or account itself is restricted. The client passed the raw "Workspace access denied" body through, which read like a local permissions bug, and left the connection without a status. Decode the 403 Forbidden body alongside the existing SsoRequired body, report the connection as restricted with the console URL, and let the inference explainer replace the raw body with the restriction. The TUI connection footer now says "Restricted" instead of "Sign in required" for this status.
|
The check, test and nix-eval suites are stuck at "action required" for this fork, so they haven't run. I ran the same steps locally and everything is green: root typecheck (all packages; the only failure is the pre-existing @opencode/app Windows symlink artifact, identical on untouched dev), sdk-docs (0 problems), ast-grep, and the core plugin + integration suites (420 tests, 0 failures). Would a maintainer be able to approve and run the workflows? Thanks. |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
The core change works. On the base, a Console config 403 {"_tag":"Forbidden"} leaves the connection status unset; with this PR it becomes restricted and the inference 401/403 is rewritten, while other providers are left alone. I checked this by running your new test in provider-opencode.test.ts against the base, where it fails, and against this branch, where the whole file passes. I didn't drive the TUI, so could you add before/after screenshots of the "Restricted →" footer?
Public API: Connection.Status.status goes from "needs_auth" to "needs_auth" | "restricted" in @opencode/schema, the HTTP API / OpenAPI and the generated client ConnectionStatus. It's additive, but clients that assume every status is needs_auth will now see a new value.
Concerns:
packages/protocol/openapi.jsonwasn't regenerated:bun run check:generatedinpackages/protocolfails on this branch (it passes ondev). The clienttypes.tslooks hand-edited. Please runbun run generateinpackages/protocoland then inpackages/client(AGENTS.md says not to edit generated client files directly).- The message and recovery path say signing in again can't help, but the reporter's follow-up on #58891 says signing in again fixed it (see inline).
Related: #55995
| orgId: Schema.String, | ||
| connectionId: Schema.String, | ||
| }) | ||
| // Console's 403 when the workspace or account itself is restricted; re-authenticating cannot help. |
There was a problem hiding this comment.
This comment, the Connection.Status doc ("signing in again cannot help") and the TUI action (clicking a restricted connection opens /console instead of the reconnect flow) all assume signing in can't fix this. But in the follow-up on #58891, the reporter says the 403 was tied to the stored API-key credential, and opencode auth login opencode --method device fixed it right away while the old credential still got the 403. As it stands, users are sent to the console page but not told the one step that worked. Could the message (and restricted handling in dialog-integration.tsx) also suggest signing in again or replacing the credential, e.g. "…restricted. Sign in again with opencode auth login opencode or check it at "?
Issue for this PR
Closes #58891
Type of change
What does this PR do?
When OpenCode Console restricts the workspace or account, it answers both the config fetch and inference with
403 {"_tag":"Forbidden"}/{"type":"permission_error","message":"Workspace access denied"}. The client had no branch for that body: the config 403 fell through to the generic "failed to load provider config" warning with no connection status, and the inference body was passed through raw, so the TUI/CLI showed the bare "Workspace access denied" that reads like a local permissions bug.This extends the pattern #51847 set up for the SSO case:
Connection.Statusgains arestrictedvariant (client types regenerated). The TUI connection footer now says "Restricted →" for it, and clicking opens the console URL where the workspace can be checked.How did you verify your code works?
provider-opencode.test.tswith the issue's exact bodies: the connection status is{ status: "restricted", message: "Your OpenCode Console workspace is restricted", url: "<server>/console" }, inference rejections are rewritten from the rawpermission_errorbody to the restriction, and non-Console providers are untouched. Without the fix the test fails — the status isundefined._tag403 bodies still leave the status unset.@opencode/appWindows symlink artifact (identical on untoucheddev).sdk-docs0 problems,ast-grepclean.Screenshots / recordings
Not a UI change beyond the connection footer wording ("Restricted →" for the new status).
Checklist
Added by the opencode bot (AI-generated).
Related: #55995
Public API: adds the
restrictedvalue to Connection.Status.status in the schema, HTTP API and client types (additive; clients that only handleneeds_authsee a new value)