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 or '--hostname' 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 [Base TUI command]

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.

Testing [Attach command]

Terminal 1 [start server process]:
OPENCODE_SERVER_PASSWORD="test" bun dev serve --hostname 127.0.0.1 --port 4096

Terminal 2 [attach TUI to existing server]:
OPENCODE_SERVER_PASSWORD="test" bun dev attach http://127.0.0.1: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)
• Fixes OPENCODE_SERVER_PASSWORD设置时，远程启动opencode server，desktop无法连接。 #10166 (duplicate issue)

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

[Sly777]

Hey @R44VC0RP do you have any plan about this PR?

[Florosonic]

I have this promlem in my Opencode and wait PR.

[alexellis]

I have the same issue (testing with SlicerVM.com) - the idea is to run a microVM, and opencode with the repo inside.. isolated. And then to run opencode as a thin client locally for control.

This PR implies that the issue is only present when --port is given, but I get it regardless?

# SlicerVM:

OPENCODE_SERVER_PASSWORD=secret opencode web --hostname 0.0.0.0

# Mac
OPENCODE_PASSWORD=secret OPENCODE_USER=opencode opencode attach http://192.168.141.2:4096                                                                              
Unauthorized

Workaround for now is to turn auth off, but port-forwarding to a local port on the Mac means any process could potentially gain access.

Will keep an eye on this, just wanted to clarify whether I misunderstood: "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."

Since this may be using basic auth, have you also considered parsing the username/password from the URL to avoid clunky env-vars (at least as a second option?

For instance:

opencode attach http://opencode:secret@192.168.141.2:4096                                                                              

# Or:

ENV OC_URL="http://opencode:secret@192.168.141.2:4096"
opencode attach   

[LeonMueller-OneAndOnly]

Since this may be using basic auth, have you also considered parsing the username/password from the URL to avoid clunky env-vars (at least as a second option?

For instance:

This PR only aims to fix the existing issues when using the existing SERVER_PASSWORD / USER_NAME env-variables for plugins, the TUI+server starting and TUI attaching.

Adding functionality for username + password via URL-parameters is not in scope of this PR - feel free however to open another PR that builds on this. I think that is a good idea.

[imarshallwidjaja]

can devs merge this fix please ❤️

[LeonMueller-OneAndOnly]

This PR implies that the issue is only present when --port is given, but I get it regardless?

The issue is present when OpenCode starts an HTTP server alongside the TUI. This happens when either the port or hostname are provided as CLI arguments. When using the opencode web command, this is always the case.

The basic TUI regularly starts another process to run the server and communicates over RPC with this.
For this case the auth issue was already fixed by PR #8179

HTTP is only chosen as a communication protocol when needed for Web usage.

[TheOrdinaryWow]

It would be nice to support auth in desktop as well.

Currently, use the base auth style url is not permitted.

http://username:password@example.com:port

This would be simplistic method of connecting to a remote server instead of popup (that works as a workaround).

[LeonMueller-OneAndOnly]

It would be nice to support auth in desktop as well.

Currently, use the base auth style url is not permitted.

http://username:password@example.com:port

This would be simplistic method of connecting to a remote server instead of popup (that works as a workaround).

I agree that this is a sensible feature request. It is however out of scope of this PR. This one is already open for a long time, further extending the scope of this will make the review harder and therefore is not desirable imo.

[Hicsy]

will be great if this feature can make it in to one of the recent releases that have come out since.

[dhowe]

status on this?

[LeonMueller-OneAndOnly]

@rekram1-node Might I suggest bumping this up the list a touch? I realise there is no shortage of open PRs, though this does strike me as a matter of some urgency for cross-device workflows.

[Hicsy]

Thanks! I can now see that -password and $env:OPENCODE_SERVER_PASSWORD both work when attaching TUI.
Du7chManiac/agent-container#17

[SrHenry]

#8458, #10166, #8173, #9066 were automatically closed, since they were inactive for more than 3 months.
This PR is in the clutches since January and it is a letdown to see it still unmerged, and, because of a forced push to dev branch 2 weeks ago, it now has conflicts with the dev.

[alberti42]

I think the problem is that 04a2c95 was merge instead of being a rebase. Now the merge contains "millions" of lines of code when I try to distill a .patch.

I could spend time in the next days to resolve the conflicts and recreate a linear commit history for the reviewer. But is there still interest in this feature? I also think it is a pity that opencode does not take a pause and deep breath and cover the fundamentals before jumping on implementing the new features. I am not even sure what they are developing because for me, OpenCode is nearly pretty close to being perfect. Except that there are embarrassing bugs like the one raised in this PR. Just to avoid misunderstanding, I say this as a compliment to OpenCode for delivering the best coding agent.

@LeonMueller-OneAndOnly: Are you still using your fix? Did you find problems to resolve conflicts with HEAD? It would be really nice if we can fix it. Let us know if we can help you.

[LeonMueller-OneAndOnly]

@alberti42 i am no longer actively using this patched version - as i use the desktop app nowadays.

In case there is interest to merge this I will gladly to a clean rebase / redo these patches on top of the current branch

[SrHenry]

The PR's #25596 and #25600 already apply the fixes this PR was supposed to fix, and got merged 10 days ago, and released since 1.14.34.

So this PR should probably be closed, unfortunately. Quite the letdown to realize we could've been using this fix months ago.

[LeonMueller-OneAndOnly]

@SrHenry well with the flood of PR's you receive that happens - nice to know the issues are already fixed👍