[dsh-acp] session/list and session/resume treat parentSession as a subagent marker, so forked sessions are hidden and cannot be resumed

[yamingmou]

Summary. @deepseek-ai/dsh-acp@0.1.5-rc.2 refuses to list or resume any session whose header carries parentSession, OR-ing it together with the real subagent marker:

:1215  if (persisted === void 0 || persisted.origin === "subagent" || persisted.parentSession !== void 0)
         throw invalidParams(`session is not resumable: ${sessionId}`);
:1266  … || header.origin === "subagent" || header.parentSession !== void 0 || …

The two fields mean different things, and this is the only place in the release that conflates them. origin is the subagent marker; parentSession is lineage. A session created by the official fork path has parentSession and no origin, so it disappears from session/list and is rejected by session/resume — even though its log is intact and opens fine.

Related but distinct. This is not the same gap as #6322 (missing available_commands_update), #6324 or #6393 (no session/load / resume does not replay history). Those are about an ACP client rebuilding a transcript. This one is about which sessions ACP is willing to address at all: a session can be perfectly readable and still be excluded before any transcript question arises.

Where the two fields are kept apart elsewhere. Four sites in the same release:

1. dsh-session — the fork API writes parentSession and nothing else:

   fork(source, boundary, childSessionId) { … meta: { …, parentSession: liveSource.id, isSeeded: true } }

   So the official fork path produces exactly the header the ACP layer then refuses.
2. dsh-subagent — the delegation path is the only writer of origin, and it writes all three fields together:

   childSessionMeta(parent, childDepth, isSeeded)
     → { …, parentSession: parentHeader.id, isSeeded, origin: "subagent", delegationDepth: childDepth }

   and it identifies children by both fields, never by parentSession alone:
   record.header.parentSession === parentSessionId && record.header.origin === "subagent".
3. dsh-api-session-controller — subagent authorization also requires both:
   header.origin !== "subagent" || header.parentSession !== address.parentSessionId.
4. The header type declares them as two independent optional fields — parentSession?: SessionId and origin?: 'subagent' — and origin admits no value other than "subagent".

One site merges what four sites separate.

On documentation. dsh-acp's README lists fork among unsupported operations ("deletion, forks, transcript replay, and additional directories are unsupported"), and the session/list row says "persisted, resumable root sessions". So a "root only" reading of list is arguable. But the session/resume row states no such restriction — it says "A persisted inactive session whose canonical workspace is verified before composition" — and nothing in the README says a session with lineage metadata cannot be resumed. The :1215 condition exists only in the code, and the refusal message (session is not resumable: <id>) carries no reason.

Controlled experiment (4 headers, one field apart). Four synthetic v0 headers served by the shipped ACP server (dsh --profile acp): initialize → session/list → session/resume.

#	origin	parentSession	delegationDepth	in session/list	session/resume
R1	–	–	0	yes	ok
R2	subagent	set	1	no	refused
R3	–	set	0	no	refused
R4	–	set	1	no	refused

• R1 vs R3 differ in parentSession alone — resume goes from ok to refused. One variable, one flip.
• R3 vs R4 differ in delegationDepth alone — identical outcome, so depth is not consulted.
• All three refusals return the same string: Invalid params: session is not resumable: <id>.

Two further checks on real artifacts (108 MB and 80 MB of JSONL, both fork-derived, delegationDepth: 0, no origin):

• Removing only parentSession from the header, everything else byte-identical, flips them to openable: session/list shows them, session/resume returns ok, and the log migrates to v3.
• Repointing parentSession at a session that does not exist changes nothing — same message. The branch does not resolve the pointer; it only tests presence.

Measured blast radius (our store, read-only scan). Snapshot: 279 session directories, 248 of which carry parentSession.

header shape	sessions
origin: "subagent" (depth 1/2/3)	222
lineage only — no origin, depth 0	26
root (no parent)	31

The middle row is the problem: 26 ordinary forked main-line sessions. They are not delegated work, nothing owns them, and their logs are intact — but under 0.1.5 an ACP client cannot see them and cannot continue them. For a user that reads as "my sessions disappeared and will not reopen", which is hard to distinguish from data loss.

