[Feature]: Qoder as a client integration (use opencodex models inside Qoder IDE / qodercli) #5660

Area

Multiple areas

What are you trying to accomplish?

I want to use opencodex-hosted models (Claude, Grok, DeepSeek, Ollama, and anything else the proxy routes) directly inside the Qoder IDE and qodercli, with opencodex managing the configuration automatically — the same way the existing client integrations work for Codex CLI (clientIntegrations.codex), Grok (clientIntegrations.grok), and Claude Desktop (clientIntegrations.claude-desktop).

What prevents this today?

opencodex supports Qoder only in the provider direction: the native qoder provider adapter routes requests through a Qoder subscription. There is no clientIntegrations.qoder, so nothing writes opencodex into Qoder's BYOK ("External Provider") settings, nothing keeps the model list in sync with the proxy roster, and nothing cleans the entries up on ocx restore / ocx uninstall. Today a user has to hand-edit ~/.qoder/settings.json and re-sync it manually whenever the models or the port change.

What should OpenCodex do?

Add a qoder client integration following the same lifecycle as the Grok integration:

• on startup, sync a managed provider entry plus one managed custom-model entry per proxy model into ~/.qoder/settings.json, pointing at the loopback proxy;
• strip exactly the managed entries on ocx restore / ocx uninstall, preserving foreign and unrelated entries;
• gate it on the durable clientIntegrations.qoder switch (missing means on), like the other integrations.

One design constraint worth knowing up front: Qoder gates External Provider usage per account on its server. With the settings in place but the account not entitled, requests fail with External Provider is not enabled for the current user — the check is enforced remotely, not by a client-side flag. So the integration can only work for accounts with the feature enabled, and it would help if the sync/diagnostics surface recognized that specific failure and explained it instead of surfacing a generic upstream error.

Example usage or interface

Qoder's BYOK settings format, verified against qodercli 1.1.3 (unofficial and may change without notice). Managed entries in ~/.qoder/settings.json:

{
  "providers": {
    "opencodex": {
      "type": "openai-compatible",
      "protocol": "openai",
      "displayName": "opencodex",
      "baseUrl": "http://127.0.0.1:<port>/v1",
      "apiKey": "<placeholder>",
      "defaultModel": "<first proxy model>",
      "models": [{ "model": "<proxy model>" }]
    }
  },
  "modelConfigs": {
    "customModels": [
      {
        "provider": "opencodex",
        "apiKey": "<placeholder>",
        "model": "<proxy model>",
        "baseURL": "http://127.0.0.1:<port>/v1",
        "displayName": "<proxy model>",
        "maxInputTokens": 128000
      }
    ]
  }
}

Behavioral details observed while verifying this against qodercli:

• entries require non-empty provider / apiKey / model;
• for protocol openai the client appends /chat/completions to baseURL (note the provider entry uses baseUrl, the custom-model entry uses baseURL);
• maxInputTokens defaults to 128000 when absent;
• the selectable id in the model picker and -m is ${provider}/${model};
• a placeholder API key suffices because the endpoint is loopback and the proxy authenticates locally — the integration should refuse to write entries for a non-loopback bind so the placeholder key can never leak to another host.

Expected workflow:

ocx start     # Qoder gains/refreshes the managed opencodex entries
              # pick e.g. opencodex/<model> in Qoder's model picker
ocx restore   # managed entries removed, foreign entries untouched

Alternatives or workarounds

Hand-writing the provider and customModels entries works today for entitled accounts, but the model list and port drift as soon as the proxy roster changes. Qoder has no other documented way to point at a local OpenAI-compatible endpoint.

Additional context

• The provider direction (opencodex routing through a Qoder subscription) already works and is out of scope for this request; this is about the reverse, client direction.
• Because the entitlement gate is server-side, injected settings are inert (but harmless) on non-entitled accounts and start working the moment the vendor enables the feature.
• Existing qoder issues ([Provider compatibility] Qoder adapter cannot use Codex-owned MCP/tool calls #5270, [qoder] Vendor CLI agent scaffolding leaks into routed output (MCP lazy-loading reminder + tool-call markup) #4190) concern the provider direction (tool-call/MCP leakage), not this.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.