[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)

[yamingmou]

Self-review update — correction of our own submitted bug report / 自我修正：对本人提交的 bug report 的修正 (2026-08-22)

⚠️ This is a self-review of the bug report we submitted. The original report was accurate but under-stated the impact. After re-reading the engine source, we are upgrading the assessment: the defect is confirmed, and it is broader than "two instances by accident" — the engine coordinates writers within one process only (an in-process coordinator), and the durable file backend appends with no lock and no writer detection (open(path, "a")). Any topology with more than one writer against a shared home — an interactive session plus a background/scheduled job, or multiple processes in parallel — is unsafe by design, and the corruption is silent and durable.

TL;DR — EN: We originally reported "two running instances silently corrupt the same session log." Upgrade: the single-writer assumption is a deliberate design (writers are coordinated in-process only — dsh-session-persistence/lib/index.js:17-20, :55), but nothing enforces it at the durable layer: the file backend opens the log in plain append mode with no lock, no exclusive flag, and no foreign-writer detection (dsh-session-persistence-jsonl/lib/index.js:1200-1227, open(path, "a") at :1203). A second process writing the same log is undetected until the session is already corrupt, with no warning at launch or at write time. For any deployment that schedules or multiplies agent processes against a shared home, the entire history — the progress/audit record — can be silently destroyed.

一句话（中文）： 这是对本人提交的 bug report 的自我修正（升级）。原报告准确但低估了影响：单写者假设是明确设计（写者只在进程内协调——dsh-session-persistence/lib/index.js:17-20、:55），但持久化层没有任何强制手段：文件后端以纯追加模式打开日志，无锁、无排他标志、无外部写者检测（dsh-session-persistence-jsonl/lib/index.js:1200-1227，:1203 的 open(path, "a")）。第二个进程写入同一日志，直到会话已损坏才会被发现，启动与写入时均无警告。任何把 agent 进程调度化/多开并共享主目录的部署，其全部历史——进度/审计记录——都可能被静默摧毁。

What we originally claimed / 初版表述 (EN): no session-level locking; two running instances silently corrupt the same session log; permanent loss of UI access; manual recovery required.
What we now state / 现修正 (EN): confirmed, and upgraded — the single-writer model is intentional but only enforced in-process; the durable layer has no lock and no writer detection, so any multi-writer topology (interactive + scheduled job, parallel processes) is unsafe by design; corruption is silent and durable, destroying the entire progress/audit record; the engine gives operators no signal until it is too late.

初版表述（中文）： 无会话级锁；两个运行实例并发写同一会话日志、静默损坏；会话永久失去 UI 访问；需要手工恢复。
现修正（中文）： 确凿，且升级——单写者模型是有意设计，但只在进程内强制；持久化层无锁、无写者检测，因此任何多写入者拓扑（交互+调度任务、多进程并行）在设计上都不安全；损坏静默且持久，摧毁整份进度/审计记录；引擎在为时已晚之前不会给运维任何信号。

---

EN / English

Follow-up — 2026-09-19: the harness has since shipped a session-level lock

What changed upstream. The release notes for dsh-v0.1.3-alpha.1 (2026-09-04) state: "Breaking change: the session persistence API now uses a lifecycle-held SessionHandle; agentLoop.create() becomes async, and a session lock was added — a session is held by at most one process." (The same line is restated in dsh-v0.1.5-rc.1, 09-10.) Source: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.1.3-alpha.1

For the mechanism this report argued — that the single-writer assumption holds only in-process — that is the direct response.

What we are not claiming. We have not re-tested this lock on the newer version, so we do not read it as "this report is fixed". The measurements in this report were taken on 0.1.1-rc.2 (which had no session-level lock); the lock's actual effect on a shared home across processes, and how it interacts with the second-writer toolchain described here, have not been reviewed by us. The findings below therefore stand as written — this section only records the upstream change so readers can check for themselves.

Boundaries. The quotation above is the official release note (URL included); no source-level review and no re-test were performed for this section. If the maintainers consider the lock to have already superseded this report, please say so and we will correct the status accordingly.

---

Observed behavior

When two dsh instances run against the same ~/.dsh home (e.g. an interactive session and a background/scheduled process sharing the home), both instances append to the same session.jsonl.zstd with independent seq counters. The result is duplicated seq ranges written out of order — violating the session log's core invariant of strictly monotonic, contiguous seq — and the session becomes permanently unreadable:

corrupt session log: seq gap in committed region at line N (expected X, got Y)

Confirmed empirically: a session repaired minutes earlier was corrupted again solely by the second instance writing.

Root cause — the single-writer assumption is in-process only

The engine does coordinate writers — but within one process. dsh-session-persistence ships a per-coordinator registry with exclusive reservation of unpublished sessions (dsh-session-persistence/lib/index.js:17-20, :55, :167). That protects one process from itself.

The durable file backend, however, has no cross-process protection: appendLines opens the log in plain append mode — open(path, "a") (dsh-session-persistence-jsonl/lib/index.js:1203) — writes and fsyncs (:1211-1214), with rollback only on its own write failure (:1215-1223). There is no lock file, no O_EXCL, no inode/seq validation against a foreign writer, and no startup check for another process holding the home.

