You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and this is not a duplicate. 我已搜索过现有 issue。
What happened? 发生了什么?
Context compression failed and encountered an error.
Warn 本回合失败: Making room failed: Chat API response missing choices
If you try to establish a new session at this time, it will fail, including using /new --force to create the session.
Note Error: Cannot start a new session while runtime work is active. Wait for the current turn, maintenance, and background tasks to finish, or cancel that specific work. /new --force only discards draft or queued input.
Steps to reproduce 复现步骤
After the session is completed, perform the context compression operation.
Codewhale version 版本
0.10.1
Where did it happen? 在哪里出现?
TUI (terminal interface)
Operating system 操作系统
Windows
How did you get Codewhale? 获取方式
Scoop / Nix / Docker / other package
Provider and model 提供商和模型
DeepSeek-v4.1-flash by Cline
Terminal and shell 终端
Windows Terminal
codewhale doctor (optional)
My model is accessed through the [Sub2API v0.2.16](https://github.com/Wei-Shaw/sub2api/releases/tag/v0.2.16) gateway, and the model service provider is Cline. Normal sessions have not encountered any errors.
Thanks for including the Sub2API/Cline route and the fact that ordinary conversations still work. Compaction sends a non-streaming request (stream: false); this particular error means the returned JSON has no choices array. The response shape is still unknown, so we have not identified a gateway compatibility fix.
Could you share the failed compaction response’s HTTP status, Content-Type and top-level JSON keys (or a sanitized error object), plus whether any background agent or shell job remains queued/running when /new is refused? Please omit credentials and conversation content.
The source already has a failure-settlement path, but that does not prove which state remains active on your machine. #6948, carried in the 0.10.2 candidate #6968, names the specific blockers. If you are testing a build containing 5530db9, the full refusal text and any named task IDs would narrow this down. That change improves diagnosis; we have not reproduced or verified a fix for this Windows case, and 0.10.2 is not released. Keeping this open.
@Hmbown I provided the response headers and the desensitized response body. Additionally, when this issue occurred, only this program was running, and there were no other background tasks.
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it. (本回复由 AI 代理 Claude Opus 5.5 代表 Codewhale 维护者撰写,经 @Hmbown 的账号发布,并非 Hunter 本人所写。)
Thank you @luestr. The response headers and sanitized body were exactly what was needed. They show the gateway returning HTTP 200 with the completion wrapped as {"data": {"choices": ...}, "success": true}. Codewhale's non-streaming parser only read a top-level choices, so every non-streaming call on that route failed with "Chat API response missing choices". That includes compaction ("Making room failed"), the doctor live probe and review. Streaming turns use a different parser, which is why ordinary conversation kept working.
a38062b (on main) reads id, model, choices and usage from data only when all three of these hold:
top-level choices is absent;
success is the boolean true;
data.choices is an array.
Standard responses parse as before, and an envelope with success: false still reports an error. The fix is part of the 0.10.2 release candidate (9f25ef0). That candidate is still in testing and not released yet.
What was verified:
I ran a local mock gateway that returns your body shape. The current 0.10.2 development build reproduces your exact error, and the fixed build compacts the session ("Made room: 2 → 4 messages").
doctor --probe-local fails before the fix and passes after it.
It was not tested against a real Sub2API/Cline gateway or on Windows. When 0.10.2 is out, a quick confirmation on your setup would be very welcome.
The /new refusal you saw after the failed compaction ("Cannot start a new session while runtime work is active") is a separate problem, and this fix does not change it. We will follow up on it in this issue.
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it. (本回复由 AI 代理 Claude Opus 5.5 代表 Codewhale 维护者撰写,经 @Hmbown 的账号发布,并非 Hunter 本人所写。)
Follow-up on the /new refusal ("Cannot start a new session while runtime work is active") that @luestr reported alongside the compaction failure.
We found one way a session gets stuck there. A "Making room…" pass may still be running or queued when Codewhale replaces its engine. That happens when you switch provider, model route, profile or workspace, when plugins reload, or when Codewhale falls back or rolls back to another provider. The old engine's result then never reaches the session, so the session keeps treating compaction as active. /new, /resume and /compact are refused until restart. 8f54845 and 856eefa (on main) stop or settle the old pass when the engine is replaced. The transcript then shows "Making room stopped; the conversation was not changed", and /new works again.
This is not in 0.10.2, which is already frozen. It is queued for the release after it. It was checked with focused tests and a TUI run that switched provider during Making room. It has not been checked on Windows or against your gateway.
We have not confirmed this is the path you hit. Between the failed compaction and /new, did you switch provider or model, or did Codewhale move to another provider? If neither happened, a short note on what you did in between would help us find the remaining path.
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it. (本回复由 AI 代理 Claude Opus 5.5 代表 Codewhale 维护者撰写,经 @Hmbown 的账号发布,并非 Hunter 本人所写。)
Thanks @luestr, that rules out the provider-switch path. It is not what you hit.
We then tried to reproduce your sequence without any switch. We used the official v0.10.1 macOS release binary (SHA-256 matches the release manifest) and current main, against a local gateway whose non-streaming reply fails the same way ("Chat API response missing choices"). The sequence was: one turn, then /compact (fails with "Turn failed: Making room failed…"), then /new. In both builds /new started a new session, including when the failing compaction took 15 seconds, as yours did. So something else in your session held the gate, and the 0.10.1 refusal text does not say what.
0.10.2 helps with both halves:
It carries a38062b, which reads your gateway's {"data": {...}, "success": true} reply. Compaction on your route should no longer fail at all.
If /new is ever refused again, 0.10.2 lists each thing that is blocking it. For example: "the session is still busy with the current turn", "context compaction is running", "a manual compaction is queued", or a running task with its id. Pasting that list here would pinpoint it.
We have not reproduced your refusal, so it stays open until you have tested 0.10.2.
Activity
Hmbown commentedon Oct 15, 2026
Thanks for including the Sub2API/Cline route and the fact that ordinary conversations still work. Compaction sends a non-streaming request (
stream: false); this particular error means the returned JSON has nochoicesarray. The response shape is still unknown, so we have not identified a gateway compatibility fix.Could you share the failed compaction response’s HTTP status, Content-Type and top-level JSON keys (or a sanitized error object), plus whether any background agent or shell job remains queued/running when
/newis refused? Please omit credentials and conversation content.The source already has a failure-settlement path, but that does not prove which state remains active on your machine. #6948, carried in the 0.10.2 candidate #6968, names the specific blockers. If you are testing a build containing 5530db9, the full refusal text and any named task IDs would narrow this down. That change improves diagnosis; we have not reproduced or verified a fix for this Windows case, and 0.10.2 is not released. Keeping this open.
luestr commentedon Oct 16, 2026
@Hmbown I provided the response headers and the desensitized response body. Additionally, when this issue occurred, only this program was running, and there were no other background tasks.
fix(client): unwrap a gateway's {data, success} envelope on non-strea…
docs(changelog): carry the post-candidate fixes into 0.10.2
Hmbown commentedon Oct 16, 2026
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it.
(本回复由 AI 代理 Claude Opus 5.5 代表 Codewhale 维护者撰写,经 @Hmbown 的账号发布,并非 Hunter 本人所写。)
Thank you @luestr. The response headers and sanitized body were exactly what was needed. They show the gateway returning HTTP 200 with the completion wrapped as
{"data": {"choices": ...}, "success": true}. Codewhale's non-streaming parser only read a top-levelchoices, so every non-streaming call on that route failed with "Chat API response missing choices". That includes compaction ("Making room failed"), thedoctorlive probe and review. Streaming turns use a different parser, which is why ordinary conversation kept working.a38062b (on
main) readsid,model,choicesandusagefromdataonly when all three of these hold:choicesis absent;successis the booleantrue;data.choicesis an array.Standard responses parse as before, and an envelope with
success: falsestill reports an error. The fix is part of the 0.10.2 release candidate (9f25ef0). That candidate is still in testing and not released yet.What was verified:
doctor --probe-localfails before the fix and passes after it.It was not tested against a real Sub2API/Cline gateway or on Windows. When 0.10.2 is out, a quick confirmation on your setup would be very welcome.
The
/newrefusal you saw after the failed compaction ("Cannot start a new session while runtime work is active") is a separate problem, and this fix does not change it. We will follow up on it in this issue.简要:a38062bd07 修复了网关以
{data, success}包装非流式响应导致的上下文压缩失败。该修复将包含在尚未发布的 0.10.2 中;压缩失败后/new被拒绝的问题会在本 issue 中另行跟进。— Written by Claude Opus 5.5 (AI agent) on behalf of the maintainers.
luestr commentedon Oct 16, 2026
@Hmbown I will wait for the new version to be released and then test and verify it as soon as possible.
fix(tui): settle Making room when an engine is replaced so /new is no…
fix(tui): localize the engine-switch Making room receipts and toast t…
Hmbown commentedon Oct 16, 2026
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it.
(本回复由 AI 代理 Claude Opus 5.5 代表 Codewhale 维护者撰写,经 @Hmbown 的账号发布,并非 Hunter 本人所写。)
Follow-up on the
/newrefusal ("Cannot start a new session while runtime work is active") that @luestr reported alongside the compaction failure.We found one way a session gets stuck there. A "Making room…" pass may still be running or queued when Codewhale replaces its engine. That happens when you switch provider, model route, profile or workspace, when plugins reload, or when Codewhale falls back or rolls back to another provider. The old engine's result then never reaches the session, so the session keeps treating compaction as active.
/new,/resumeand/compactare refused until restart. 8f54845 and 856eefa (onmain) stop or settle the old pass when the engine is replaced. The transcript then shows "Making room stopped; the conversation was not changed", and/newworks again.This is not in 0.10.2, which is already frozen. It is queued for the release after it. It was checked with focused tests and a TUI run that switched provider during Making room. It has not been checked on Windows or against your gateway.
We have not confirmed this is the path you hit. Between the failed compaction and
/new, did you switch provider or model, or did Codewhale move to another provider? If neither happened, a short note on what you did in between would help us find the remaining path.简要:在“Making room…”进行或排队时若引擎被替换(切换服务商、模型、配置或工作区,插件重载,或自动回退到其他服务商),会话会一直认为压缩仍在进行,从而拒绝
/new。8f54845f78 / 856eefa(已在main)修复了这一路径,但不在已冻结的 0.10.2 中,会随下一个版本发布。我们尚未确认这就是你遇到的情况:在压缩失败和/new之间,你是否切换过服务商或模型,或者 Codewhale 是否切换到了其他服务商?— Written by Claude Opus 5.5 (AI agent) on behalf of the maintainers.
luestr commentedon Oct 16, 2026
@Hmbown I've never switched service providers or models.
fix(tui): refuse provider switches while a turn is running (#2982 tur…
Hmbown commentedon Oct 16, 2026
🤖 This reply is from Claude Opus 5.5, an AI agent working on behalf of the Codewhale maintainers. It is posted through @Hmbown's account, but Hunter did not write it.
(本回复由 AI 代理 Claude Opus 5.5 代表 Codewhale 维护者撰写,经 @Hmbown 的账号发布,并非 Hunter 本人所写。)
Thanks @luestr, that rules out the provider-switch path. It is not what you hit.
We then tried to reproduce your sequence without any switch. We used the official v0.10.1 macOS release binary (SHA-256 matches the release manifest) and current
main, against a local gateway whose non-streaming reply fails the same way ("Chat API response missing choices"). The sequence was: one turn, then/compact(fails with "Turn failed: Making room failed…"), then/new. In both builds/newstarted a new session, including when the failing compaction took 15 seconds, as yours did. So something else in your session held the gate, and the 0.10.1 refusal text does not say what.0.10.2 helps with both halves:
{"data": {...}, "success": true}reply. Compaction on your route should no longer fail at all./newis ever refused again, 0.10.2 lists each thing that is blocking it. For example: "the session is still busy with the current turn", "context compaction is running", "a manual compaction is queued", or a running task with its id. Pasting that list here would pinpoint it.We have not reproduced your refusal, so it stays open until you have tested 0.10.2.
简要:你没有切换服务商,所以不是我们之前修复的那条路径。我们用官方 v0.10.1 发行版和当前
main,在不切换服务商的情况下复现了“压缩失败(missing choices)后执行/new”,两者都能正常新建会话(包括压缩耗时 15 秒的情况),因此你的会话里还有别的工作占用了门槛。0.10.2 包含 a38062b(能解析你网关的{"data": …}响应,压缩不应再失败),并且/new被拒绝时会逐条列出阻塞项。如果 0.10.2 中仍出现,请贴出那份列表。— Written by Claude Opus 5.5 (AI agent) on behalf of the maintainers.