Gitlab Duo Support

[shaheislam]

https://about.gitlab.com/gitlab-duo-agent-platform/

[clawsweeper]

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

Summary
The issue is not already implemented: current main has no GitLab/GitLab Duo provider ID, descriptor, implementation, docs entry, or matching related PR. It should stay open, but it needs maintainer/product scoping before implementation because the issue body is only a link and does not define the data source or desired CodexBar behavior.

Reproducibility: not applicable. this is a new provider support request, not a bug with an existing behavior contract to reproduce. Source inspection confirms current main does not have a GitLab Duo provider path.

Ways to help us reproduce this

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

Next step
The next action is maintainer/product clarification, not an autonomous fix PR, because the GitLab Duo source and desired behavior are undefined.

Review details

Best possible solution:

Keep the request open and turn it into a scoped provider proposal that names the GitLab Duo data source, auth/session model, quota or status fields, and the CodexBar UI/CLI behavior to add.

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

Not applicable; this is a new provider support request, not a bug with an existing behavior contract to reproduce. Source inspection confirms current main does not have a GitLab Duo provider path.

Is this the best way to solve the issue?

No; the one-link request is not yet the best implementation plan because it does not identify the GitLab Duo data source, auth/session model, or output fields CodexBar should show. The maintainable path is to scope those details first, then follow docs/provider.md with focused provider tests and docs.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The issue body only links GitLab Duo, so it does not define whether CodexBar should show Duo usage limits, GitLab credits, agent status, external-agent integration state, or another surface.
• A provider implementation would likely need new auth/config handling; AGENTS.md specifically requires keeping provider identity and plan data siloed.

Codex review notes: model internal, reasoning high; reviewed against 18eab6b68e3e.

Label changes

Label changes:

• add P3: This is a low-urgency new provider/integration request with no broken existing workflow or regression evidence.
• add impact:auth-provider: The issue is about adding a new provider/auth integration surface to CodexBar.
• 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: This is a low-urgency new provider/integration request with no broken existing workflow or regression evidence.
• impact:auth-provider: The issue is about adding a new provider/auth integration surface to CodexBar.

Evidence reviewed

What I checked:

• Repository policy read: The full target AGENTS.md was read; its provider-siloing and no-live-Keychain-probe guidance is relevant to any provider request review. (AGENTS.md:1, 18eab6b68e3e)
• Provider authoring boundary: The provider guide says provider IDs are compile-time UsageProvider enum cases and adding a provider requires a descriptor, fetch pipeline, app implementation, tests, and docs. (docs/provider.md:29, 18eab6b68e3e)
• Supported provider overview: The providers overview says CodexBar currently registers 53 provider IDs and lists current strategy rows; GitLab Duo is not listed. (docs/providers.md:8, 18eab6b68e3e)
• No GitLab provider enum case: UsageProvider enumerates providers from codex through chutes, with no GitLab or GitLab Duo case. (Sources/CodexBarCore/Providers/Providers.swift:5, 18eab6b68e3e)
• No GitLab descriptor registration: ProviderDescriptorRegistry maps every UsageProvider case to a descriptor and has no GitLab/GitLab Duo descriptor. (Sources/CodexBarCore/Providers/ProviderDescriptor.swift:55, 18eab6b68e3e)
• No GitLab app implementation registration: ProviderImplementationRegistry exhaustively maps provider cases to app implementations and has no GitLab/GitLab Duo branch. (Sources/CodexBar/Providers/Shared/ProviderImplementationRegistry.swift:14, 18eab6b68e3e)

Likely related people:

