Repository navigation
GitLab Duo workflow fails on self-managed instances #50843
Description
Description
GitLab Duo workflow models do not work correctly with a self-managed GitLab instance.
I found two issues while testing this:
- Duo workflow models need the current working directory and GitLab project/namespace context.
- If the stored GitLab OAuth token is expired and the refresh fails, provider initialization throws and can prevent OpenCode from starting.
I reproduced the OAuth failure with an expired credential where the refresh endpoint returned invalid_grant.
Plugins
None
OpenCode version
0.0.0-dev-202609112115
Steps to reproduce
-
Configure OpenCode to use a self-managed GitLab instance:
$env:GITLAB_INSTANCE_URL = "https://gitlab.example.com" $env:GITLAB_HOST = "https://gitlab.example.com"
-
Authenticate OpenCode with GitLab OAuth and configure GitLab Duo.
-
Start OpenCode using the GitLab Duo workflow model:
opencode -m gitlab/duo-workflow`
-
On a self-managed GitLab instance, start a GitLab Duo workflow and observe that the workflow does not receive the working directory and project/namespace context required for the current repository.
-
Let the stored GitLab OAuth credentials expire or make the refresh token invalid/revoked, then start OpenCode again.
-
OpenCode attempts to refresh the expired GitLab OAuth token. If GitLab returns
invalid_grant, provider initialization throws and OpenCode can fail to start. -
Removing the expired GitLab entries from
auth.jsonallows OpenCode to start again. Re-authenticating restores GitLab access.
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
Windows Terminal / PowerShell 7
Activity
github-actions commentedon Sep 23, 2026
This issue might be a duplicate of existing issues. Please check:
invalid_grantand require re-authentication — this overlaps with your second reported issue (expired token causing OpenCode to fail to start).invalid_grant— same failure mode as what you observed.If your OAuth startup failure is the same as #50759 or #49439, it may be worth adding your reproduction details there. The context-passing issue for self-managed instances may be distinct enough to stand on its own.
guillermovc commentedon Sep 24, 2026
I had that problem too, both on Linux and Windows
cazaroni commentedon Sep 25, 2026
I came across this issue as well while running Arch Linux under WSL. Seems like I had similar behavior with GitLab Duo on a self-managed GitLab instance, so that would seem to indicate the issue is OS-agnostic.
KarolBurrola commentedon Sep 25, 2026
I had some issues with it too, and couldn’t get everything to work properly
l22330896-arch commentedon Sep 25, 2026
Had a rough time getting this working on Windows too, ended up stuck on the same problems.
ana-chenoweth commentedon Sep 25, 2026
It also didn’t work correctly for me, the same issues on Windows 11, I tried re-authenticating, but I still couldn't get it working
GikAvecLeStik commentedon Sep 25, 2026
I can confirm this as well. The missing working directory and project/namespace context prevents the Duo workflow from having the repository context it needs. I also confirmed that an expired or invalid GitLab OAuth credential returning
invalid_grantcan cause provider initialization to fail and prevent OpenCode from starting.Removing the expired GitLab credentials from
auth.jsonand re-authenticating resolves the startup issue, which confirms that the OAuth refresh failure is the cause.elba505 commentedon Sep 25, 2026
I ran into the same issue on Windows 11. Tried several fixes and configuration changes without success. Haven't found a reliable workaround yet. If anyone has additional troubleshooting ideas, I'd appreciate the suggestions.
CarlosMancillas commentedon Sep 25, 2026
I had the same problem everyone is having: it's not working on Windows 11. I tried re-authenticating to double-check that it was not that, but it still didn't work.
trujillocharlotte0-oss commentedon Sep 25, 2026
I’ve been seeing the same behavior on my end. Tried a few things but couldn’t get it to work as expected.
rekram1-node commentedon Oct 3, 2026
I'm realizing now the agent stuff is kinda weird, are gitlab users wanting to use the duo agent? OR are you mostly just wanting to use duo models in opencode agent?
MJVNOR commentedon Oct 3, 2026
We want to use gitlab dúo models on opencode, whi the merge request that's i propuse is working for opencode v1
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report and for working on a fix in #50844, @MJVNOR!
This was reported against OpenCode v1 (
0.0.0-dev-202609112115, a build from before v2 became the main line). v1 now only gets fixes for critical bugs such as data loss, security problems, or breakage with no workaround. This one has a workaround (removing the GitLab entries fromauth.jsonand logging in again), so it's unlikely to be fixed in v1.We'd encourage you to try v2 (
@opencode/cli). Its GitLab provider was rewritten and, going by the code:Related:
devmoved to v2If you see the same problem on v2, or you think this is critical, please reply here with your v2 version and what happens.
opencodejr commentedon Oct 29, 2026
Closing this as not planned. It was reported against OpenCode v1 (
0.0.0-dev-202609112115), which only gets critical fixes, and the expired-token startup failure has a workaround: remove the GitLab entries fromauth.jsonand log in again. Thanks again for the report and for the work in #50844, @MJVNOR.v2 (
@opencode/cli) passes the working directory to Duo workflow models, refreshes OAuth against your self-managed instance URL, and handles failed refreshes without breaking startup. If you still see either problem on v2, please comment here with your v2 version and what happens, and we can reopen this.