Scope. This is the ACP surface only — dsh-api-session-controller and the client paths never treat parentSession as a refusal, so desktop/web is unaffected. But ACP is what external ACP clients speak, and dsh-subagent-acp is the repository's own ACP client for out-of-process delegation.

Suggested fix. Narrow the predicate to the subagent marker — refuse on origin === "subagent" and keep parentSession as lineage metadata, matching the four sites above. Failing that, at least let a fork be resumed when its parent is resolvable; and if the ban is deliberate, state it in the README next to the session/resume row rather than only in the code.

Repro. Four header lines differing in one field each, placed under an isolated DSH_HOME, then initialize → session/list → session/resume. Script and raw output available on request; no session content, user name, or filesystem path is included here.

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

---

中文版

摘要。 @deepseek-ai/dsh-acp@0.1.5-rc.2 会拒绝 list / resume 任何 header 里带 parentSession 的会话，把它和真正的子代理标记用 || 并在一起：

:1215  if (persisted === void 0 || persisted.origin === "subagent" || persisted.parentSession !== void 0)
         throw invalidParams(`session is not resumable: ${sessionId}`);
:1266  … || header.origin === "subagent" || header.parentSession !== void 0 || …

这两个字段含义不同，而整个版本里只有这一处把它们混在一起。origin 是子代理标记；parentSession 只是世系来源。由官方 fork 路径产生的会话有 parentSession、没有 origin，于是它从 session/list 里消失、被 session/resume 拒绝 —— 而它的日志完好、本来打得开。

与相邻几条不同题。 这条不是 #6322（缺 available_commands_update），也不是 #6324 / #6393（没有 session/load、resume 不重放历史）—— 那几条讲的是 ACP 客户端如何重建一份 transcript。这一条讲的是 ACP愿意寻址哪些会话：一个会话可以完全可读，却在任何 transcript 问题出现之前就被排除在外了。

官方在另外四处都是分开判的：

1. dsh-session —— fork API 只写 parentSession，别的都不写：

   fork(source, boundary, childSessionId) { … meta: { …, parentSession: liveSource.id, isSeeded: true } }

   即：官方 fork 自己产出的 header，正是 ACP 层随后要拒的那一种。
2. dsh-subagent —— 派生路径是 origin 全仓唯一的写入点，三个字段一起写：

   childSessionMeta(parent, childDepth, isSeeded)
     → { …, parentSession: parentHeader.id, isSeeded, origin: "subagent", delegationDepth: childDepth }

   而它认子代理时要求两个字段同时成立：parentSession === X && origin === "subagent"。
3. dsh-api-session-controller —— 子代理鉴权同样要两个：header.origin !== "subagent" || header.parentSession !== address.parentSessionId。
4. header 类型把两者声明为两个独立的可选字段：parentSession?: SessionId、origin?: 'subagent'，且 origin 的取值域只有 "subagent"。

四个位点分开判，一个位点合并判。

关于文档。 README 把 fork 列在"不支持的操作"里（"deletion, forks, transcript replay, and additional directories are unsupported"），session/list 一行写的是 "persisted, resumable root sessions" —— 所以 list 侧的"只列 root"是可以争辩为已文档化的。但 session/resume 一行没有任何此类限定（原文只说"A persisted inactive session whose canonical workspace is verified before composition"），README 里也没有任何一句说"带世系元数据的会话不可 resume"。:1215 这个条件只存在于代码里，而拒绝信息（session is not resumable: <id>）不说明理由。

对照实验（4 个 header，彼此只差一个字段）。 用官方发布的服务端（dsh --profile acp）：initialize → session/list → session/resume。

#	origin	parentSession	delegationDepth	进 session/list	session/resume
R1	–	–	0	是	ok
R2	subagent	有	1	否	拒绝
R3	–	有	0	否	拒绝
R4	–	有	1	否	拒绝

