[WIP] feat: support custom endpoints for built-in providers

[VrianCao]

What

• add first-class endpoint overrides for built-in providers via templated provider URLs and default URL params
• carry URL params through API key, OAuth code, and device auth flows
• switch codex and claude_code custom-endpoint logins to BYOK while keeping provider request semantics and headers

Notes

• WIP draft for Issue [Feature]: Provide first-class custom endpoint configuration for all built-in providers #2490
• endpoint decides auth/routing mode, while provider keeps request semantics
• for providers other than codex and claude_code, custom endpoints only change the endpoint and preserve the existing auth mode

Verification

• cargo test -p forge_services --lib
• cargo test -p forge_repo --lib
• cargo test -p forge_main --lib
• cargo test -p forge_infra --lib
• cargo test -p forge_domain --lib
• cargo +homebrew-local clippy -p forge_domain -p forge_services -p forge_repo -p forge_main -p forge_infra --all-targets -- -D warnings

Follow-up

• manual CLI smoke testing is still pending

Refs #2490

[CLAassistant]

All committers have signed the CLA.

[amitksingh1490]

Hey @VrianCao thanks for this PR. One insight i would like to suggest is you can override existing provider by defining a new provider.json on ~/forge repo. So we if can support the ui to override settings and save the file in ~/forge/provider.json. It should work.

You can create new providers also in ~/forge/provider.json and it will be listed in provider list.

Let me know if u need help in that?

[VrianCao]

Thanks @amitksingh1490 — this is helpful, and yes, I’m aware Forge already supports overriding providers via ~/forge/provider.json.

I think the goal of this PR / feature is a bit broader than only exposing that internal override path, though. What we want to achieve is more of a first-class UI/UX around endpoint configuration, so users can do this through the normal forge provider login flow instead of having to manually edit provider.json.

For most providers, I agree we should try to reuse the existing provider endpoint rewrite / merge system as much as possible rather than inventing a parallel mechanism. The main thing missing today is the official UX layer on top of it.

The special case is codex and claude_code.

For those two providers, a custom endpoint is not just “same provider, different base URL”. In some enterprise setups, Claude Code / Codex is reverse-proxied behind an internal gateway. Employees authenticate to that gateway using a standard API key, but the gateway ultimately forwards the request upstream as Claude Code / Codex. That means the request still has to preserve the original provider semantics — request shape, special headers, beta flags, tool behavior, etc. In other words:

• the endpoint decides the auth mode / routing
• the provider still decides the request semantics

So for codex / claude_code, when the endpoint is customized, we intentionally want API key auth to the gateway, while still keeping the original Codex / Claude Code request format intact.

This is still WIP on our side, and we’re actively thinking about how to make the whole flow simpler, smoother, and lower-friction for users. So your suggestion is definitely useful, especially for the general provider-config story — we just also need to account for the Codex / Claude Code-specific behavior.

[github-actions]

Action required: PR inactive for 5 days.
Status update or closure in 10 days.