cli: TUI fails to connect to password-protected explicit server via --server #49427

Activity

1. github-actions

   assigned

   simonklee

   on Sep 17, 2026
2. github-actions commented on Sep 17, 2026

   

   github-actionsBot

   on Sep 17, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • v2 serve: configured Basic Auth credentials always return 401 #45856: v2 serve: configured Basic Auth credentials always return 401 — also covers authentication failures against a password-protected opencode serve endpoint, though that issue focuses on Basic Auth always rejecting valid credentials while this one specifically identifies that the TUI --server startup path sends no credentials at all.

   If these are the same root cause, it may make sense to consolidate. If the underlying credential-sending bug in the TUI is distinct from the server-side auth rejection, both are worth tracking separately.
3. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report! I reproduced this on 2.0.5. A password-protected server answers the client's health check with a 401 that has no body, so the client can't tell it's an authentication error. Instead of saying a password is needed, it fails with the generic did not provide a compatible V2 health response ... UnsupportedContentType.

   On the latest dev (950111ff2) the server's 401 says what it is, and opencode --server <url> now fails with Server at <url> requires a password; set OPENCODE_PASSWORD. So this is likely already fixed, and the fix should be in the next release.

   On both versions, the TUI takes the password from the environment rather than from the URL. This works on 2.0.5 too:

   OPENCODE_PASSWORD=<pass> opencode --server http://127.0.0.1:4096

   If you also want URL credentials (user:pass@ or ?auth_token=) to work for the TUI, please open a separate feature request.

   Related: #55558 (docs request for server deployment and passwords).

   The bot will close this issue in 1 day unless you reply that it still happens, e.g. on a newer version.
4. opencodejr

   added

   pending close

   on Oct 28, 2026
5. alex-mashin commented on Oct 28, 2026

   

   alex-mashin

   on Oct 28, 2026

   More actions

   This is likely to be caused by #45856. It is not fixed and this is time that a human attends to the bug.
6. opencodejr

   closed this as completedon Oct 29, 2026
7. opencodejr commented on Oct 29, 2026

   

   opencodejrBot

   on Oct 29, 2026

   Contributor

   More actions

   Closing this as completed, since there's been no reply in the day since the last update. On 2.0.5, a password-protected server's 401 has no body, so opencode --server showed the generic UnsupportedContentType health-check error. On the latest dev (950111ff2) it says requires a password; set OPENCODE_PASSWORD instead, so the fix should be in the next release. Until then, setting OPENCODE_PASSWORD=<pass> in the shell where you run opencode --server lets the TUI connect.

   If this still happens on a newer version, please comment here or open a new issue. If you'd like the TUI to accept credentials in the URL, a separate feature request is welcome. Thanks for the detailed report!