• R1 与 R3 只差 parentSession：resume 从 ok 变为拒绝。单变量、单次翻转。
• R3 与 R4 只差 delegationDepth：结果完全相同 ⇒ 该字段不参与判定。
• 三次拒绝返回的原文完全相同：Invalid params: session is not resumable: <id>。

另在两例真实产物上复核（108 MB 与 80 MB 的 JSONL，均为 fork 派生、delegationDepth: 0、无 origin）：

• 只删掉 header 里的 parentSession 一个键、其余逐字节不动，两例立刻变为可打开：session/list 可见、session/resume 返回 ok、日志迁移落 v3。
• 把 parentSession 指向一个不存在的会话，什么都没变 —— 报的还是同一句。说明该分支不解析指针，只测"键在不在"。

实测影响面（我方语料，只读扫描）。 快照：279 个会话目录，其中 248 个带 parentSession。

header 形态	会话数
origin: "subagent"（depth 1/2/3）	222
仅有世系 —— 无 origin、depth 0	26
root（无父）	31

问题就在中间这一行：26 个普通的 fork 主线会话。它们不是被派出去干的活、没有谁"占用"它们、日志也完好 —— 但在 0.1.5 下 ACP 客户端看不到、也接不回去。对用户来说，这就是"我的会话不见了、而且打不开"，与实际数据损坏难以区分。

范围。 这道门只在 ACP 面（dsh-api-session-controller 与客户端各路径都不把 parentSession 当作拒绝依据），所以桌面/网页主界面不受影响。但 ACP 正是外部 ACP 客户端所讲的那套协议，而 dsh-subagent-acp 是本仓自带的进程外委派 ACP 客户端。

建议修法。 把判据收窄到子代理标记 —— 以 origin === "subagent" 为准，parentSession 只作世系元数据，与上面四处保持一致。退一步讲，至少允许父可解析的 fork 被 resume；如果这个拦截是有意为之，请把它写进 README 的 session/resume 那一行旁边，而不是只存在于代码里。

复现。 四个只在单个字段上有差异的 header 行，放进一个隔离的 DSH_HOME，然后走 initialize → session/list → session/resume。脚本与原始输出可按需提供；本文不含任何会话内容、用户名或文件系统路径。

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

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

[PerryLink]

Confirmed against master c291e79 (= 0.1.5-rc.2) and the rc.2 dist: the behavior is real and ACP-specific. session/resume rejects any session whose header carries parentSession, OR-ed with the true subagent marker (packages/acp/acp/src/index.ts:249-250; your :1215/:1266 line numbers match the dist verbatim); session/list hides them (:304-313); both predicates test key-presence only, and the behavior is pinned by the ACP's own tests (bridge.spec.ts:373-399). The two signals are separate fields: origin === 'subagent' is the real marker (core/session/src/types.ts:106), and plain forks write parentSession (core/session/src/index.ts:1203-1218). Outside ACP this does not reproduce: Web/API resume rejects only subagent origin (session-controller/src/agent.ts:400-434), and core has resume coverage for forked sessions (agent-loop/tests/resume.spec.ts:907-934). Nuance: README says session/list returns "root sessions" (acp/README.md:67-68), but session/resume has no such restriction (README.md:12), so the resume-side predicate looks over-broad - present since 5111816 (2026-08-22), unfixed on master.

[PerryLink]

核实结论：已确认，两处谓词在 master @ c291e79 上仍然如此，且行号可以精确给出：packages/acp/acp/src/index.ts:249（resumeSession）与 :310（session/list 的过滤），均写作 … || header.parentSession !== undefined，与你在 0.1.5-rc.2 产物里看到的 :1215/:1266 是同一处。

你的"四处分判、一处并判"分析完全成立：fork 路径只写 parentSession（无 origin），委派路径写全三字段且认子代时要求 origin === 'subagent' 与 parentSession 同时成立；ACP 是全仓唯一把 parentSession 单独当作拒绝条件的位点。R1/R3 单变量实验的结论也因此可信——不是指针解析问题，纯属"键在不在"。