So the single-writer model is a deliberate design (in-process coordinator) whose durable enforcement is absent. A second writer is undetected at launch and at write time; corruption is only discovered later, and only as a read error.

Impact scope (upgraded — production / progress / scheduling)

• Any multi-writer topology is unsafe by design: an interactive session plus a background/scheduled job sharing one home; several processes in parallel; any deployment where more than one writer can reach the same home. For deployments that schedule or multiply agent processes, this is a realistic operational topology, not an accident.
• The corruption is silent and durable: duplicated seq ranges are written out of order, the session becomes permanently unreadable, and nothing warns at launch or at write time. The entire history — the progress/audit record of the work — is destroyed, and the only recovery is manual log surgery.
• The blast radius is the whole home: because seq counters are per-instance, the conflict is not confined to one session — every session the two instances touch in parallel is at risk.

Expected behavior

• Per-session (or per-home) durable locking: a second writer should refuse to write, or detect the conflict and recover.
• At minimum, a write-time writer check (validate the file's last seq/inode against the instance's own counter before appending) and a startup warning when the home appears to be in use by another process.

Repro

1. Start one instance (engine loads ~/.dsh/sessions).
2. Start a second instance while the first is still running.
3. Continue a conversation in one instance for a few minutes.
4. The shared session log now contains duplicated/out-of-order seq → seq gap, history unavailable.

Environment

• Engine: @deepseek-ai/dsh 0.1.0-rc.6 / 0.1.0-rc.7, same ~/.dsh home.
• Also verified on: @deepseek-ai/dsh 0.1.1-rc.2
• Confirmed empirically: a session repaired minutes earlier was corrupted again solely by the second instance writing.

Evidence (sanitized + source)

line 37058: expected seq 693898, got 683973   <- duplicated range from the second writer

• dsh-session-persistence/lib/index.js:17-20, :55, :167 — in-process coordinator: exclusive reservation and write rejection within one process only.
• dsh-session-persistence-jsonl/lib/index.js:1200-1227 — appendLines: open(path, "a") (:1203), write + fsync, rollback only on own failure; no lock, no exclusive flag, no foreign-writer detection.

---

Authorship note: reproduced and documented by me in real-world usage; 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.

中文版 / ZH

后续进展 —— 2026-09-19：引擎已加入 session 级锁

上游变化。 dsh-v0.1.3-alpha.1（2026-09-04）的 release notes 写明：「破坏性变更： Session persistence API 改为由生命周期持有的 SessionHandle；agentLoop.create() 改为异步，新增 session 锁，同一 session 至多被一个进程持有。」（dsh-v0.1.5-rc.1，09-10 重申同一条。）原文：https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.1.3-alpha.1

就本报告当初主张的机制 —— 单写者假设只在进程内成立 —— 而言，这条正是对它的回应。

我方不主张的部分。 我们没有在新版本上复测这个锁，因此不把它读作"本条已修复"。本报告的实测样本取自 0.1.1-rc.2（当时确无 session 级锁）；该锁对多进程共享同一 home 的实际效果，以及它与本报告所述"第二写入者工具链"的相互作用，我方均未复核。所以下述结论维持原状 —— 这一段只记录上游变化，供读者自查。

边界。 以上引文为官方 release notes 原文（含 URL）；本段未做源码级复核，也未复测。若维护者认为该锁已使本条失效，请直接说明，我们会据此更正本条状态。

---

现象

当两个 dsh 实例共用同一个 ~/.dsh 主目录（例如交互会话与一个后台/调度进程共享主目录）时，两个实例会以各自独立的 seq 计数器向同一个 session.jsonl.zstd 追加内容。结果：重复的 seq 段乱序写入——破坏会话日志"seq 严格单调连续"的核心不变量——会话永久不可读：

corrupt session log: seq gap in committed region at line N (expected X, got Y)

实测实证：刚修复好的会话，仅因第二个实例写入而再次损坏。

根因 —— 单写者假设只在进程内成立

引擎确实协调写者——但只在单个进程内。dsh-session-persistence 带有一个按 coordinator 组织的注册表，对未发布会话做排他保留（dsh-session-persistence/lib/index.js:17-20、:55、:167）。这保护的是"一个进程不和自己打架"。

而持久化文件后端没有跨进程保护：appendLines 以纯追加模式打开日志——open(path, "a")（dsh-session-persistence-jsonl/lib/index.js:1203）——写入并 fsync（:1211-1214），只在自身写失败时回滚（:1215-1223）。没有锁文件、没有 O_EXCL、没有针对外部写者的 inode/seq 校验、也没有启动时对"另一进程正持有该主目录"的检查。

所以，单写者模型是有意设计（进程内 coordinator），但它的持久化强制手段缺失。第二个写者在启动时、写入时都不会被发现；损坏只在事后以读错误的形式暴露。

影响范围（升级 —— 生产 / 进度 / 调度）

