Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Closed
  • Is something wrong?
#5,660 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
developer-experience, tooling

Research direction

Read the existing Grok client integration and the Codex and Claude Desktop integrations to understand their lifecycle and configuration-switch conventions. Then inspect the settings sync and restore/uninstall paths, along with loopback-bind handling and proxy diagnostics. Done means Qoder settings are refreshed and precisely cleaned up, unrelated entries are preserved, and the entitlement failure is explained.

Written by the indexing model from the issue text.

Description

catalog enhancement help wanted needs-design priority: P3 provider
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 (#5270, #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.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
7h 38m
Merged PRs (30d)
659

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.