[Windows/Desktop v1.17.11] OpenAI gpt-5.5-fast xhigh fails with reasoning part rs_*:0 not found

[NedMalki-Chief]

Description

On Windows Desktop v1.17.11, OpenAI via Codex OAuth can fail a fresh Desktop session when using model openai/gpt-5.5-fast with variant xhigh.

The surfaced Desktop error is:

"reasoning part rs_0fb3300ac7bf0ed4016a3d4ba7f050819a94b5161d7e1791ab:0 not found"

I also saw the same shape with other reasoning ids in separate Desktop sessions.

Sanitized environment

• OS: Windows 11 x64
• OpenCode Desktop: v1.17.11
• OpenCode CLI after manual alignment: v1.17.11
• Provider: OpenAI using Codex OAuth
• Runtime from log: llm.runtime=ai-sdk
• Model from session DB: {"id":"gpt-5.5-fast","providerID":"openai","variant":"xhigh"}

Steps to reproduce

1. On Windows 11, run OpenCode Desktop v1.17.11 authenticated to OpenAI via Codex OAuth.
2. Select openai/gpt-5.5-fast with variant xhigh.
3. Start a fresh Desktop agent session with a normal file-edit or documentation-inspection task.
4. Let the assistant stream reasoning/tool-planning output.
5. The session can fail with the reasoning part error above.

What I observed locally

• New Desktop sessions were created successfully, then failed during the assistant stream.
• The local DB had multiple reasoning parts associated with the same OpenAI reasoning item id before the assistant message stored the error.
• Example duplicate OpenAI item id from metadata.openai.itemId: rs_0fb3300ac7bf0ed4016a3d4ba7f050819a94b5161d7e1791ab
• Assistant error stored in DB: "reasoning part ...:0 not found"

Expected behavior

OpenCode should merge/reconcile repeated reasoning segments for one OpenAI Responses reasoning item, or tolerate a reasoning-end event without crashing the session.

Actual behavior

The Desktop session fails with "reasoning part rs_*:0 not found".

Mitigation that worked locally

• Set the default agent model to openai/gpt-5.5 with variant high.
• Disable gpt-5.5-fast variants in config.
• After restart, a default OpenCode run selected gpt-5.5/high and completed.

Possibly related

Issue #27987 looks related at the processor layer because it discusses multiple reasoning-start/end cycles and reasoning part merging, but this report is specifically the OpenAI/Codex OAuth plus gpt-5.5-fast/xhigh failure case on Windows Desktop v1.17.11.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Stream parsing: "text part <uuid> not found" when provider is OpenAI-compatible proxy (LiteLLM) #25487: Same <type> part <id> not found error pattern during stream parsing/part-id reconciliation — different provider (LiteLLM proxy) but the same processor-layer mechanism
• processor.ts: merge multiple reasoning-start/end cycles into one part #27987: Directly related reasoning-start/end cycle merging in processor.ts (which you also referenced) — covers multiple reasoning segments mapped to the same reasoning item id

[arcanistzed]

I’m encountering the same issue:

• Fedora Workstation 44, x86_64
• OpenAI via OAuth
• openai/gpt-5.6-sol (non-fast)
• medium reasoning variant
• plan agent, primary mode
• llm.runtime=ai-sdk
• No plugins

The affected session was originally created with OpenCode 1.17.19. The logs from the run containing the failures also record newly created sessions as version 1.18.1.

Prompting with continue from the affected conversation branch failed repeatedly. Two consecutive attempts in the same session produced the same error with different reasoning IDs:

stream providerID=openai modelID=gpt-5.6-sol small=false agent=plan mode=primary
llm.runtime=ai-sdk llm.provider=openai llm.model=gpt-5.6-sol
process error="reasoning part rs_<redacted-1>:0 not found"

stream providerID=openai modelID=gpt-5.6-sol small=false agent=plan mode=primary
llm.runtime=ai-sdk llm.provider=openai llm.model=gpt-5.6-sol
process error="reasoning part rs_<redacted-2>:0 not found"

I recovered the same session by reverting to an earlier message and submitting the original prompt again unchanged. The next request in that session proceeded normally, including further tool/subagent calls. Changing the prompt was not required.

This differs slightly from recovery by “changing what it’s thinking about”: in my case, the identical prompt succeeds after rolling back the conversation branch. That makes a prompt-only trigger less likely and suggests the failure may depend on reasoning-part state retained in the affected branch. The fact that the session crossed an OpenCode version upgrade may also be relevant.

This confirms the issue on Linux, with non-fast GPT-5.6 Sol and the medium reasoning variant.

[rekram1-node]

Hm this shouldn't be possible unless u are overriding the default settings. Show me opencode debug config

[arcanistzed]

This is my current opencode debug config. The MCP entries were added after the error and were not active during the affected session. At the time, my source config contained only the $schema field, with no provider, model, agent, plugin, or mcp overrides.

The timestamps confirm this:

• ~/.local/share/opencode/log/opencode.log records the errors at 2026-07-16T07:50:11Z and 2026-07-16T07:53:29Z.
• OpenCode’s apply_patch tool call records the MCP block being added at 2026-07-16T19:20:26Z. The diff shows that the previous config contained only $schema.
• The config file’s modification time is 2026-07-16 15:20:26 -0400, equivalent to 19:20:26Z, corroborating the tool-call record.

Thus, the MCP configuration was added approximately 11 hours and 27 minutes after the errors. The affected session was effectively using the default configuration.

Current opencode debug config output:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "cloudflare": {
      "type": "remote",
      "url": "https://mcp.cloudflare.com/mcp",
      "enabled": true,
      "oauth": {}
    },
    "cloudflare-docs": {
      "type": "remote",
      "url": "https://docs.mcp.cloudflare.com/mcp",
      "enabled": true
    },
    "cloudflare-bindings": {
      "type": "remote",
      "url": "https://bindings.mcp.cloudflare.com/mcp",
      "enabled": true,
      "oauth": {}
    },
    "cloudflare-builds": {
      "type": "remote",
      "url": "https://builds.mcp.cloudflare.com/mcp",
      "enabled": true,
      "oauth": {}
    },
    "cloudflare-observability": {
      "type": "remote",
      "url": "https://observability.mcp.cloudflare.com/mcp",
      "enabled": true,
      "oauth": {}
    }
  },
  "agent": {},
  "mode": {},
  "plugin": [],
  "command": {},
  "username": "arcanist"
}