• 任何多写入者拓扑在设计上都不安全：交互会话与后台/调度任务共用一个主目录；多个进程并行；任何"多于一个写者可达同一主目录"的部署。对把 agent 进程调度化/多开的部署，这是现实的操作拓扑，不是意外。
• 损坏静默且持久：重复 seq 段乱序写入、会话永久不可读，启动与写入时均无警告。全部历史——工作的进度/审计记录——被摧毁，唯一恢复途径是手工外科手术式编辑日志。
• 爆炸半径是整片主目录：seq 计数器按实例独立，冲突不限于单个会话——两个实例并行触碰的每一个会话都处于风险中。

期望行为

• 会话级（或主目录级）持久化锁：第二个写者应拒绝写入，或检测到冲突并自动恢复。
• 至少要有写入时的写者检查（追加前校验文件末尾 seq/inode 与本实例计数一致）和启动时警告（主目录疑似被另一进程占用）。

复现步骤

1. 启动第一个实例（引擎加载 ~/.dsh/sessions）。
2. 在第一个实例仍运行时启动第二个实例。
3. 在任一实例中继续对话几分钟。
4. 共享的会话日志出现重复/乱序 seq → seq gap，历史不可用。

环境

• 引擎：@deepseek-ai/dsh 0.1.0-rc.6 / 0.1.0-rc.7，同一 ~/.dsh 主目录。
• 另已在：@deepseek-ai/dsh 0.1.1-rc.2 上验证
• 实测实证：刚修复好的会话，仅因第二个实例写入而再次损坏。

证据（脱敏 + 源码）

line 37058: expected seq 693898, got 683973   <- 来自第二个写入者的重复 seq 段

• dsh-session-persistence/lib/index.js:17-20、:55、:167 —— 进程内 coordinator：排他保留与写入拒绝仅在同一进程内生效。
• dsh-session-persistence-jsonl/lib/index.js:1200-1227 —— appendLines：open(path, "a")（:1203）、写入 + fsync、仅在自身失败时回滚；无锁、无排他标志、无外部写者检测。

---

Original report (archived for transparency) / 初版报告（归档保留）

以下为初版表述（被上方"自我修正"升级）。保留以透明展示我们修正了什么。

EN

Observed behavior (original). When two dsh instances run against the same ~/.dsh home (e.g. desktop shell + dsh web) and the user continues a conversation, both instances append to the same session.jsonl.zstd with independent seq counters. The result is duplicated seq ranges written out of order, and the session becomes permanently unreadable.

Impact scope (original). Permanent loss of UI access to sessions (history unavailable); manual recovery required. Silent — no warning at launch or at write time; corruption is only discovered later. Realistic scenario: user opens the desktop app and a dsh web session without realizing they share ~/.dsh.

中文

现象（初版）。 当两个 dsh 实例共用同一个 ~/.dsh 主目录，用户在其中任一实例继续对话时，两个实例会以各自独立的 seq 计数器向同一个 session.jsonl.zstd 追加内容。结果：重复的 seq 段乱序写入，会话永久不可读。

影响范围（初版）。 会话永久失去 UI 访问（历史不可用），需要手工恢复。静默发生——启动时、写入时都没有警告，用户事后才发现损坏。真实场景：用户同时开着桌面应用和一个 dsh web，不知道它们共用 ~/.dsh。

---

署名 / About this report

EN: Reported by the OfferKuai (Offer快) Team — an AI startup building full-lifecycle job-application services, guided by the belief that "users need results, not repeated conversations." Founder: Zhaofeng (Yaming). We use DeepSeek Harness as part of our daily development workflow; this report is our way of contributing back to the ecosystem. Website: https://www.offerkuai.com/ | Contact: <contact@offerkuai.com>

ZH: 本报告由 OfferKuai（Offer快）团队提交 —— 一家专注 AI 全流程求职托管的创业团队，核心理念是「用户要的是结果，不是重复对话」。创始人：Zhaofeng（Yaming）。我们将 DeepSeek Harness 用于日常开发工作流，这份报告是我们对社区的回馈。官网：https://www.offerkuai.com/ | 联系：<contact@offerkuai.com>

---

协作说明：本文由我在真实使用中复现并记录；根因与成文由 AI 协助完成，我负责校验与发布。我非工程背景，技术表述如有错误，欢迎指出——我会回去用工具链重新验证后更正。

[yamingmou]

→ 粘贴到 GitHub 的评论框

Closing this one out. We re-checked it against 0.2.0-rc.2 on 2026-10-07 and rolled it into one follow-up — #9104 — which lists what each of the eleven August reports looks like now, and names the official note each one runs up against. Partly shipped: a real cross-process lease landed. That post's section 2 has this report's row. Nothing further is needed here.

Authorship note: drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out.

Reported by the OfferKuai Team.

中文版

收口。这一条我们已于 2026-10-07 对着 0.2.0-rc.2 重核，并并到一个后续里 —— #9104 —— 那帖列出 8 月那十一帖各自现在是什么样，也标了每一条撞上的官方记录。部分已落地：真正的跨进程租约已经有了。 那帖第 2 节里有本条对应的一行。这里不需要再做任何事。

协作说明：成文由 AI 协助完成，我负责校验与发布。我非工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。

本报告由 OfferKuai（Offer快）团队提交。