建议修法我认同：判据收窄到 origin === 'subagent'，parentSession 只作世系元数据。补充两点执行时要注意的：

1. 收窄之后，fork 会话经由 session/resume 会走带种子的日志回放——resume 路径（AcpSession.resume）是否完整支持 seeded 历史，需要用一个真实 fork 会话的 e2e 测例钉住。如果当初把 parentSession 并进来正是为了挡住 seeded 回放的某个缺口，那 PR 应该把缺口一并补上，而不是只删条件；如果不是，测试就是防线。
2. README 的 session/resume 行确实没有这条限制，session/list 行的 "root sessions" 措辞在收窄后也建议同步改掉（fork 会话将重新出现在 list 里），避免文档与行为再次分叉。

顺带确认：delegationDepth 不参与任何 ACP 判定（与你的 R3/R4 结论一致）；桌面/网页与 dsh-api-session-controller 均不受影响，范围只限 ACP 面。如果维护者确认方向，我可以开 PR：收窄两处谓词 + 一个"fork 会话可被 list/resume"的 e2e 测例 + README 两行同步。

[yamingmou]

@PerryLink — your second comment is the kind that only surfaces from source, and taken together they change what a fix has to contain. Three things I'm taking from it:

1. The behaviour is pinned by ACP's own test (bridge.spec.ts:373-399). So narrowing the predicate is a three-part change — predicate, test, README — not a one-line deletion. Worth stating up front: it's the difference between a one-liner and a contract change.
2. The dist → source mapping (:1215/:1266 ≈ packages/acp/acp/src/index.ts:249 / :310, with session/list hiding them at :304-313) means anyone can reproduce from source rather than from a build, and that the predicate has been unchanged since 511181684c (2026-08-22).
3. "Does not reproduce outside ACP" matches what I could see from the outside. I only ever had the build, so your cross-references (session-controller rejecting only origin === 'subagent'; core carrying resume coverage for forked sessions) are the first source-level confirmation of the same shape.

On your first caution — seeded replay: one data point, with its limits stated.

I did not touch the resume path. I deleted only the parentSession key from copies of two real forked sessions, changed nothing else, and resumed them. Both appeared in session/list, both resumed, and both landed as v3 logs (24,288 and 21,335 events). So for these two, seeded history did replay and re-land on 0.1.5-rc.2 — the predicate was not shielding that path here.

The honest limits: n = 2, my own store, both ordinary forked sessions. That does not rule out the OR having been added to mask a seeded shape these two never exercise — so I agree your e2e belongs in the PR either way. If a third and fourth shape would help, tell me which dimension matters (fork-of-fork lineage? a fork whose source moved on after the fork point?) and I'll produce them.

On your second caution — README: agreed, and it is the sharpest asymmetry in the report: session/resume carries no root wording while session/list does. Narrow the predicate and the list line has to move with it, or docs and behaviour diverge the other way instead.

On the PR: please go ahead. I have no standing to open one — I'm not a contributor, and my evidence comes from the outside (a build, a scratch DSH_HOME, my own store). What I can do once a fix exists: re-run the same four-cell single-variable table against the new build and post the result, and hand over the exact header shapes I used (synthesized, no session content) as fixtures if they're useful. Say where you'd like them.

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

@PerryLink —— 你第二条是从源码里才能看到的东西，两条合起来，改变了"修法必须包含什么"。我从里面取了三点：

1. 该行为被 ACP 自己的测试钉住（bridge.spec.ts:373-399）。所以收窄谓词是三件事——谓词、测试、README——不是删一行。这一点值得写在最前面：它决定了这是"一行小改"还是"契约变更"。
2. dist → 源码的映射（:1215/:1266 ≈ packages/acp/acp/src/index.ts:249 / :310，session/list 的隐藏位点在 :304-313），使任何人都能从源码而非产物复现；也给出了该谓词自 511181684c（2026-08-22）起未变。
3. "ACP 之外不复现" 与我从外部能看到的相符。我手上一直只有产物，所以你给出的交叉引用（session-controller 只拒 origin === 'subagent'；core 对 fork 会话有 resume 覆盖）是对同一形状的第一次源码级确认。

