Our reports and the fixes that followed — a timeline table, shared as a record rather than a claim **[Update 2026-09-18: re-verified on 0.1.6-alpha.2; two rows corrected]**

[yamingmou]

EN / English

Important

Update — 2026-09-18. This is an append, not a rewrite. Every row of Table B has been re-verified against a newer build — 0.1.6-alpha.2 (released 09-17, i.e. after this post) instead of 0.1.5-rc.2 — and the Basis column below now reads 0.1.6-alpha.2. All ten rows still hold: we found no fix for any of them on that build, so each "unfixed" row is now anchored to the newest alpha rather than to rc.2.

Two rows in Table A described the code inaccurately and are corrected below:

• [Analysis] mcp-client activeServerNames: root cause is a scope mismatch, not a missed cleanup — and the proposed "defensive cleanup" is unsafe (#3984 follow-up) #4025 — we wrote that the leak had no explicit teardown. That is not what the code does: the registry removes the name when the effect is disposed (return () => void names.delete(...) in dsh-mcp-client). What still holds is the scope keying (scopeOf(ctx) ?? ctx.root) — our original point;
• [Bug] A misbehaving MCP server can hang the app forever while listing its tools #5905 — we wrote that 0.1.5-alpha.2 rejects repeated cursors, and left it as the current behaviour. The first half stands, the second does not: on 0.1.6-alpha.2 that manual pagination loop and its cursor guard are gone, and tool listing is delegated to the MCP SDK (client.listTools(…, { cacheMode: "refresh" })). We have not re-tested whether the original hang still reproduces, so the row now says only what the code says.

One row keeps its 🔴 and gains a note: #6532. 0.1.6-alpha.2 added an empty-completion guard that rc.2 did not have (blocks.size === 0 && stop → EMPTY_RESPONSE). Its predicate counts blocks, not visible content, so the shape we reported — a completion whose only blocks are reasoning — still passes as a legal stop. The row stays in Table B because our shape is still unmatched.

Everything else is unchanged.

First, what this is and is not. This is a table we assembled for our own records and are sharing in case it is useful: the reports we filed, and the version each fix shipped in. We are not claiming those fixes exist because of our reports. Some of them were plausibly already on the team's plan, or noticed independently by others; a timeline only shows what shipped after what was filed, which is not the same as cause. If any row overstates our part, or a correspondence is wrong, say so and we will change the wording or drop the row.

Three notes on how to read it:

• "Correspondence" is our own judgment, reached by reading the source on the version in question — it is not an official statement;
• Dates: the filing date of the report, and the official Release publication date of the fix (both UTC+8). Release dates, not npm dates — one of these versions (0.1.3-alpha.1) was released on GitHub without a matching npm publish;
• Table B is deliberately not a scoreboard. It lists reports where we could not find a fix — open items on our side; we may simply have missed one.

Important

How to read the colour on each row
🟢 matches — the fix lines up with the mechanism we reported · 🟠 partial / residual — a fix shipped, but a boundary or residual remains · 🔴 unfixed — we could not find the fix on the version we checked

A. Reports where a fix shipped afterwards

Report	Area	What we reported	Filed	Fix version	Shipped	Gap	Status
#3633	session storage	Session writes had no lock — multiple writers could silently corrupt a shared home	08-20	0.1.3-alpha.1	09-04	15 d
#3662 · #3664	subagent lifecycle	Cancelling a task that had spawned subagents could permanently corrupt the session	08-20	0.1.5-rc.2	09-10	21 d
#3994	background jobs	Finished background-job records were never reclaimed	08-22	0.1.5-rc.2	09-10	19 d
#4025	MCP client	The client's registry leaked across lifecycle scopes, eventually blocking new sessions	08-22	0.1.5-rc.2	09-10	19 d
#4793	subagent lifecycle	Disposing a parent agent did not propagate to its continuable subagents	08-28	0.1.5-rc.1 · 0.1.5-rc.2	09-10	13 d
#4910	session format	Every persistence format hard-refused non-current versions, with no migration path	08-28	0.1.3-alpha.1 · 0.1.5-rc.1	09-04	7 d
#5905	MCP client	A misbehaving MCP server could hang the app forever listing its tools	09-08	0.1.5-alpha.2	09-09	1 d

Where a fix shipped but something remains (the 🟠 rows), so nobody has to dig:

• [Bug] [Update 2026-09-19] Missing session-level lock silently corrupts shared-home deployments — impact upgrade: any multi-writer topology destroys the durable work record (self-review of our own bug report) #3633 — the lock landed in 0.1.3-alpha.1 ("at most one process per session"); on our side the runtime still has none, and that lock conflicts with our second-process tooling;
• [Bug] Terminal background-job records are never reclaimed in a live session: unbounded store growth, O(n) list/start scans, and a silent memory footprint that grows with session age #3994 — owner-scoped reclamation landed, but the cancel-does-not-settle hang is still documented as present in the official README;
• [Analysis] mcp-client activeServerNames: root cause is a scope mismatch, not a missed cleanup — and the proposed "defensive cleanup" is unsafe (#3984 follow-up) #4025 — switched to owner-scoped WeakMap access; the residual is the scope keying (scopeOf(ctx) ?? ctx.root). (Corrected 09-18: an earlier version of this bullet also said there was "no explicit teardown" — the registry does delete the name on effect disposal.)
• [Bug] A misbehaving MCP server can hang the app forever while listing its tools #5905 — 0.1.5-alpha.2 rejected repeated cursors. (Corrected 09-18: that manual loop and its guard are no longer present on 0.1.6-alpha.2 — tool listing is delegated to the MCP SDK; the original loop has not been re-tested.)

B. Reports we have not been able to match to a fix

Listed for completeness, not as a demand — if a fix exists that we missed, we would rather be corrected than keep an outdated row.

Report	Area	What we reported	Filed	Basis we checked	Status
#3631	session reading	A valid session that ends mid-turn is silently treated as "no more history"	08-20	0.1.6-alpha.2
#4795	session reading	(analysis) Why a valid session silently becomes "no more history"	08-28	0.1.6-alpha.2
#4549	scheduler / tool calls	A scheduler failure leaves a tool call with no result, wedging the session	08-26	0.1.6-alpha.2
#5692	session editing	Editing or revoking a message scrambles the window pagination	09-05	0.1.6-alpha.2
#5917	MCP client	Saving a tool's image result can hang the session — the storage step has no deadline	09-08	0.1.6-alpha.2
#5920	compaction / metering	/compact fails forever once a plugin writes a marker with a null turn/step	09-08	0.1.6-alpha.2
#6067	goals	An orphan goal/complete (no matching create) makes the session unresponsive	09-10	0.1.6-alpha.2
#6491	ACP / session derivation	ACP treats a parent session as a subagent marker, hiding forked sessions	09-13	0.1.6-alpha.2
#6514	compaction	A compaction span written by an older version became unaddressable	09-13	0.1.6-alpha.2
#6532	output verdict	A turn with no visible content passed as a legal stop	09-13	0.1.6-alpha.2

Related: @PerryLink's #6520 is the community-verified list of what is still unfixed on master — it is the more rigorous artefact for that question, and we are adding one entry there rather than duplicating it here. This post is only the other direction of the same timeline: what was filed, and what shipped afterwards.

Data sources: report numbers and filing dates from the community discussions; fix dates from the official GitHub Releases (UTC+8). Corrections welcome — we will re-verify against the toolchain and update this post.

Authorship note: reproduced and measured by me against my own store; root-cause tracing and drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版 / ZH

Important

更新 —— 2026-09-18。这是追加说明，不是改写。 B 表每一行都已换到更新的构建上重核 —— 从 0.1.5-rc.2 改为 0.1.6-alpha.2（09-17 发布，即本帖发布之后），下表的「复核基准」列现已写为 0.1.6-alpha.2。十行结论全部维持：在该构建上我们仍未找到任何一行的修复，因此每一行"未修"现在都挂在最新 alpha 上，而不是 rc.2。

A 表有两行对代码的描述不准确，已逐条更正：

• [Analysis] mcp-client activeServerNames: root cause is a scope mismatch, not a missed cleanup — and the proposed "defensive cleanup" is unsafe (#3984 follow-up) #4025 —— 我们写过该泄漏没有显式 teardown。代码并非如此：注册表会在 effect 释放时删除名字（dsh-mcp-client 里 return () => void names.delete(...)）。仍然成立的是「作用域分桶」（scopeOf(ctx) ?? ctx.root）—— 那才是我们原本的论点；
• [Bug] A misbehaving MCP server can hang the app forever while listing its tools #5905 —— 我们写过 0.1.5-alpha.2 拒绝重复游标，且把它当作当前行为。前半句成立，后半句不成立：在 0.1.6-alpha.2 上，那段手写分页循环与游标守卫已不存在，工具列举改由 MCP SDK 完成（client.listTools(…, { cacheMode: "refresh" })）。我们尚未实测原形态是否仍可复现，因此该行现在只写代码所显示的事实。

另有一行保留 🔴、但要加一句说明：#6532。 0.1.6-alpha.2 新增了 rc.2 没有的「零块完成」守卫（blocks.size === 0 && stop → EMPTY_RESPONSE）。但该判据数的是块数、不是可见内容，因此我们报的形态 —— 整轮只有 reasoning 块 —— 仍以合法 stop 通过。该行仍留在 B 表，因为我方报的形态仍未被覆盖。

其余一切未变。

先说清这是什么、不是什么。 这份表是我们为自己留档整理的，顺手放出来看有没有用：我们提交过的报告，以及每个修复出现在哪个版本。我们并不主张"这些修复是因为我们的报告才有的" —— 其中一些很可能本来就在官方的计划里，或者是别人独立发现的；时间线只能说明"谁在谁之后"，不等于因果。如果哪一行高估了我们的作用，或者对应关系有误，请直接说，我们会改措辞或撤掉那一行。

读这张表的三点说明：

• 「对应度」是我们自己的判断 —— 靠阅读相应版本的源码得出，不是官方声明；
• 日期 = 报告提交日 + 修复的官方 Release 发布日（均为北京时间）。用 Release 日期而不是 npm 日期 —— 其中 0.1.3-alpha.1 只发了 GitHub Release、没有对应的 npm 发布；
• B 表故意不做成记分牌：它列的是"我们找不到对应修复"的报告 —— 那只是我方视角下的待办，也可能是我们漏看了修复。

Important

怎么读每行的颜色
🟢 matches（对得上） —— 修复与我们报的机制一致 · 🟠 partial / residual（部分·有残留） —— 有修复发布，但边界或残留仍在 · 🔴 unfixed（未修） —— 在我们复核的版本上找不到修复

A. 报告之后有修复发布的

报告	方向	我们报的什么	报告于	修复版本	发布于	间隔	状态
#3633	会话存储	会话写入没有锁，多个写入者会静默写坏共享目录	08-20	0.1.3-alpha.1	09-04	15 天
#3662 · #3664	子代理生命周期	取消一个派生过子代理的任务，会永久写坏会话	08-20	0.1.5-rc.2	09-10	21 天
#3994	后台任务	已结束的后台任务记录永不回收	08-22	0.1.5-rc.2	09-10	19 天
#4025	MCP 客户端	客户端注册表跨生命周期作用域泄漏，最终无法新建会话	08-22	0.1.5-rc.2	09-10	19 天
#4793	子代理生命周期	释放父 agent 时不传播到可续子 agent	08-28	0.1.5-rc.1 · 0.1.5-rc.2	09-10	13 天
#4910	会话格式	所有持久化格式硬拒非当前版本，且零迁移路径	08-28	0.1.3-alpha.1 · 0.1.5-rc.1	09-04	7 天
#5905	MCP 客户端	MCP 服务器反复返回同一分页游标时，列举工具会无限循环	09-08	0.1.5-alpha.2	09-09	1 天

「有修复、但还有残留」的几行（🟠）逐条说明，免得大家自己去挖：

• [Bug] [Update 2026-09-19] Missing session-level lock silently corrupts shared-home deployments — impact upgrade: any multi-writer topology destroys the durable work record (self-review of our own bug report) #3633 —— 锁在 0.1.3-alpha.1 落地（"同一 session 至多被一个进程持有"）；但我方运行时侧仍无锁（自备兜底），且该锁与我方第二进程工具链冲突；
• [Bug] Terminal background-job records are never reclaimed in a live session: unbounded store growth, O(n) list/start scans, and a silent memory footprint that grows with session age #3994 —— owner 级回收已落地，但"取消不 settle"的悬挂风险在官方 README 里仍被明示存在；
• [Analysis] mcp-client activeServerNames: root cause is a scope mismatch, not a missed cleanup — and the proposed "defensive cleanup" is unsafe (#3984 follow-up) #4025 —— 改为按 owner 存取 WeakMap；仍然成立的是「作用域分桶」（scopeOf(ctx) ?? ctx.root）。（09-18 更正：本行早先还写过"无显式 teardown"—— 实际注册表会在 effect 释放时删除名字。）
• [Bug] A misbehaving MCP server can hang the app forever while listing its tools #5905 —— 0.1.5-alpha.2 拒绝的是重复游标。（09-18 更正：那段手写循环与守卫在 0.1.6-alpha.2 上已不存在，工具列举改由 MCP SDK 完成；原形态是否仍可复现尚未实测。）

B. 我们找不到对应修复的报告

列在这里只为完整，不是催单 —— 若有我们漏看的修复，我们更愿意被纠正，而不是留着过期的行。

报告	方向	我们报的什么	报告于	复核基准	状态
#3631	会话读取	一个合法但中断的会话，被静默当成「没有更多历史」	08-20	0.1.6-alpha.2
#4795	会话读取	（分析）为什么合法会话会静默变成「没有更多历史」	08-28	0.1.6-alpha.2
#4549	调度 / 工具调用	调度失败留下一个没有结果的工具调用，会话被卡死	08-26	0.1.6-alpha.2
#5692	会话编辑	编辑或撤回消息会打乱窗口分页	09-05	0.1.6-alpha.2
#5917	MCP 客户端	保存工具图片结果会挂住会话 —— 存储阶段没有截止时间	09-08	0.1.6-alpha.2
#5920	压缩 / 计量	插件写入回合为空的标记后，/compact 永久失败	09-08	0.1.6-alpha.2
#6067	任务目标	孤儿的 goal/complete（无对应创建）令会话无响应	09-10	0.1.6-alpha.2
#6491	ACP / 会话派生	ACP 把父会话当作子代理标记，派生出的会话被隐藏	09-13	0.1.6-alpha.2
#6514	会话压缩	旧版本写入的压缩跨度变得不可寻址	09-13	0.1.6-alpha.2
#6532	输出判据	整轮没有可见内容，却通过了「合法结束」的判定	09-13	0.1.6-alpha.2

相关：@PerryLink 的 #6520 是社区核实的「master 上仍未修」清单 —— 那个问题它做得比我们严谨，我们只在那边补一条，不在这里重复。本帖只是同一条时间线的另一个方向：提交了什么，之后发布了什么。

数据来源：报告编号与提交日取自社区帖；修复日期取自官方 GitHub Releases（北京时间）。欢迎指正，我们会对照工具链重新核实并更新本帖。

声明：本次实测与统计由我针对自己的数据完成；根因追查与文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com