lidge-jun/opencodex

Area Provider adapters What are you trying to accomplish? Use the official Claude subscription runtime behind an application-managed Codex app-server: Application → Codex app-server → OpenCodex /v1/responses → official Claude runtime The application needs both ordinary text generation and a structured workflow: advertise application tools, receive a native function call, execute it in the application, return the result, and receive a final answer conforming to a supplied JSON Schema. Codex remains the tool/session host; the application retains control of tool execution and writes. This request concerns the subscription provider, with authentication owned by the official Claude runtime. A direct Anthropic API-key adapter or copying subscription tokens into a custom HTTP client does not meet this use case. What prevents this today? On the inspected OpenCodex 2.73.0 source, claude-cli does not pass the caller's tool catalog or textFormat to the Claude process. Its argument builder

Area Service lifecycle What are you trying to accomplish? Run OpenCodex as a service that can perform a Kubernetes Ready-before-stop rolling replacement (maxSurge: 1, maxUnavailable: 0). During the overlap, the old pod must continue serving requests until the replacement is actually ready, while both instances obey one logical spend/reservation state and the same admission limits. This is an opt-in multi-instance deployment mode; ordinary single-instance installations should not need PostgreSQL. What prevents this today? The current supported topology is one live writer per OPENCODEX_HOME. The durable spend ledger is a JSONL journal, while a separate SQLite spend-ledger-owner.sqlite holds a process-lifetime BEGIN IMMEDIATE ownership transaction. The replacement pod using the same home cannot acquire that lease while the old pod runs, so it cannot become Ready before the old pod stops. This is correct fail-closed behavior for the current topology, not a broken SQLite lock. Recreate avoi

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

Client or integration CI only (GitHub Actions hosted macOS runners); not a client-facing path. Area CI and release Summary Sharded macOS test legs stop producing output mid-suite and are killed at their job budget with zero reported failures. Across four occurrences the signature is identical: a test logs PASS, then the job emits nothing at all for 16 to 18 minutes until the runner cancels it, and Bun and tee are orphan-killed. This has been present since at least the 2.58.0 release round and was recorded there as capacity cancellation, which the evidence below does not support. A related but distinct failure mode appears where a hook timeout exists to stop it: the same shard reports a beforeEach/afterEach hook timed out for this test at just over 30s instead of going silent. Two consequences. Releases have been cut without complete macOS evidence while believing macOS reds were infrastructure. And because the silent form produces a cancellation rather than a failure, it is indistingui

Area Provider adapter What are you trying to accomplish? I use several text-only routed models through the vision sidecar, which describes images before feeding them to the text-only model. Right now my only choice for the "describer" is an OpenAI-native or Anthropic model that runs through the ChatGPT forward backend. I'd like to be able to pick any configured provider's vision model — for instance a Doubao/volcengine vision model I already have configured in opencodex — as the describer. What prevents this today? The vision sidecar (visionSidecar.model) sends the describe request through forwardProvider (the ChatGPT forward backend) to /responses, so model is effectively limited to OpenAI-native (or Anthropic) model ids. A model hosted on a custom provider (cliproxy, volcengine/doubao, etc.) can't be selected because the describe path doesn't know how to reach that provider. What should OpenCodex do? Allow the vision-sidecar description model to be resolved against any configured