关于你第一条提醒——seeded 回放：我给一个数据点，并把边界一并说清。

我没有碰 resume 路径。我只从两个真实 fork 会话的副本上删掉 parentSession 这一个键，其余一字未动，然后 resume。两个都出现在 session/list 里、都成功 resume、并都以 v3 日志落地（24,288 与 21,335 事件）。所以至少这两例，在 0.1.5-rc.2 上 seeded 历史确实被回放并重新落地了——谓词在这里挡的并不是这条路径。

诚实边界：n = 2、我自己的样本、且两例都是普通 fork 会话。这不能排除当初并入该条件正是为了挡住这两例从未触及的某种 seeded 形状——所以你的 e2e 无论如何都该进 PR。若要第三、第四种形状，告诉我哪个维度更重要（fork 的 fork（更深世系）？还是 fork 之后源会话又继续推进过？），我去做。

关于你第二条提醒——README：同意，而且这是本报告里最锋利的不对称：session/resume 那一行没有任何 root 限定词，而 session/list 有。谓词一旦收窄，list 那行必须同步跟改，否则文档与行为只是反方向再分叉一次。

关于 PR：请你开。 我没有开 PR 的立场——我不是贡献者，证据也来自外部（一个产物、一个临时 DSH_HOME、我自己的样本）。修好之后我能做两件事：对新构建重跑同一张四格单变量表并贴出结果；如果你需要，把我用过的header 形状（合成的，不含任何会话内容）给你当 fixture。贴在哪里，你说。

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

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

[PerryLink]

@yamingmou — thanks for the careful reproduction; that data closes the seeded-replay gap better than anything I could assert from source alone.

Extra shapes. Both dimensions you named are worth it, plus a third:

1. fork-of-fork (lineage depth ≥ 2 — a two-hop parentSession chain);
2. a fork whose source session continued advancing after the fork point;
3. a fork listed/resumed while its source session is still open and owned by a live agent (this exercises the session-controller routing case rather than only the ACP predicate).

Synthesized v3 header shapes are perfect — paste them here or on the PR, whichever you prefer.

PR. I'll prepare it as one three-part change: narrow the predicate, update bridge.spec.ts (373–399 pins both the origin === 'subagent' and the parentSession filters), and move the README session/list wording together with the code. One caveat before promising a link: this repo currently has external PR creation disabled (community PRs are not being accepted; see #3920), so if a PR cannot be opened from my side I will post the complete patch diff in this thread for the maintainers to cherry-pick — either way the patch is coming, and your re-run of the four-cell table against the fixed build is the cross-check I'd want before it lands.

One nuance on the controller side. Your summary of my cross-reference was a degree too strong: packages/api/session-controller/src/agent.ts:85-89 also routes a parentSession child to subagent ownership, but only while a live parent agent owns it — that is the routing path, not resume authorization. The resume-facing rejection stays entirely with ACP (packages/acp/acp/src/index.ts:249 and :310). The contract change is the same either way; I just don't want the record to overstate where the wall is.

History check. I re-ran git log -S parentSession -- packages/acp/acp/src/index.ts on master: the predicate text has not changed since 511181684c (2026-08-22), matching your finding.

Also noted your authorship caveat — the n=2 replay stands on its own evidence; nothing to correct from my side.

[yamingmou]

@PerryLink — your correction is right, and I'd rather carry the narrower version than the one I wrote.

1 · The correction, and why it holds mechanically. I read packages/api/session-controller/src/agent.ts at c291e79. The predicate short-circuits, and the third argument is what decides everything:

