Repository navigation
[Feature]: Opt in to showing raw Chat reasoning in Codex Desktop #7367
Description
Area
Provider adapters
What are you trying to accomplish?
I use Codex Desktop through OpenCodex with an open-source reasoning model served by an OpenAI-compatible Chat Completions endpoint. I want the model's reasoning to appear in Codex's expandable thinking view.
What prevents this today?
Codex sends a Responses API request, but OpenCodex translates it to the provider's Chat Completions API. Some models return reasoning only in provider-specific raw fields. OpenCodex currently keeps that raw text out of the Responses summary channel, so Codex has no expandable summary to display. Showing raw chain of thought by default is not appropriate; the earlier reasoning-display work in #45 and PR #2007 was reverted for that reason.
What should OpenCodex do?
Offer a per-provider, default-off compatibility setting that lets an operator explicitly expose raw reasoning from a translated Chat Completions route through the Responses summary channel. The setting should not synthesize or claim a provider-authored summary, and explicit hideRawReasoning or reasoning.summary: "none" should continue to suppress it. Native Responses passthrough and direct Chat/Messages clients should remain unchanged.
Example usage or interface
Add an opt-in to the existing provider configuration:
{
"providers": {
"my-chat-model": {
"adapter": "openai-chat",
"rawReasoningAsSummary": true
}
}
}
Alternatives or workarounds
Use a Responses-compatible provider route when available, or rely on the Codex setting that displays raw reasoning. Neither provides the same per-provider, explicit compatibility control for a Chat-only upstream.
Additional context
This is a follow-up capability to the earlier default-display issue, not a request to expose raw reasoning globally. Related: #45 and #210.
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.
Activity
github-actions commentedon Oct 19, 2026
Automated translation bookkeeping — detected language: English.
Ingwannu commentedon Oct 19, 2026
Tracked the concrete opt-in proposal in Draft #7370. Its default-off scope, suppression precedence and difference from provider-authored summaries need owner disposition because the earlier global display approach was reverted. The PR currently has a real sponsorship/readiness hold on auth-cors.ts and is not a shipped setting. Keep native passthrough and direct Chat/Messages unchanged, and verify the replay copy/non-persistence/byte-accounting path separately from what the Desktop displays. Marking needs-design; no raw-reasoning display or live configuration was enabled.
lidge-jun commentedon Oct 28, 2026
Maintainer triage design proposal. This is a proposal for discussion, not approval. I fetched
origin/devand reviewedfdc6dd82d930295880dcf6d10bbb9f2c61994574.Current state. The translated bridge still distinguishes raw reasoning from provider-authored summaries: raw SSE uses
response.reasoning_text.delta(src/bridge/sse.ts:1037–1065), and buffered raw items have an empty summary plusreasoning_textcontent (src/bridge/response-json.ts:298–320). Final-route normalization explicitly preserves that distinction (src/server/responses/core-normalize.ts:201–212). @reisen-ww already supplied the concrete opt-in design in #7370, and @Ingwannu established the suppression, replay and review boundaries; those contracts should be reused. One status correction matters: that Draft PR was closed on October 22, with design left open here. Its reported tests do not establish a shipped setting. The owning structure/providers/chat-compat.md:451–480 still records the earlier global-display revert.Options and recommendation. We can retain the current content channel and document the client's raw-display control; introduce the proposed per-provider, default-off compatibility switch for Responses requests finally using
openai-chat; or pursue genuine upstream-authored summaries as a separate capability. I recommend the second option only after @lidge-jun explicitly accepts verbatim raw text in the summary channel and its user-facing labeling. It should reuse the existing proposal rather than revive the broader #2007 passthrough rewrite.Risks. An expandable summary can make unsummarized model text look curated and expose it wherever clients retain or export responses. Display suppression is not confidentiality: replay carriers must be inspected independently, and the existing encoded envelope must not be described as encryption. Both delivery modes need accounting for the visible text and encoded replay copy, including cancellation and budget exhaustion. Native Responses and direct Chat/Messages compatibility need explicit controls.
Smallest next slice. An offline characterization patch can compare enabled, disabled and explicitly suppressed SSE/JSON output, replay continuity, fallback routing,
store:falsepersistence and byte limits. No production implementation should start before the owner decides the raw-as-summary policy and provider-save scope. Any renewed authentication-surface change needs the normal security review; the closed PR's sponsorship hold was not waived. Desktop rendering and live acceptance remain unverified by this analysis.