Summary
Add native support for dynamic authentication headers for remote MCP servers.
The main use case is short-lived bearer tokens or other custom auth flows that cannot be represented cleanly with static headers and do not fit the existing OAuth path.
Proposed shape
Add a structured headersHelper object on remote MCP servers, for example:
{
"headersHelper": {
"command": ["node", "./scripts/mcp-headers.js"],
"environment": {
"PROFILE": "prod"
},
"timeout": 10000
}
}
Proposed behavior
- run the helper on connect and reconnect
- no caching in v1
- helper stdout must be a JSON object of string headers
- helper-produced headers override static
headers
- require trust approval before executing project-local or remote-config helpers
Why this would help
Today OpenCode supports static headers and OAuth, but some MCP servers need custom auth headers generated at runtime.
Notes
I have a local implementation draft for this, but I do not want to open a PR until the core team confirms the design is acceptable.
If this direction looks good, I can open a focused PR with the code, tests, docs, and generated SDK/OpenAPI updates.
Summary
Add native support for dynamic authentication headers for remote MCP servers.
The main use case is short-lived bearer tokens or other custom auth flows that cannot be represented cleanly with static
headersand do not fit the existing OAuth path.Proposed shape
Add a structured
headersHelperobject on remote MCP servers, for example:{ "headersHelper": { "command": ["node", "./scripts/mcp-headers.js"], "environment": { "PROFILE": "prod" }, "timeout": 10000 } }Proposed behavior
headersWhy this would help
Today OpenCode supports static headers and OAuth, but some MCP servers need custom auth headers generated at runtime.
Notes
I have a local implementation draft for this, but I do not want to open a PR until the core team confirms the design is acceptable.
If this direction looks good, I can open a focused PR with the code, tests, docs, and generated SDK/OpenAPI updates.