Repository navigation
Are openai-codex/chatgpt deliberately disabled? (codex proxy door question) #1317
Description
Question
openai-codex and chatgpt — two provider ids that both front the same Codex proxy door (127.0.0.1:18744) — sit in disabled_providers. They entered that list in commit f574927 ("chore(config): commit laptop fleet config working-tree state"), a bulk state commit, so the repo records no reasoning. Meanwhile the plan pools (luna-plan, sol-plan, terra-plan) address the bare openai provider + openai.alternate for OpenAI traffic, and the codex proxy itself is healthy and supervised.
Why it matters
- If the disable is deliberate (e.g. the two ids duplicate one quota and route traffic should never split across them), it should be documented in the config header like the other disables (the 2026-10-24 provider-alignment note explains google/antigravity-agy but not these).
- If it is debris from the working-tree commit, the fleet's intended OpenAI door for plan traffic may actually be the codex proxy, and the bare
openaiprovider leaves in every plan pool deserve a second look (what credential/quota do they draw on?).
Ask
Decide and record: (a) un-disable one or both ids and adjust plan-pool doors accordingly, or (b) keep them disabled and add the reasoning to the config header note. Surfaced by the 2026-10-27 validation sweep that caught terra-plan (PR #1296) pointing at these disabled providers; terra-plan was retargeted to openai + openai.alternate in the meantime.
Acceptance criteria
- The question is answered on this issue with evidence: either (a) the disable was deliberate, with the reasoning recorded in the opencode config header note, or (b) it was an accident of the bulk commit f574927 and
openai-codex/chatgptare re-enabled (or the plan-pool doors adjusted) accordingly. - Whichever outcome: the config in the repo and the recorded reasoning agree, and no plan-pool door points at a disabled provider (the terra-plan failure mode from PR feat(opencode): set up GPT-6.1 Terra (probe-verified via Codex) #1296).
Activity
developing-today commentedon Oct 27, 2026
CODE-428
dezren39 commentedon Oct 27, 2026
Intake review
Related: PR #1296 (terra-plan originally pointed at these disabled providers; retargeted to openai + openai.alternate), PR #1316 (terra-plan door correction), commit f574927 (bulk config commit that introduced the disable with no recorded reasoning) — all named in the issue body.
Notes: this is a decision question, not an implementation defect — the code/config state is known and self-consistent right now; what is missing is the intent. Live check this run: no merged PR answers it (PR #1316 adjusts doors around the disable without explaining it).
Risks: re-enabling a deliberately-disabled door could re-route plan traffic through the Codex proxy (127.0.0.1:18744) unexpectedly; leaving an accidental disable in place silently wastes a working door.
Suggested approach: Drew/Muse answers from the POOL MAP / routing history; the answer and reasoning get recorded in the config header note per the issue's own option (b), then this closes. Labelled
user/reviewfor that answer.dezren39 commentedon Nov 1, 2026
agent-note:v1
event: picked_up
task: 2545 (repo-health-code-pilot, openchamber scheduled lane)
state: Claimed triage; checking current routing configuration and evidence of intent before proposing a follow-up.
dezren39 commentedon Nov 1, 2026
agent-note:v1
event: escalated
task: 2545 (repo-health-code-pilot, openchamber scheduled lane)
outcome: blocked — owner decision required; no provider or routing changes made.
At main d64e83c, .opencode/opencode.jsonc:126–137 still disables both provider IDs. Lines 6625–6665 show the current nested OpenAI plan routes use openai.alternate then openai, not these proxy IDs. Lines 6891–6898 themselves say original disable intent is unresolved. #3216 supplies evidence that built-in OpenAI browser/headless auth uses the ChatGPT plan Codex backend, not necessarily PAYG. None of this establishes why the proxy IDs were disabled.
Decision needed: keep both disabled and record the intended reason, or enable a specified provider and choose any necessary route changes? Do not infer the original intent from the bulk commit.
dezren39 commentedon Nov 3, 2026
RULING (Muse, acting for Drew, 2026-11-03): openai-codex and chatgpt providers remain disabled (status quo); no evidence of an intent to enable was found, and re-enabling is a routing/cost change that needs its own stated reason. Task 2545 closed with this ruling.
dezren39 commentedon Nov 3, 2026
Closed in the 2026-11-03 coverage pass. This was a question issue, and it was answered by ruling on 2026-11-03 (Muse, acting for Drew): the openai-codex/chatgpt providers remain deliberately disabled. The decision was the deliverable; task 2545 is done. Reopen if the provider posture ever changes.
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
openai-codex/chatgptremain deliberately disabled; task 2545 closed with that ruling) and closed in the 2026-11-03 coverage pass. No in-flight work remains.queue/blocked,status/blocked, anduser/escalated. Those stale state labels are removed in the same action as this note; the descriptive labels (kind/question, source/human, priority/normal, effort/s, meta/enriched) stay.