fix(TUI): complete auth fix for TUI with server password (HTTP mode)

[LeonMueller-OneAndOnly]

Summary

Completes the TUI authentication fix for when OPENCODE_SERVER_PASSWORD is set and TUI starts an HTTP server, due to the --port flag being set.

Problem

PR #8179 fixed TUI authentication when using direct RPC communication, but didn't handle the case where TUI starts an HTTP server (when --port flag is used). In this scenario, the TUI would fail to authenticate against its own server.

Solution

• Extracted getAuthorizationHeader() to a shared module packages/opencode/src/flag/auth.ts

• Modified packages/opencode/src/cli/cmd/tui/thread.ts to use a custom fetch function that includes the Authorization header when an HTTP server is started with password protection

• Modified packages/opencode/src/cli/cmd/tui/attach.ts to use a custom fetch function too (if needed)

• Modified packages/opencode/src/plugin/index.ts to use a custom fetch function too (if needed)

• The fix ensures the TUI can authenticate to the HTTP server it spawns when password is set. For plugins, the base TUI command itself and the attach TUI command.

Testing

Verified with:

OPENCODE_SERVER_PASSWORD="test" bun dev . --hostname 127.0.0.1 --port 4096

Previously this would fail with Unauthorized errors. Now the TUI successfully authenticates and works as expected.

Related

• Completes fix(TUI): make tui work when OPENCODE_SERVER_PASSWORD is set #8179 (previous partial fix)
• Fixes OPENCODE_SERVER_PASSWORD in env prevents user from working in TUI #8173 (original issue)
• Fixes Failing to authenticate into web UI when username or password is set #9066 (same root issue)
• Fixes fix: Plugin client returns 401 Unauthorized when OPENCODE_SERVER_PASSWORD is set (Desktop) #8676 (duplicate issue)
• Fixes [FEATURE]: Attach to authenticated OC Server #8458 (same root cause)

This PR completes the authentication flow that was partially addressed in #8179. The previous PR only fixed the RPC communication path, while this PR fixes the HTTP server path.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[R44VC0RP]

Heads up - #9706 was just opened which identifies the same auth header issue but specifically for the plugin client in plugin/index.ts.

This PR fixes the TUI HTTP mode auth, but the plugin client at packages/opencode/src/plugin/index.ts:24-28 also needs the same treatment - it creates a client without auth headers.

Could we extend this PR to also add auth headers to the plugin client fetch wrapper? The fix would be similar to what you've done for the TUI worker.

[LeonMueller-OneAndOnly]

@R44VC0RP This PR now also includes the same authorization-header fix for the plugin client in packages/opencode/src/plugin/index.ts 👍

[0xRichardH]

Hi @LeonMueller-OneAndOnly

Great work on this PR! I tested it with a remote server and found that the opencode attach command also needs the same authentication fix.

The attach command in packages/opencode/src/cli/cmd/tui/attach.ts doesn't pass authentication headers when connecting to a remote server with OPENCODE_SERVER_PASSWORD set.
Here's the fix (you can also apply this patch):

diff --git a/packages/opencode/src/cli/cmd/tui/attach.ts b/packages/opencode/src/cli/cmd/tui/attach.ts
index 3f9285f63..3390a03f7 100644
--- a/packages/opencode/src/cli/cmd/tui/attach.ts
+++ b/packages/opencode/src/cli/cmd/tui/attach.ts
@@ -1,5 +1,6 @@
 import { cmd } from "../cmd"
 import { tui } from "./app"
+import { getAuthorizationHeader } from "../../../flag/auth"
 
 export const AttachCommand = cmd({
   command: "attach <url>",
@@ -22,10 +23,22 @@ export const AttachCommand = cmd({
       }),
   handler: async (args) => {
     if (args.dir) process.chdir(args.dir)
+
+    // If server requires authentication, create a custom fetch that includes the auth header
+    const authHeader = getAuthorizationHeader()
+    const customFetch = authHeader
+      ? ((async (input: RequestInfo | URL, init?: RequestInit): Promise<Response> => {
+          const request = new Request(input, init)
+          request.headers.set("Authorization", authHeader)
+          return fetch(request)
+        }) as typeof fetch)
+      : undefined
+
     await tui({
       url: args.url,
       args: { sessionID: args.session },
       directory: args.dir ? process.cwd() : undefined,
+      fetch: customFetch,
     })
   },
 })

Tested with:

export OPENCODE_SERVER_USERNAME=myuser
export OPENCODE_SERVER_PASSWORD=mypass
opencode attach https://my-remote-server.example.com

This completes the authentication fix for all TUI connection modes.

[LeonMueller-OneAndOnly]

@0xRichardH Thank you, that makes sense. I added another commit that resembles your patch to this PR

[LeonMueller-OneAndOnly]

@0xRichardH I have reverted the changes done by this patch, since the windows-test (the github action) is not passing anymore after applying it. Not sure if this is a reproducible issue and/or a flaky windows test build. Sadly I have no windows computer to investigate. A separate pull request would be good for this in my opinion.

[LeonMueller-OneAndOnly]

Okay, even after revertig the windows check does not pass. Since it passed in the commit before, I am pretty sure this I either an error in the current dev branch and/or a flaky test.

Does a maintainer/collaborator have more insights regarding this?

[LeonMueller-OneAndOnly]

So final verdict from my side:

• The patch for the attach command was now reapplied after previously reverting it

• The underlying issue is present in the current dev branch

Here is a screenshot as of now to display that the windows-check is failing on the dev-branch itself currently.