Are custom provider headers from config expected to work in v1.2.x?

Question

Hi team 👋

I have a question regarding provider-level custom headers in the config.

In v1.2.15, it appears that headers defined in:

provider.options.headers
provider.models..headers

are merged into options internally, but they do not seem to be applied to the actual fetch request.

I noticed that PR #11788 attempted to fix:

"provider headers from config not applied to fetch requests"

However, based on the current implementation in packages/opencode/src/provider/provider.ts, it looks like those headers may not be reaching the final request layer.

My Questions

Are custom headers from config expected to work in v1.2.x?
Was PR fix: provider headers from config not applied to fetch requests #11788 reverted intentionally due to breaking changes?
Is there a plan to properly support provider-level custom headers in a future release?

Why This Matters

For some providers (internal gateways / enterprise proxies), custom headers such as:

apiKey
custom auth headers
custom User-Agent

are required at the HTTP layer.

Currently we may need to patch the fetch wrapper manually.

Would appreciate clarification on the intended design direction 🙏

Thanks!

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

provider headers from config not applied to fetch requests #11789: Same bug reported — provider headers from config not applied to fetch requests (same file provider.ts, same symptom). This issue was closed and references the same PR fix: provider headers from config not applied to fetch requests #11788 you mention.

Thanks for the reference 👍

I’ve reviewed #11789 and PR #11788.

Looking at the current implementation in v1.2.15, provider-level headers from config (e.g. provider.options.headers or provider.models.<model>.headers) appear to be merged into internal options, but they do not seem to be consistently applied to the final fetch layer.

Before implementing a local workaround, I’d like to clarify the intended design direction:

Are config-defined provider headers meant to propagate to the underlying HTTP request?
Or is header control expected to be handled entirely by the provider SDK layer instead?

Understanding the architectural intent here would help us determine whether:

This is a regression,
An unsupported use case,
Or something that may be formally supported in a future release.

Appreciate any guidance on the intended behavior going forward 🙏

For me, I'm looking for a way to send the AWS Guardrail information fromOpenCode. In ClaudeCode you set this up by including the following in your settings file.

Example for docker-compose or environment variables

ANTHROPIC_CUSTOM_HEADERS=X-Amzn-Bedrock-GuardrailIdentifier: <Your_ID>,X-Amzn-Bedrock-GuardrailVersion:

Automated: closing question issues.

GitHub Issues are for bug reports and feature requests only — questions / support are no longer tracked here.

For help & questions: https://discord.gg/opencode
Billing issues with Opencode Go / Zen: [email protected]

If this is a bug or feature request, please open a new issue with the appropriate template.

Navigation Menu

Repository navigation

Are custom provider headers from config expected to work in v1.2.x? #15306

Question

My Questions

Why This Matters

Example for docker-compose or environment variables

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Are custom provider headers from config expected to work in v1.2.x? #15306

Description

Question

My Questions

Why This Matters

Activity

github-actions commented on Feb 27, 2026

dreamjxw commented on Feb 27, 2026

esiemiat commented on Mar 15, 2026

Example for docker-compose or environment variables

rekram1-node commented on Jun 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions