Feature Request: Support multiple OpenCode Go workspaces under a single account

[addisonwebb]

Hello! I have a feature request.

The OpenCode Go provider currently tracks usage for only one workspace at a time. I have multiple workspaces under the same account, each with its own OpenCode Go subscription, and I'd like to see limits for all of them at once.

Note: This is not a request for multi-account support (see #81). It's a single account with multiple workspaces, each holding its own subscription.

Current behavior

• In Settings → Providers → OpenCode Go, I can manually change the workspace ID and hit "Refresh" — the usage values update correctly for the new workspace.
• The same cookie/auth works across all workspaces since they share the same account.
• But there's no way to see more than one workspace at a time without manually swapping IDs.

Proposed behavior

• Discover all workspaces from the existing workspaces endpoint and track usage for each one.
• Show each workspace as a separate row/tile in the menu bar popover, labeled by workspace name, with its own 5-hour rolling and weekly usage meters and reset countdowns.
• The UI for this would need some design thought — possibly workspace-level tiles within the OpenCode Go provider section, or a sub-menu per workspace.

Thank you! I appreciate all your hard work on this tool!

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 19, 2026, 1:59 PM ET / 17:59 UTC.

Summary
Keep open: current main still resolves and renders OpenCode Go as one workspace at a time, while this request asks for a new multi-workspace fan-out and menu presentation. The closed multiple-accounts discussion is related context, but it does not supersede this same-account, multiple-workspace request.

Reproducibility: not applicable. this is a feature request, not a report of broken documented behavior. Source inspection provides high-confidence evidence that current main still models OpenCode Go as one workspace at a time.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Needs maintainer product/UI direction before a safe implementation can choose the menu layout, workspace identity model, and whether workspace fan-out should be automatic or configurable.

Review details

Best possible solution:

Add a maintainer-approved OpenCode Go workspace fan-out that discovers workspace IDs/names, fetches each workspace with provider-siloed cookies, and renders them through shared multi-row menu patterns with parser and menu-model coverage.

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

Not applicable: this is a feature request, not a report of broken documented behavior. Source inspection provides high-confidence evidence that current main still models OpenCode Go as one workspace at a time.

Is this the best way to solve the issue?

Unclear until maintainers choose the UI and data model. The requested endpoint discovery is plausible, but the maintainable path should fit shared provider/menu patterns instead of bolting on a one-off OpenCode Go surface.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The OpenCode workspaces endpoint shape and workspace-name extraction need confirmation before implementation because current code only consumes IDs.
• Menu layout is a product decision: reusing token-account rows, adding workspace tiles, or adding a workspace sub-section each creates different UX and data-model tradeoffs.

Codex review notes: model internal, reasoning high; reviewed against 7ffad6b5a4bf.

Label changes

Label changes:

• add P3: The item is a provider UX feature request with limited blast radius rather than a broken existing workflow.
• add impact:other: The request affects maintainer-visible provider usage coverage for users with multiple OpenCode Go workspaces.
• add issue-rating: 🌊 off-meta tidepool: 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.

Label justifications:

• P3: The item is a provider UX feature request with limited blast radius rather than a broken existing workflow.
• impact:other: The request affects maintainer-visible provider usage coverage for users with multiple OpenCode Go workspaces.

Evidence reviewed

Acceptance criteria:

• swift test --filter OpenCodeGoUsageParserTests
• swift test --filter OpenCodeGoMenuCardModelTests
• swift test --filter ProviderSettingsDescriptorTests

What I checked:

• Repository policy read: AGENTS.md was read fully; its provider-siloing, read-only, and focused provider-test guidance applies to this review. (AGENTS.md:1, 7ffad6b5a4bf)
• Vision fit requires sign-off: VISION.md frames CodexBar as provider limit/reset-window coverage, but marks new features and provider additions with UI/auth/privacy implications as sign-off work. (VISION.md:1, 7ffad6b5a4bf)
• Fetcher chooses one workspace: fetchUsage uses one normalized override or calls fetchWorkspaceID, then fetches usage for that single workspace ID. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift:130, 7ffad6b5a4bf)
• Workspace discovery returns the first ID: fetchWorkspaceID parses workspace IDs from the endpoint but returns ids[0], so current main does not fan out across every workspace. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift:311, 7ffad6b5a4bf)
• Snapshot model is single-workspace: OpenCodeGoUsageSnapshot stores scalar rolling, weekly, monthly, balance, and reset fields with no workspace list/name dimension. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageSnapshot.swift:3, 7ffad6b5a4bf)
• Settings expose one workspace override: The provider UI exposes one Workspace ID field and SettingsStore persists one provider-level opencodegoWorkspaceID. (Sources/CodexBar/Providers/OpenCodeGo/OpenCodeGoProviderImplementation.swift:81, 7ffad6b5a4bf)

Likely related people:

• ratulsarna: Commit 31bd481 introduced OpenCode Go provider support across the fetcher, settings, descriptor, snapshot, and parser tests; ratulsarna also reviewed workspace-dashboard PR context. (role: introduced behavior / adjacent reviewer; confidence: high; commits: 31bd4812d227; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift, Sources/CodexBar/Providers/OpenCodeGo/OpenCodeGoProviderImplementation.swift, Sources/CodexBar/Providers/OpenCodeGo/OpenCodeGoSettingsStore.swift)
• sopenlaz0: PR history for fix: read OpenCode Go usage from local data #1021 shows recent OpenCode Go local usage work touching the provider descriptor, usage fetcher, and focused tests. (role: recent area contributor; confidence: medium; commits: 7754035e6bb5; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoLocalUsageReader.swift, Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift, Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift)
• steipete: Peter landed workspace-specific dashboard behavior on main after Fix OpenCode Go Usage Dashboard link to open workspace-specific URL #667 and has recent release/history touches around OpenCode Go. (role: recent area contributor / merger; confidence: medium; commits: 61177d789088, 06fea2c897cc; files: Sources/CodexBar/Providers/OpenCodeGo/OpenCodeGoSettingsStore.swift, Sources/CodexBar/StatusItemController+Actions.swift, CHANGELOG.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.

[steipete]

I prepared a bounded decision brief in draft PR #1806. It recommends automatic all-workspace fan-out with shared credentials, stacked cards, per-workspace failure isolation, and the existing override retained as a single-workspace filter.

The remaining blocker is real and explicit: current discovery proves workspace identifiers, not a stable display-name contract, and active PR #1788 overlaps the parser/snapshot implementation surface. The draft defines the authenticated redacted proof, packaged screenshots, and exact acceptance tests required before implementation. Keeping this issue open for the maintainer choice between automatic fan-out and settings-selected workspaces.