Repository navigation
[feat] Support OpenCode agent and GitLab as git provider #303
Description
Is your feature request related to a problem? Please describe.
Our team uses OpenCode as the AI coding agent and GitLab (self-hosted) as our git platform. Currently TeamAI CLI only supports Claude Code / Codex / CodeBuddy / WorkBuddy as agents, and GitHub / TGit / CNB as git providers. We'd like to use TeamAI's harness management with our existing toolchain.
Proposed Feature
1. OpenCode Agent Support
Add OpenCode (https://github.com/opencode-ai/opencode) as a supported agent, so that teamai pull can inject skills/rules/docs into OpenCode's configuration format, and hooks (SessionStart, etc.) work in OpenCode sessions.
2. GitLab as a Git Provider
Add GitLab (both gitlab.com and self-hosted instances) as a supported git provider, covering:
teamai init— OAuth / token-based auth for GitLabteamai push— create branch + MR via GitLab APIteamai pull— fetch and merge from GitLab remote- CI MR-extract — work with GitLab webhook / pipeline events
Alternatives Considered
- Issue feat: support self-hosted private Git repositories via a generic provider #300 mentions a "generic provider" approach. A generic GitLab adapter would partially or fully address this request.
- We could maintain a fork with GitLab/OpenCode patches, but upstream support would benefit the wider community.
Environment
- AI Agent: OpenCode (latest)
- Git Platform: GitLab (self-hosted, v17.x)
- OS: macOS / Linux
Additional Context
OpenCode has a plugin/extension system and its own config format (.opencode/opencode.jsonc). The integration would need to map TeamAI's harness resources (skills, rules, docs) to OpenCode's conventions.
For GitLab, the MR workflow maps naturally to GitLab's Merge Request API — the main difference from GitHub is the API endpoints and auth mechanism (Personal Access Token or OAuth2).
Activity
Walternater commentedon Aug 21, 2026
+1 — our team also needs a GitLab provider. Adding some source-level observations from v0.20.0 that may help whoever picks this up:
providerfield inteamai.yamlis currentlyz.enum(["tgit", "github"]); the schema and the defaulting logic (providerName ?? getDefaultProvider(...), defaults totgitfor backward compat) both need extending.providers/<name>/(existing:tgit,github,cnb), so aproviders/gitlab/would slot in cleanly. Thecnbmodule already demonstrates supporting a self-hosted host via an env var (TEAMAI_CNB_HOST/TEAMAI_CNB_HOSTfallback logic) — aTEAMAI_GITLAB_HOSTwould cover self-hosted GitLab instances the same way.mrUrl.includes("github.com")outside the provider modules; those need to be pulled behind the provider interface as part of this work.git clone, so a GitLab remote clones fine — what breaks afterwards is member registration, MR interop, and status reporting, i.e. exactly the provider surface.If this doesn't get scheduled soon, we'd also be happy to put together a PR draft following the existing
providers/<name>/structure.jeff-r2026 commentedon Aug 24, 2026
Several recently merged PRs implement large parts of this request:
OpenCode agent support
feat(opencode): sync skills/rules/subagents/MCP into OpenCode config (both scopes). Syncs all four resource types into OpenCode's native config in both user (~/.config/opencode/) and project (.opencode/) scopes. Note: OpenCode hooks (SessionStart, etc.) are intentionally deferred to a follow-up PR.GitLab git provider
feat(providers): add GitLab provider supporting self-hosted instances. Newproviders/gitlab/module (matching the existingproviders/<name>/layout suggested above), coveringinit,push/MR creation, MR fetch, and org repo listing, with self-hosted support viaGITLAB_URL/TEAMAI_GITLAB_HOST.fix(gitlab): stop leaking the PAT (SSRF-scoped MR fetch, header-based clone auth). Security follow-up to feat(providers): add GitLab provider supporting self-hosted instances #307.Related (generic-provider alternative)
feat(git): support generic private repository hosts, addressing the "generic provider" approach referenced from feat: support self-hosted private Git repositories via a generic provider #300.Keeping this issue open until OpenCode hooks land, which is the remaining piece.
Walternater commentedon Aug 25, 2026
Quick follow-up — between forking my work and opening the PR, the upstream GitLab provider shipped in 0.21.0-beta.0 (much more complete than what I'd drafted: 5 files, http.extraHeader to avoid token persistence in .git/config, reviewer_ids resolution, listOrgRepos, GITLAB_URL support). So I scrapped the duplicate implementation and PR'd only the genuinely missing piece: an opt-in live smoke test under
src/__tests__/e2e/gitlab-provider-live.test.tsthat mirrors the existingcnb-provider-livepattern.PR: #321
Mutating flow (create → clone → push → open-MR) was verified manually against git.guazi-corp.com before opening the PR; the closed
!2withsha=e160899was created via the same provider code paths shipping in 0.21.0-beta.0, so this works as a regression guard for anyone running the e2e suite with a real GitLab instance.Closing out from this end — happy to help on the generic provider path (#300) if that's still on the roadmap.
test(providers/gitlab): add opt-in live smoke test against real GitLab (
feat(opencode): sync built-in and agent hooks as an OpenCode plugin (#…