Title
Package / version
Summary
// agent.ts, around line 470 (0.1.3-alpha.1 source)
import { mkdir } from 'node:fs/promises'
...
try {
await mkdir(cwd, { recursive: true })
} catch (error: unknown) {
throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error })
}The same statement ships verbatim in every published version (verified by Why this is a defect
Observed impact (out-of-tree deployment)With a remote fs provider mounted (user namespaces are backend-held, virtual Expected behavior
await ctx.fs.mkdir(cwd, { recursive: true }) // or the seam's exact signatureso that:
If a deliberate "host-dir bootstrap" contract is intended (e.g. the launcher Reproduction
Regression test sketchit('creates the project directory through the fs seam, not the host fs', async () => {
const fs = new RecordingFsProvider() // fails loud on unknown calls
ctx.provide(fsServiceKey, fs)
const agent = await controller.create({ cwd: 'ws-a', ... })
expect(fs.calls).toEqual([['mkdir', 'ws-a', { recursive: true }]])
expect(hostTreeDiff(before, after)).toBeEmpty()
})Compatibility notes
Prior art in the tree
|
Replies: 4 comments 3 replies
|
我对你的判读做了源级复核（基于本仓库 master 5dda764 / dsh 0.1.5-alpha.1），结论：你的"seam 绕过"判定成立，但"修复方式 = ctx.fs.mkdir"在 current API 上不成立 —— fs seam（ 你正确的地方
需要修正的地方：
|
|
感谢源级复核，尤其是" 已落地的实现（方案 B，不动 core seam）只用现有 seam 原语（ const fs = this.ctx.get('fs')
const hostDir = fs?.processPathFromHostPath(cwd)
if (hostDir !== undefined || fs === undefined) {
try {
await mkdir(hostDir ?? cwd, { recursive: true }) // local mapping: unchanged
} catch (error: unknown) {
throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error })
}
} else {
let present = false
try {
present = (await fs.lstat(cwd))?.type === 'directory'
} catch (error: unknown) {
throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error })
}
if (!present) {
throw new Error(
`failed to ensure project directory "${cwd}": the fs backend does not map this cwd to the harness host,`
+ ' and the directory does not exist in the backend\'s execution world;'
+ ' create it through the workspace flow (or a pre-provisioned path) before starting a session there',
)
}
}与方案 B 的逐点对应：
回归证据（真实引擎 + 远程 backend，挂 provider-fs-remote）
host 文件树 / DSH_HOME 零新增目录。您给的 RecordingFsProvider 回归 sketch 关于方案 A 同意拆开推进。补充一个下游事实供 A 的 core 提案参考：我们 backend 的文件面 期待 upstream 在"严格 B（controller 永不创建目录）"与"B + 本地映射保留" |
|
这个问题，官方这边会考虑安排解决吗？ |
|
关于这类似的所有接缝点远程化问题，现在每个地方都行需要单独插件区对接，工作量比较大，官方有没有计划收拢一些统一的插件，简化我们拿来做远程化对接繁琐的问题。 |
|
@xmRobinYu 你这两个问题触到的是同一个架构断面，我分开答，都基于 master 5dda764（0.1.5-alpha.1）源级核对。 ① 官方会不会修这个 seam 绕过？我的判断：大概率会先走"收紧"而非"扩 seam"，但具体到 session-controller 这一处，它更像是一笔被动的清理，而不是官方主动立项的修复。理由：
这跟你问的第二点强烈相关 ↓ ② 有没有官方的"统一远程化插件"计划？没有，而且短中期也不会有——这恰恰是插件体系的用武之地，而不是反例。 关键在于：树里没有一条统一的"remote fs seam 实现"。 这就是为什么你那种"每个接缝点都要单独插件对接"的沉重感是真实的：它反映的是 seam 设计缺一个统一的远程世界抽象，而不是插件生态的问题。你这个观察其实可以反过来变成一个很值钱的 core 提案：
这属于 core 能力演进，不是单包修复——如果要提，建议往这个方向写："unified remote execution world adapter"。而 session-controller 的 mkdir 孤点，恰好可以作为这个适配层的第一个回归用例（远程世界下不得在引擎主机长目录树）。 落到插件的一等视角在你等官方对 mkdir / 统一适配层表态的这段时间，有两个可以用插件立刻缓解的夹缝：
这样你不用等官方统一适配层，也能先把"哪个缝在漏"这件事可视化并逐步堵上。你这两问其实把问题从"修一个孤点"上升到了"缺一个统一远程世界抽象"——这比单点修复价值高，建议你在报告里保留这个层次。 （上面提到我之前建议的"方案 B require-exists + 结构化拒绝"仍然成立，作为 mkdir 孤点的保守第一步；"统一远程世界适配层"是它的长远方向。两者不冲突。） |
|
@xmRobinYu 你已落地 Option B（且用真实 remote backend 跑了三场景回归）——这非常扎实，比"提方案"进了一大步。你留给我/upstream 的那个裁决点（严格 B：controller 永不 mkdir vs B + 本地映射保留），我倾向严格 B，理由如下。 为什么选严格 B（controller 永不创建目录）
保留"本地映射 mkdir"分支，虽然让本地零回归（你 host spec 476 绿），但它留住了那个越权语义，只是把它限定在本地 backend。也就是说：
这种后端相关性行为差异，恰恰是 seam 契约最忌讳的：同一个 严格 B 的具体落法严格 B 不是删掉 mkdir 就行，而是要把"cwd 必须已存在"这一不变量前移到调用方，controller 只验证不创造： // 无论本地/远程，controller 都不 mkdir，只校验存在性
const fs = this.ctx.get('fs')
if (fs !== undefined) {
let present = false
try {
present = (await fs.lstat(cwd))?.type === 'directory'
} catch (error: unknown) {
throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error })
}
if (!present) {
throw new Error(
`failed to ensure project directory "${cwd}": ...`,
{ cause: ... },
)
}
}
// fs === undefined 时（无 fs service，纯本地组装），才保底 fallback 到你现有的 mkdir 行为关键点： 一个你可能没注意的边界你现在的补丁里有一个失败分类的缝隙：
对 core 提案的补强你说 remote provider 到 backend 已有 我这边会把"严格 B"作为我推荐的上游取向，并把它归档为一个 upstream-fix 候选（ |
|
真正把 remote fs 当生产部署跑起来 这个我们正在计划做这个，初期支持1000用户使用，后面考虑支持起码上万用户同事使用 |
我对你的判读做了源级复核（基于本仓库 master 5dda764 / dsh 0.1.5-alpha.1），结论：你的"seam 绕过"判定成立，但"修复方式 = ctx.fs.mkdir"在 current API 上不成立 —— fs seam（
FileSystemService）当前没有 mkdir/ensureDir 原语。这是个值得先厘清的前提分叉，否则修复方向会落空。你正确的地方
packages/api/session-controller/src/agent.ts:3确实是import { mkdir } from 'node:fs/promises'，:474直接await mkdir(cwd, { recursive: true })。同包media-references.ts:74已走serveFile(request, ctx.fs, maxBytes)，证明 controller 自己的 media 路径从不直接摸node:fs—— agent-creation 是孤点。这条 seam 绕过在本地 fs 部署下无害，但一旦挂远程/虚拟 fs provider，就会在引擎主机长出镜像目录树（破坏"engine host 不产生用户目录"不变量），或在虚拟 cwd 无法解析为主机绝对路径时直接failed to ensure project directory—— 判断准确。需要修正的地方：
ctx.fs没有 mkdir 原语你的修复建议写的是：