anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[BUG] Plugin client missing Authorization header when OPENCODE_SERVER_PASSWORD is set #6988

New Issue
Open
opened 2026-02-16 18:05:50 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 18:05:50 -05:00
Owner
Copy Link
Copy Source

Originally created by @uf-hy on GitHub (Jan 20, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Description

When OPENCODE_SERVER_PASSWORD is set, the client passed to plugins via PluginInput does not include the Authorization header, causing all plugin API calls (like ctx.client.session.create()) to fail with 401 Unauthorized.

Steps to Reproduce

  1. Set environment variables: 
    export OPENCODE_SERVER_PASSWORD=your-password
export OPENCODE_SERVER_USERNAME=your-username
  2. Start opencode TUI
  3. Use any plugin tool that calls ctx.client.session.create() (e.g., oh-my-opencode's look_at tool)
  4. Observe: Error: Failed to create session: Unauthorized

Expected Behavior

The plugin client should include the Authorization header when OPENCODE_SERVER_PASSWORD is set, and plugin API calls should work normally.

Actual Behavior

Plugin API calls fail with 401 Unauthorized.

Analysis

I noticed that in packages/opencode/src/plugin/index.ts, the client is created without the Authorization header:

const client = createOpencodeClient({
  baseUrl: Server.url().href,
  // @ts-ignore - fetch type incompatibility
  fetch: async (...args) => Server.App().fetch(...args),  // <-- No auth header
})

However, in packages/opencode/src/cli/cmd/tui/worker.ts, the auth header IS correctly added:

const fetchFn = (async (input: RequestInfo | URL, init?: RequestInit) => {
  const request = new Request(input, init)
  const auth = getAuthorizationHeader()  // <-- Auth header added here
  if (auth) request.headers.set("Authorization", auth)
  return Server.App().fetch(request)
}) as typeof globalThis.fetch

It seems like the plugin client might need similar auth handling, but I'm not 100% sure if this is the correct fix approach.

Environment

  • opencode version: 1.1.27
  • OS: macOS
  • Plugin: oh-my-opencode 3.0.0-beta.11

Plugins

oh-my-opencode 3.0.0-beta.11

OpenCode version

1.1.27

Steps to reproduce

  1. Set OPENCODE_SERVER_PASSWORD
  2. Use oh-my-opencode plugin
  3. Call look_at tool
  4. Get 401 Unauthorized

Screenshot and/or share link

No response

Operating System

macos 26.0

Terminal

Terminal

Originally created by @uf-hy on GitHub (Jan 20, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description ## Description When `OPENCODE_SERVER_PASSWORD` is set, the client passed to plugins via `PluginInput` does not include the Authorization header, causing all plugin API calls (like `ctx.client.session.create()`) to fail with `401 Unauthorized`. ## Steps to Reproduce 1. Set environment variables: ```bash export OPENCODE_SERVER_PASSWORD=your-password export OPENCODE_SERVER_USERNAME=your-username ``` 2. Start opencode TUI 3. Use any plugin tool that calls `ctx.client.session.create()` (e.g., `oh-my-opencode`'s `look_at` tool) 4. **Observe:** `Error: Failed to create session: Unauthorized` ## Expected Behavior The plugin client should include the Authorization header when `OPENCODE_SERVER_PASSWORD` is set, and plugin API calls should work normally. ## Actual Behavior Plugin API calls fail with `401 Unauthorized`. ## Analysis I noticed that in `packages/opencode/src/plugin/index.ts`, the client is created without the Authorization header: ```typescript const client = createOpencodeClient({ baseUrl: Server.url().href, // @ts-ignore - fetch type incompatibility fetch: async (...args) => Server.App().fetch(...args), // <-- No auth header }) ``` However, in `packages/opencode/src/cli/cmd/tui/worker.ts`, the auth header IS correctly added: ```typescript const fetchFn = (async (input: RequestInfo | URL, init?: RequestInit) => { const request = new Request(input, init) const auth = getAuthorizationHeader() // <-- Auth header added here if (auth) request.headers.set("Authorization", auth) return Server.App().fetch(request) }) as typeof globalThis.fetch ``` It seems like the plugin client might need similar auth handling, but I'm not 100% sure if this is the correct fix approach. ## Environment - opencode version: 1.1.27 - OS: macOS - Plugin: oh-my-opencode 3.0.0-beta.11 ### Plugins oh-my-opencode 3.0.0-beta.11 ### OpenCode version 1.1.27 ### Steps to reproduce 1. Set OPENCODE_SERVER_PASSWORD 2. Use oh-my-opencode plugin 3. Call look_at tool 4. Get 401 Unauthorized ### Screenshot and/or share link _No response_ ### Operating System macos 26.0 ### Terminal Terminal
yindo added the bug label 2026-02-16 18:05:50 -05:00
yindo commented 2026-02-16 18:05:50 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 20, 2026):

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

  • #8676: Plugin client returns 401 Unauthorized when OPENCODE_SERVER_PASSWORD is set (Desktop)

The symptoms and root cause appear to be identical - the plugin client is missing the Authorization header when OPENCODE_SERVER_PASSWORD is set. Feel free to ignore if this addresses a specific case not covered by #8676.

@github-actions[bot] commented on GitHub (Jan 20, 2026): This issue might be a duplicate of existing issues. Please check: - #8676: Plugin client returns 401 Unauthorized when OPENCODE_SERVER_PASSWORD is set (Desktop) The symptoms and root cause appear to be identical - the plugin client is missing the Authorization header when OPENCODE_SERVER_PASSWORD is set. Feel free to ignore if this addresses a specific case not covered by #8676.
yindo commented 2026-02-16 18:05:50 -05:00
Author
Owner
Copy Link
Copy Source

@R44VC0RP commented on GitHub (Jan 20, 2026):

Thanks for the detailed bug report and excellent analysis @uf-hy! You've correctly identified the root cause.

This is a confirmed bug and is related to #8676 (which covers the Desktop/Tauri case). There's already an open PR #9095 that addresses TUI auth when using HTTP mode, but it doesn't fix the plugin client path you've identified in plugin/index.ts.

Your analysis is spot-on:

  • worker.ts correctly uses getAuthorizationHeader() to add Basic Auth
  • plugin/index.ts creates the client without any auth headers

Next Steps:
We'll either extend PR #9095 to also fix the plugin client, or create a separate targeted fix. The fix is straightforward - using a similar fetchWithAuth wrapper like the TUI worker does.

For now, the workaround is to not set OPENCODE_SERVER_PASSWORD when using plugins that make SDK API calls, or use the CLI without the server password when testing plugins.

Linking this to #8676 for tracking. Thanks for the clear reproduction steps!

@R44VC0RP commented on GitHub (Jan 20, 2026): Thanks for the detailed bug report and excellent analysis @uf-hy! You've correctly identified the root cause. This is a confirmed bug and is related to #8676 (which covers the Desktop/Tauri case). There's already an open PR #9095 that addresses TUI auth when using HTTP mode, but it **doesn't fix the plugin client path** you've identified in `plugin/index.ts`. Your analysis is spot-on: - `worker.ts` correctly uses `getAuthorizationHeader()` to add Basic Auth - `plugin/index.ts` creates the client without any auth headers **Next Steps:** We'll either extend PR #9095 to also fix the plugin client, or create a separate targeted fix. The fix is straightforward - using a similar `fetchWithAuth` wrapper like the TUI worker does. For now, the workaround is to not set `OPENCODE_SERVER_PASSWORD` when using plugins that make SDK API calls, or use the CLI without the server password when testing plugins. Linking this to #8676 for tracking. Thanks for the clear reproduction steps!
yindo commented 2026-02-16 18:05:50 -05:00
Author
Owner
Copy Link
Copy Source

@LeonMueller-OneAndOnly commented on GitHub (Jan 31, 2026):

Info for maintainers: This fix for the plugin authorization issue was incorporated into the pr #9095 - which solves the auth issue when a server-password is set for the

  • plugins
  • the tui+server starting
  • and the tui attaching
@LeonMueller-OneAndOnly commented on GitHub (Jan 31, 2026): Info for maintainers: This fix for the plugin authorization issue was incorporated into the pr #9095 - which solves the auth issue when a server-password is set for the - plugins - the tui+server starting - and the tui attaching
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6988
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?