Feature request: supported host APIs for third-party bundles

[yanggu0413]

我請求 DSH 正式支援以下供第三方 bundle 使用的通用宿主 API：

• per-Agent scope 的工具 schema 與執行限制，涵蓋 own/descendant scope 工具。
• 對閒置既有 Session 安全切換 preset，並提供持久化確認與失敗保護。
• 經 composed filesystem 寫入 bounded raw bytes，保留 sandbox 授權與版本／目標不存在條件。
• 驗證來源與完整性後讀回已儲存的 spill text。
• 為原生 sidebar、Session browser、reference 與 Chat UI 提供 additive extension hooks。

請 DSH 將這些能力作為受支援的宿主擴充 API，讓第三方 bundle 能在不複製核心、不繞過 sandbox 或另行修改執行中 runtime 的前提下使用。

[argszero]

Taking these one at a time, with what it is today and where the gap really is. Three of the five exist in some form; two do not.

1. Per-Agent tool schema and execution limits — exists, and it is scoped by construction. ctx.tools.restrict({ allow, deny }) (packages/core/tools/src/index.ts:1097) attaches a restriction layer to a scope, and it refuses to be called on a context-global context, with the message "requires a scoped context (agent.ctx): a context-global restriction would mask every agent — deny the tool for the intended agent instead". Visibility is then resolved per scope through the scope chain (chainLayers(scope), :926-933), which is what makes "own scope" work today; the tool set is also an input to prompt-order validation rather than a post-hoc filter (restrictableNames, :720). Execution-side limits are separate and also present: ctx.tools.guard(...) for pre-execute decisions, and ctx.tools.executionMode(...) for scheduling semantics. What I did not exercise is the descendant case, so treat "a parent's restriction is what a child scope chains onto" as expected from the layer chain rather than measured.

2. Safely switching a preset on an existing Session — this one is refused by design, not missing. A Session records the preset it runs under, and adoption under a different one fails with a named error (ApiSessionPresetConflict, packages/api/session-controller/src/agent.ts:45-58: "session X runs agent preset Y, not Z"; the check is assertPresetUnchanged, :269). The reason is the same one that makes the persistence question hard: the preset is part of the Session's recorded identity, so a live switch would silently reinterpret history that was produced under different instructions and a different tool set. If you want to make this an ask, the useful form is not "switch" but "fork": a new Session seeded from an existing one under the new preset, which keeps both identities honest. That channel already exists in the client (branch/fork); the API-side question is whether it can be driven without a user at the keyboard.

3. Bounded raw-bytes write through the composed filesystem — your ask stands. The Fs service has a byte-oriented read path with a hard cap (readBytes(target, signal, maxBytes) and readByteRange, packages/fs/fs/src/index.ts:228,243), but its write surface is text-only (writeText, editText, :266,287). There is no byte-bounded write, so a plugin that has to place binary content inside the composed filesystem has to leave the abstraction — exactly what your requirement is trying to prevent. Worth stating in the ask that the read side already establishes the contract worth mirroring (an inclusive cap that fails with a specific error rather than truncating silently).

4. Reading back a stored spill — your ask stands, with a subtlety. SpillStore exposes exactly one method, saveText(input): Promise<SpillRef> (packages/spill/spill/src/index.ts:45-58). SpillRef is { locator, bytes, retrievalHint }, and the hint is explicitly backend-specific retrieval guidance — i.e. the design says "read it back with whatever your backend gave you", not "ask the service". So there is no verify-then-read API to call: no integrity check, no service-side read. If your requirement is "verify origin and integrity before reading", the missing piece is in that interface, not in a plugin.

5. Additive UI hooks — the mechanism exists; what is missing is a directory of the entry points. Client slots are declaration-merged: SlotMap, SlotFactoryMap, SlotScopeTargetMap are empty interfaces in packages/client/ui-slots/src/index.ts:26,29,107, and each client plugin fills them via declare module, so slots are additive by construction rather than a fixed enum. Registration is ctx.slots.register(options, component) (:1203), where options may declare children — the child-slot table (:178) — so a third-party plugin can both mount into an existing slot and publish new ones, and the client module system composes those bundles at runtime. The practical gap for a bundle author is knowing which native areas (sidebar, session browser, reference, chat) already publish slots and with what props — that is discoverability, and it is a documentation ask rather than an API ask.

A note on scope. Items 1 and 5 are already supported surfaces that a bundle can use today without copying core or bypassing the sandbox; items 2, 3 and 4 are genuine holes. Phrasing this thread as a list of five equal asks makes it easy to defer all five together — the two supported ones and the constraint that motivated them are the strongest part of your request, because they are what a "no core copying, no sandbox bypass" bundle is actually built from.