[Bug] 打开侧边聊天会，报一个，未能打开侧边聊天，但实际使用时正常

[wosnxn123]

Area

Other / Unknown

Summary

打开侧边聊天会，报一个：
未能打开侧边聊天
但实际使用时正常

Expected behavior

报错消失

Actual behavior

打开侧边聊天会，报一个：
未能打开侧边聊天
但实际使用时正常

Reproduction

打开侧边聊天除codex当做Harness是正常的，其他的会报(测试环境是claude code)

codexhost version

0.7.1

Codex Desktop version

26.908.40834

OS / Architecture

Windows 11 x64

Installation

Windows installer

Harness / Version

2.1.270 (Claude Code)

Connection

None

Redacted logs / Screenshots

No response

[BytePioneer-AI]

PR #302 已合并，修复了侧边聊天开启后请求通道失效的问题。按已修复关闭；如后续版本中仍可复现，请携带最新版本信息重新打开。

[4sj9wrhgbp]

Reopening per the maintainer invitation ("如后续版本中仍可复现，请携带最新版本信息重新打开") — still reproduces on v0.8.2, which includes the #302 fix, and the manifestation is more severe than the original report.

Environment: Windows 11, CodexHost 0.8.2 (includes #302), Codex Desktop 26.908.9136.0 (auto-updated; third build in the 26.908 line within days), Claude Code 2.1.261.

Trigger: opening the ChatGPT side chat panel (侧边栏/侧边聊天).

Observed (reporter screenshot):

• The harness icon slot next to the model selector renders as an exclamation placeholder instead of the harness icon.
• Sending messages fails entirely while in this state — not just a benign toast.
• Model selector shows the selected model (e.g., GPT-6 Astra 中 on the Hermes harness); also observed switching between harnesses does not help until a conversation toggle.

Recovery: intermittent — sometimes self-heals, sometimes requires toggling conversations back and forth; a full Host chain restart restores everything until the next occurrence.

Contrast with the original report: on 0.7.1 / Desktop 26.908.40834 the symptom was a benign error toast with usage still working. On 0.8.2 / Desktop 26.908.9136.0 the failure is functional (sends blocked while stuck).

Happy to run additional diagnostics — DevTools is attached to the Desktop instance if specific state inspection would help locate the issue.

[4sj9wrhgbp]

[BytePioneer-AI]

试下 0.9.0

[4sj9wrhgbp]

Live reproduction captured on v0.8.2 (which includes the #302 fix) — Windows 11, Codex Desktop 26.908.9136.0. Requesting reopen.

The issue still occurs on 0.8.2, with a more severe manifestation than the original report:

• Trigger: opening the ChatGPT side chat panel (侧边栏).
• Live DOM state (captured mid-episode, CDP attached to the Desktop):
  • The composer model area is stuck showing "Loading models..." (5 occurrences in the live DOM) and/or "Select model" with an exclamation icon.
  • Message sending is blocked entirely in this state — no model is attached to the submission.
• Recovery: intermittent — sometimes self-heals, sometimes requires toggling conversations back and forth; a full Host chain restart restores everything until the next occurrence.
• Harness context: observed on both a claude-code harness session (glm-5.3-flash[1M] via custom route) and with Hermes (gpt-6-astra) selected — not model-specific.

Contrast with the original report: on 0.7.1 / Desktop 26.908.40834 the symptom was a benign error toast with usage still working. On 0.8.2 / Desktop 26.908.9136.0 the failure is functional (composer stuck loading models, sends blocked).

Versions: CodexHost 0.8.2, Codex Desktop 26.908.9136.0, codex-cli 0.153.4, Claude Code 2.1.261.

CDP is attached to the Desktop instance — happy to run specific state inspections (DOM/model-catalog state dumps) on request.

[4sj9wrhgbp]

Version correction (important): the machine is actually on CodexHost v0.9.0 — my earlier comment said 0.8.2 because the exe''s embedded FileVersion resource was not bumped for the v0.9.0 build (distribution.json and the app content confirm v0.9.0; SHA-256 unchanged across checks).

So the live reproduction captured earlier today (composer stuck "Loading models..." ×5 in the DOM, sends blocked, intermittent self-heal) happened on v0.9.0 itself, with the #302 fix included — the fix did not fully resolve this on Windows, and it now reproduces on the latest Desktop (26.908.9136.0) as well.

Requesting reopen stands, with higher priority: latest CodexHost + latest Desktop, functional send-block, deterministic-enough repro.