[Feature] Add an OpenCodex-specific User-Agent header

[fanqiecd]

Summary

Outbound requests routed through OpenCodex appear upstream with only the runtime User-Agent Bun/1.3.14. This makes OpenCodex traffic difficult to distinguish from direct Bun clients.

Evidence

The provider usage panel reports:

USER-AGENT: Bun/1.3.14

Observed on a Windows OpenCodex setup using an OpenAI Responses-compatible /v1/responses route. No credentials, prompts, or personal data are included.

Expected behavior

OpenCodex should send a stable product-specific User-Agent, for example:

OpenCodex/<version> (Bun/1.3.14)

or provide a configurable OpenCodex client identifier while retaining the Bun runtime version as secondary metadata.

Actual behavior

Only Bun/1.3.14 is visible upstream.

Why this matters

• Distinguishes OpenCodex traffic from direct Bun clients.
• Improves provider-side debugging and request attribution.
• Helps correlate usage and transport issues without inspecting request bodies.

Acceptance criteria

• Outbound requests include an OpenCodex-specific User-Agent token.
• The bundled runtime version may remain in the header.
• Existing custom User-Agent behavior, if configured, is preserved or documented.
• No secrets or request content are logged or exposed.

Checks

• I searched existing issues and documentation.
• I removed secrets and personal data.

[coderabbitai]

🔗 Related PRs

#966 - fix(codex): keep pre-connection DNS/network failures off account health (#914) [open]
#1488 - feat(codex): show per-account usage [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Maintainer decision respected

A maintainer has reopened this issue. The automated closure has been deactivated.

[lidge-jun]

Declining after triage. A large share of opencodex traffic must stay wire-compatible with the upstream clients it proxies for (Codex CLI/App, Claude Code), and several providers gate on the client fingerprint — advertising a distinct opencodex/x.y.z User-Agent on those paths risks breaking exactly the flows the proxy exists to keep working. A scoped variant (custom/API-key providers only) would fragment behavior per route for little diagnostic gain, so we are not taking this now. If a provider ever requires client identification explicitly, we can revisit with a per-provider opt-in.