[Bug]: openai-chat doubles /chat/completions when custom baseUrl already includes it

[lidge-jun]

Client or integration

OpenCodex dashboard

Area

Provider adapter

Summary

A custom openai-chat provider whose baseUrl already ends in /chat/completions is routed correctly, then fails upstream with HTTP 404.

The chat adapter always appends /chat/completions to the configured baseUrl. If a dashboard/custom provider is saved as https://host/v1/chat/completions, the live request goes to https://host/v1/chat/completions/chat/completions.

The dashboard error is therefore a path construction miss, not a missing Teamwicked account or an OpenCodex routing miss. I expected either:

• the adapter to treat a baseUrl that already ends in /chat/completions as the full endpoint, or
• the provider form to reject/normalize that value to https://host/v1.

Reproduction

1. Add a custom key-auth provider:
   • adapter: openai-chat
   • baseUrl: https://api.example.test/v1/chat/completions
   • defaultModel: any model id the upstream actually hosts
2. Request that model through the dashboard / Codex App as <provider>/<defaultModel>.
3. OpenCodex selects the provider via explicit-provider-namespace and sends openai-chat.
4. Upstream returns HTTP 404 Not found.

Observed locally against a custom Teamwicked provider on 2026-08-13:

• requested model: teamwicked/teamwicked-kimi-k3
• request id: ocx-msqzl901-69
• conversation: b475653e97f224b016731c114e2205b1
• 6/6 consecutive attempts returned the same 404
• configured baseUrl: https://api.teamwicked.me/v1/chat/completions
• constructed send URL from src/adapters/openai-chat.ts: ${provider.baseUrl}/chat/completions

Workaround that matches the documented custom-provider shape: set baseUrl to https://api.teamwicked.me/v1 (no trailing /chat/completions).

If the path is corrected and 404 persists, that is a separate upstream model-id mismatch. This report is only about the doubled path.

Version

Running local service 2.13.0 (GET /healthz). Checkout package.json is 2.14.0 at 7bdc8f86c.

Operating system

macOS 27.0 (25A5353q / reported as 26A5353q)

Provider and model

teamwicked / teamwicked-kimi-k3

Logs or error output

requestId=ocx-msqzl901-69
status=404
errorCode=http_404
upstreamError=Provider error 404: Not found.
adapter=openai-chat
routeKind=explicit-provider
selected=teamwicked/teamwicked-kimi-k3
reason=explicit-provider-namespace
configured baseUrl=https://api.teamwicked.me/v1/chat/completions
constructed upstream URL=https://api.teamwicked.me/v1/chat/completions/chat/completions

Adapter construction:

const url = `${provider.baseUrl}/chat/completions`;

Docs already tell custom providers to use a /v1 base, for example https://api.example.com/v1. The form still accepts a full chat-completions URL.

Screenshots and supporting files

No screenshot attached. The dashboard 404 page for ocx-msqzl901-69 shows Teamwicked + teamwicked-kimi-k3 + http_404 + Provider error 404: Not found.

Redacted configuration

{
  "providers": {
    "teamwicked": {
      "adapter": "openai-chat",
      "baseUrl": "https://api.teamwicked.me/v1/chat/completions",
      "authMode": "key",
      "defaultModel": "teamwicked-kimi-k3"
    }
  }
}

API key omitted.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

Trailing-slash follow-up (live, 2026-08-13)

The original report was the doubled path:

https://api.teamwicked.me/v1/chat/completions + adapter append -> .../v1/chat/completions/chat/completions -> 404.

After that baseUrl was changed to https://api.teamwicked.me/v1/ (trailing slash, no endpoint). OpenCodex then sent:

https://api.teamwicked.me/v1/chat/completions/

Teamwicked still 404s that URL as teamwicked_gateway_error. Direct probes against the same host:

URL	Result
GET /v1/models	200, includes teamwicked-kimi-k3
POST /v1/chat/completions	200
POST /v1/chat/completions/	404 teamwicked_gateway_error
POST /chat/completions	HTML 404
POST /v1/responses	404
POST /v1/messages	404

With baseUrl normalized to https://api.teamwicked.me/v1 (no trailing slash), the same local proxy returned:

• POST /v1/chat/completions -> 200, assistant content OK
• POST /v1/responses -> 200, output_text OK
• POST /api/providers/test?name=teamwicked -> Connected, 5 models

So both paste shapes need the same send-path strip: trailing / and a trailing /chat/completions. Docs unit: devlog/_plan/260813_openai_chat_baseurl_normalize. Implementation will land on an isolated origin/dev worktree; this comment is evidence only, no keys.

[lidge-jun]

Patch on isolated branch

codex/openai-chat-baseurl-normalize @ feedaa1bce4fc3b5f16f3e058ab22e17f4218aac (from current origin/dev).

Send-path helper openaiChatCompletionsUrl strips trailing / and a trailing /chat/completions before appending the chat endpoint. Focused tests cover:

• /v1
• /v1/
• /v1/chat/completions
• /v1/chat/completions/
• mid-path /v1/relay
• false-positive somechat/completions
• buildRequest with a pasted /chat/completions/ baseUrl

bun test tests/openai-chat-url.test.ts tests/url-normalization.test.ts — 10 pass.

Branch: https://github.com/lidge-jun/opencodex/tree/codex/openai-chat-baseurl-normalize
Compare: dev...codex/openai-chat-baseurl-normalize
New PR: https://github.com/lidge-jun/opencodex/pull/new/codex/openai-chat-baseurl-normalize