:80-84  export function hasApiSessionSubagentOwner(ctx, session, agent): boolean {
:85     if (session.header.origin === 'subagent') return true
:86     const parentId = session.header.parentSession
:87     if (parentId === undefined || agent === undefined) return false
:88     const parent = ctx.agents.get(parentId)
:89     return parent !== undefined && ctx.agents.isOwnedBy(agent.id, parent)

The two call sites on the resume path pass different things:

:421  if (hasApiSessionSubagentOwner(this.ctx, { header: observation.header }, undefined)) {   // agent undefined → parentSession branch unreachable
:427  if (published !== undefined && hasApiSessionSubagentOwner(this.ctx, published, live)) {  // agent live → parentSession branch reachable

resumeObserved calls it with undefined (:421), so for a cold resume of a session that is not currently published, the parentSession branch cannot fire — only origin === 'subagent' can. :427 is the case where a session is published and owned by a live agent, which is the routing/ownership check you described. So your wording is the accurate one: routing and ownership live in the controller; the resume-facing rejection for this marker is ACP-only. My sentence stated a property of the controller when I only had evidence for a property of the cold resume path — that was the degree too strong. For what it's worth, your two references are not in tension: :400-434 is where the rejection is raised, :85-89 is the predicate it asks, and the difference between :421 and :427 is entirely in the third argument.

2 · Your three extra shapes — what I can evidence and what I cannot. Across my two stores (586 session logs, 321 unique sessions; 66 roots, 489 delegation children with origin: 'subagent', 26 forks — parentSession present, origin absent, seeded). Every count below is over unique session ids, so a session present in both stores is not counted twice:

• fork-of-fork, depth ≥ 2: 20 of the 26 forks. The full depth distribution is 2:8, 3:4, 4:3, 5:2, 6:1, 7:1, 8:1 — so two hops is the mild end of what my store contains, not the extreme. If you want the deep case for the e2e, it exists as real headers.
• a fork whose source kept advancing after the fork point: 25 of the 26 forks. By header timestamps, the source's last event is strictly later than the fork's createdAt, the largest gap being about seventeen days.
• a fork listed/resumed while its source is still open and owned by a live agent: I cannot evidence this from logs. That is a runtime ownership state, not a header property, so I will only send you a synthesised header for it — I am not claiming a real instance.

Boundary. My own two stores, my own usage, 26 forks — small. These numbers show the shapes occur in real headers; they say nothing about how the engine behaves on each. That is exactly what your e2e is for, and why I'd rather hand over shapes than conclusions.

3 · Header shapes, since you asked for them. Two key sets differ in the field that carries the seed:

• as written by the fork path (v0): {type, version, id, createdAt, cwd, parentSession, seedLength, delegationDepth, agentPreset} — and note the absence of origin. That absence is the whole reason ACP can only test parentSession !== undefined.
• the same fork after my v0→v3 migration: … parentSession, isSeeded: true …. So the seed is carried as seedLength in v0 and isSeeded in v3; a fixture, or a predicate, written against one name will not see the other.

One more, possibly useful: 12 of the 26 forks carry seedLength: 0 — a fork with nothing to replay. If a fixture for that shape is wanted, that is what I'd use. Say the word and I'll paste the exact header objects with the ids replaced, here or on the patch.

4 · PR and #3920. Noted that external PR creation is disabled here, so the complete diff in-thread is fine from my side — my part of this doesn't depend on how the patch travels. Yes to the cross-check: once it lands I'll re-run the four-cell table against the fixed build and post the raw output, and I'll additionally run list + resume on a depth-2 fork and on a deeper one, since the two-hop case is the one your e2e would otherwise only synthesise. If the fixed build refuses any of them, that is the result and I'll report it as such. Thanks also for re-running git log -S — the predicate being unchanged since 511181684c matches what I could see from outside.

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

@PerryLink — 你的更正成立，我宁可带更窄的那一版，而不是我原来写的那版。

1 · 更正，以及它为什么在机制上成立。 我在 c291e79 上读了 packages/api/session-controller/src/agent.ts。这个谓词会短路，而决定一切的是第三个实参：

:80-84  export function hasApiSessionSubagentOwner(ctx, session, agent): boolean {
:85     if (session.header.origin === 'subagent') return true
:86     const parentId = session.header.parentSession
:87     if (parentId === undefined || agent === undefined) return false
:88     const parent = ctx.agents.get(parentId)
:89     return parent !== undefined && ctx.agents.isOwnedBy(agent.id, parent)

resume 路径上的两个调用点传的东西不一样：

:421  if (hasApiSessionSubagentOwner(this.ctx, { header: observation.header }, undefined)) {   // agent 为 undefined → parentSession 分支不可达
:427  if (published !== undefined && hasApiSessionSubagentOwner(this.ctx, published, live)) {  // agent 活跃 → parentSession 分支可达

resumeObserved 用 undefined 调它（:421），所以对一个当前未被 publish 的会话做冷 resume 时，parentSession 分支不可能触发——能触发的只有 origin === 'subagent'。:427 是"会话已 publish、且被一个活跃代理持有"的情形，也就是你描述的那条路由/归属判定。所以你的措辞才是准的：路由与归属在 controller 里；而针对这个标记的 resume 侧拒绝，只在 ACP。我那句把一个"冷 resume 路径的性质"写成了"controller 的性质"——这就是那个"说重了一度"。顺带说一句：你前后两处引用并不矛盾——:400-434 是抛出拒绝的地方，:85-89 是它去问的那个谓词，而 :421 与 :427 的全部差别就在第三个实参。

2 · 你补的三种形状——我能取证的与取不了证的。 我的两个库合计 586 个会话日志、321 个唯一会话：66 个根、489 个委派子代理（origin: 'subagent'）、26 个 fork（有 parentSession、无 origin、带 seed）。下列所有计数一律按"唯一会话 id"计，因此同一会话在两个库里各有一份时不会被重复计入：

• fork-of-fork，链深 ≥ 2：26 个 fork 里有 20 个。 完整链深分布是 2:8、3:4、4:3、5:2、6:1、7:1、8:1 —— 也就是说两跳只是我库里最浅的那头，不是极端值。若 e2e 想要深链用例，它在真实 header 里存在。
• 源在 fork 点之后仍继续推进的 fork：26 个 fork 里有 25 个。 按 header 时间戳，源的"最后事件时间"严格晚于该 fork 的 createdAt，最大间隔约十七天。
• 源仍打开、且被活跃代理持有时被 list/resume 的 fork：这一条我无法从日志取证。 它是运行时归属状态，不是 header 属性，所以我只会给你合成 header——不主张有真实命中。

边界。 我方两个库、我方自用、26 个 fork —— 样本小。这些数字只说明形状在真实 header 里存在，不说明引擎对每种形状的行为。那正是你 e2e 的活，也是我宁可交"形状"而不是交"结论"的原因。

3 · 你要的 header 形状。 有两套键集在承载 seed 的字段上不同：

• fork 路径写出的原始形态（v0）：{type, version, id, createdAt, cwd, parentSession, seedLength, delegationDepth, agentPreset} —— 注意没有 origin。正是这个缺席，使得 ACP 只能检查 parentSession !== undefined。
• 同一 fork 经我这边 v0→v3 迁移之后：… parentSession, isSeeded: true …。也就是说 seed 在 v0 里叫 seedLength、在 v3 里叫 isSeeded；把 fixture（或谓词）写在其中一个名字上，就看不见另一个。

还有一条可能有用：26 个 fork 里有 12 个 seedLength: 0 —— 一个"没有可回放内容"的 fork。若要给这个形状做 fixture，我会用这个。你说一声，我就把去掉 id 的 header 原对象贴出来，贴这里或贴在补丁上都可以。

4 · PR 与 #3920。 已知该仓库当前禁用外部 PR，所以完整 diff 走帖内在我这边没问题——我这部分不依赖补丁怎么走。复跑那张四格表：答应。 修好后我会对修复后的构建重跑四格单变量表并贴出原始输出；此外我会额外对一个链深 2 的 fork 和一个更深的 fork 跑 list + resume —— 因为两跳那一档，正是你 e2e 否则只能用合成样本覆盖的。如果修复后的构建在任何一个上拒绝，那就是结论本身，我会照实报。也谢谢你把 git log -S 重跑了一遍——谓词自 511181684c 未变，与我从外部能看到的相符。

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

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