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

[FEATURE]: MCP auth configuration for multi-tenant serve deployments #3657

New Issue
Open
opened 2026-02-16 17:41:01 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 17:41:01 -05:00
Owner
Copy Link
Copy Source

Originally created by @trustbutverafy on GitHub (Dec 19, 2025).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

When running OpenCode in serve mode for multi-tenant deployments, all sessions share the same static MCP server configuration. This means MCP servers cannot distinguish which user/session is making a request, making it impossible to implement proper access control at the MCP layer.

Use Case

We're building a platform where multiple users interact with OpenCode through its HTTP API. Each user should only be able to access their own resources via MCP tools (e.g., their own files, databases, or external service credentials).

Currently, the MCP configuration is read once at startup:

  {
    "mcp": {
      "myServer": {
        "type": "remote",
        "url": "https://mcp.example.com",
        "headers": {
          "Authorization": "Bearer <static-token>"
        }
      }
    }
  }

This static token is used for all sessions, so the MCP server has no way to know which user is making a request.

Proposed Solution

Add an optional mcpAuth parameter to session creation that allows passing per-session headers to MCP servers:

  curl -X POST http://localhost:4096/sessions \
    -H "Content-Type: application/json" \
    -d '{
      "mcpAuth": {
        "myServer": {
          "headers": {
            "Authorization": "Bearer <user-specific-token>",
            "X-Session-Id": "session-123"
          }
        }
      }
    }'

These headers would be merged with (or override) the static headers from the config file for that session's MCP calls.

Implementation Notes

The change would involve:

  • Accepting mcpAuth in the session creation endpoint
  • Storing per-session MCP headers in session state
  • Merging these headers when making MCP HTTP requests for that session

Happy to submit a PR if this approach seems reasonable. I'll be forking otherwise, but thought I would mention here.

Originally created by @trustbutverafy on GitHub (Dec 19, 2025). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request #### Problem When running OpenCode in `serve` mode for multi-tenant deployments, all sessions share the same static MCP server configuration. This means MCP servers cannot distinguish which user/session is making a request, making it impossible to implement proper access control at the MCP layer. #### Use Case We're building a platform where multiple users interact with OpenCode through its HTTP API. Each user should only be able to access their own resources via MCP tools (e.g., their own files, databases, or external service credentials). Currently, the MCP configuration is read once at startup: ``` { "mcp": { "myServer": { "type": "remote", "url": "https://mcp.example.com", "headers": { "Authorization": "Bearer <static-token>" } } } } ``` This static token is used for all sessions, so the MCP server has no way to know which user is making a request. #### Proposed Solution Add an optional mcpAuth parameter to session creation that allows passing per-session headers to MCP servers: ``` curl -X POST http://localhost:4096/sessions \ -H "Content-Type: application/json" \ -d '{ "mcpAuth": { "myServer": { "headers": { "Authorization": "Bearer <user-specific-token>", "X-Session-Id": "session-123" } } } }' ``` These headers would be merged with (or override) the static headers from the config file for that session's MCP calls. #### Implementation Notes The change would involve: - Accepting `mcpAuth` in the session creation endpoint - Storing per-session MCP headers in session state - Merging these headers when making MCP HTTP requests for that session Happy to submit a PR if this approach seems reasonable. I'll be forking otherwise, but thought I would mention here.
yindo added the discussion label 2026-02-16 17:41:01 -05:00
yindo commented 2026-02-16 17:41:01 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 19, 2025):

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

  • #1998: Split off MCP server configuration from config.json
  • #1492: MCP client doesn't follow specification for Authentication
  • #988: Feature request: add MCP remote using oauth
  • #5256: [FEATURE]: Adding Authentication to opencode server api

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Dec 19, 2025): This issue might be a duplicate of existing issues. Please check: - #1998: Split off MCP server configuration from config.json - #1492: MCP client doesn't follow specification for Authentication - #988: Feature request: add MCP remote using oauth - #5256: [FEATURE]: Adding Authentication to `opencode server` api Feel free to ignore if none of these address your specific case.
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 discussion
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#3657
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?