• steipete: Current provider enum/registry blame points to Peter Steinberger, and recent history includes explicit provider registration refactors and Codex provider fixes by the same GitHub author. (role: recent provider architecture contributor; confidence: high; commits: 30506ca7f83e, 22a07ef225df, df9cb8e98079; files: Sources/CodexBarCore/Providers/Providers.swift, Sources/CodexBarCore/Providers/ProviderDescriptor.swift, Sources/CodexBar/Providers/Shared/ProviderImplementationRegistry.swift)
• mvanhorn: Authored the merged Chutes provider addition, a close analogue for adding a new provider once the data source is known. (role: recent new-provider contributor; confidence: medium; commits: de6cd3aff9f8; files: Sources/CodexBarCore/Providers/Chutes, Sources/CodexBar/Providers/Chutes)
• Yuxin-Qiao: Authored the merged Poe current balance provider and has recent provider data-shape work in the provider area. (role: recent provider contributor; confidence: medium; commits: 6d906d375d2e, 88b467a17629; files: Sources/CodexBarCore/Providers/Poe, Sources/CodexBarCore/Providers)
• hololee: Authored the merged LiteLLM provider addition, another recent example of the provider-addition path. (role: recent new-provider contributor; confidence: medium; commits: 87b1195969a7; files: Sources/CodexBarCore/Providers/LiteLLM, Sources/CodexBar/Providers/LiteLLM)

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]

Contract audit (2026-07-01, CodexBar main 24490b6434d491a5478ea6636f014744ada3cbeb): GitLab now exposes a plausible API, but this issue still needs one product decision and a real-account fixture before implementation.

What is public and verifiable:

• GitLab Credits are the usage currency for GitLab Duo Agent Platform. Other seat-based Duo features do not consume credits, so the accurate CodexBar product name would be GitLab Credits, not generic “GitLab Duo.”
• GitLab's /api/graphql schema exposes Query.subscriptionUsage(namespacePath:startDate:endDate:flowTypes:). Live schema introspection on GitLab.com reports it as Experiment, introduced in 18.5.
• Aggregate fields include creditsUsed, dailyUsage, products, monthlyCommitment, monthlyWaiver, and overage. products.flowTypes permits an Agent Platform-specific filter. GitLab's GraphQL auth contract says read_api is sufficient for queries.
• The dashboard/API data can lag by hours. Access is at the root namespace/top-level group and requires the corresponding Owner/admin authorization.

Bounded implementation shape:

• New gitlabcredits provider; GitLab base URL, root namespace, and access token settings; GitLab.com and Self-Managed support.
• Primary card: current-month credits used. Show monthly commitment used/total only when the API supplies a real finite total; show waiver/overage separately rather than inventing a misleading “remaining” percentage.
• Discover the Agent Platform flow IDs from products; do not hard-code display labels as identifiers.
• Request aggregate fields only. Do not query usersUsage.users, names, avatars, event locations, or session links. Store the minimum-scope token through CodexBar's existing token configuration path.

Missing proof/decision:

1. A sanitized subscriptionUsage response from a real top-level Owner/admin account, including product/flow IDs and commitment/waiver/overage shapes.
2. Decision: accept an experimental GitLab contract now, or wait for GA.
3. Confirm scope/name: all GitLab Credits (recommended), with Agent Platform breakdown, rather than a “Duo” quota that would incorrectly imply coverage of seat-based features.

Recommendation: keep open and target the aggregate-only GitLab Credits design after the fixture and experimental-API decision. No browser/Customers Portal scraping.

Redacted live endpoint proof (GitLab.com schema introspection, no authentication/account data)

{
  "field": "Query.subscriptionUsage",
  "status": "Experiment",
  "introduced": "18.5",
  "arguments": ["namespacePath", "startDate", "endDate", "flowTypes"],
  "aggregateFields": [
    "creditsUsed",
    "dailyUsage",
    "products",
    "monthlyCommitment",
    "monthlyWaiver",
    "overage"
  ],
  "privacySensitiveFieldsExcludedByDesign": [
    "usersUsage.users.name",
    "usersUsage.users.username",
    "usersUsage.users.events.location",
    "usersUsage.users.events.sessionLink"
  ]
}