Feature request: session scope for fs

[zhming0]

Hi, thanks for making DeepSeek Harness! I run each session in its own remote sandbox, so each fs operation needs to know which session's sandbox it belongs to. I recently hit a few small hurdles supporting the new sidebar with this setup.

In 0.1.5-rc.1, fs only finds a session through the ambient agent initiator, which exists inside a turn. Tool calls works but browser requests outside a turn do not (sidebar). Two examples:

• /api/file: the request carries only ?path=, so there is no session id to route on. Inline Markdown images cannot work with more than one sandbox.
• workspace-files: the gateway already resolves workspaceFileScopeId to { sessionId, workspaceRoot }, but the host methods then call ctx.fs bare, so the session is dropped one step before it is needed.

Could fs accept an optional session scope, or expose a helper like withSession(sessionId, fn), so workspace-files can pass the session it already has? And could /api/file carry a session id so it can do the same?

Thanks!

[kvnloo]

I traced this against current master, and I think the report is identifying an existing composition invariant rather than only asking for a new convenience API.

The "workspace-files" design note says file reads use the Session's composed filesystem backend, and "WorkspaceFileScope" already retains both "sessionId" and "workspaceRoot". On the current Host path, however, that scope reaches "WorkspaceFiles" and the actual "resolve" / "stat" / "read*" / "listDir" operations still go through the host "ctx.fs". The Session identity is therefore available one layer above the filesystem call and then gets dropped.

"/api/file" has the same property from the other direction: it closes over host "ctx.fs" and the URL carries only "path", so there is no Session identity available for provider selection.

One thing that makes me think the fix may belong at the Host/session adapter rather than inside "FileSystem" itself is the existing preset machinery. "AgentPresets.serviceFor()" is explicitly documented for requests that are about a Session but arrive from outside its isolated composition, including browser RPCs. "SessionFileReferences" already uses a Session-addressed adapter for an Agent-scoped capability, and "SessionSkillCatalog" has the live-vs-cold Session pattern as well.

So I wonder if the narrower invariant is:

«A Host API that already possesses Session identity should resolve that Session's filesystem capability explicitly, then use the same resolved "FileSystem" for the complete operation.»

That would keep "ctx.fs" as the filesystem for one execution world rather than making it depend on ambient Session state.

For "workspaceFiles", that could mean resolving the filesystem once from "WorkspaceFileScope.sessionId" before "resolve()" creates an "FsTarget", then threading that same provider through the rest of the operation. That last part seems important because a target produced by one remote/backend execution world should never accidentally be consumed by another.

For "/api/file", the renderer could include the owning Session id and the handler could use the same resolver instead of host-global "ctx.fs".

The cold-Session case looks like the main design question. "workspaceFiles" deliberately supports cold Sessions without activating an Agent, so resolving only through "ctx.agents.get(sessionId)" would fix live Sessions but weaken that contract. The existing recorded-preset / standing-composition path used by other Session-addressed services may be a useful precedent here.

A regression test I think would pin the behavior well is two Sessions whose compositions expose distinct fake filesystem backends but use the same path. "workspaceFiles.read(sessionA, "/same")" and "read(sessionB, "/same")" should return different backend values, and a cold Session should continue resolving its recorded composition without activating an Agent. The existing host-global filesystem behavior should remain unchanged for compositions that do not isolate "fs".

Happy to dig further into the cold-session service-selection path if this direction matches the intended ownership model.